Internet DRAFT - draft-iucg-precaution
draft-iucg-precaution
Network Working Group J-F C. Morfin
Internet-Draft Intlnet
Intended status: Informational December 15, 2008
Expires: June 18, 2009
Application of the Precautionary Principle by the IETF
http://iucg.org/draft-iucg-precaution-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 18, 2009.
Abstract
This Memo documents how the IETF pursues its mission in adherence to
the Precautionary cardinal principle and may benefit from its
application in its goal to make the Internet work better and in
addressing some of its documented problems.
Morfin Expires June 18, 2009 [Page 1]
Internet-Draft Precautionary principle December 2008
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Better safe than sorry . . . . . . . . . . . . . . . . . . . . 3
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Legal status . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Areas of applications . . . . . . . . . . . . . . . . . . 4
3.4. Innovation ethic . . . . . . . . . . . . . . . . . . . . . 4
4. Enacting the Precautionary principle . . . . . . . . . . . . . 5
4.1. When does the principle apply? . . . . . . . . . . . . . . 5
4.2. Investigating a possible case of application . . . . . . . 5
4.3. Attitude to be adopted . . . . . . . . . . . . . . . . . . 6
5. IETF mission, cardinal principles, and the standard process . 6
5.1. Cardinal principles . . . . . . . . . . . . . . . . . . . 6
5.2. The standard process . . . . . . . . . . . . . . . . . . . 7
5.2.1. Criteria for selecting new work . . . . . . . . . . . 7
5.3. Charter . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. A way to address identified IETF difficulties . . . . . . . . 9
6.1. The Balance Between Research, Invention, and Adoption . . 9
6.2. The Reach of the Internet . . . . . . . . . . . . . . . . 9
6.3. Funding the Internet R&D . . . . . . . . . . . . . . . . . 9
6.3.1. Commercial funding . . . . . . . . . . . . . . . . . . 10
6.3.2. Precautionary alternative to commercial funding . . . 10
6.4. Difficulties of the IETF in accomplishing its Mission . . 10
6.5. The IETF has Difficulty Handling Large and/or Complex
Problems . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.5.1. Engineering in the large . . . . . . . . . . . . . . . 12
6.5.2. Contribution of the lead users community . . . . . . . 13
7. Precautionary considerations section . . . . . . . . . . . . . 14
7.1. Approaches . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Practical organization . . . . . . . . . . . . . . . . . . 14
7.3. Conceptual terminology . . . . . . . . . . . . . . . . . . 14
8. Proposed Precautionary oriented questionnaire . . . . . . . . 15
8.1. Evolution of this questionnaire . . . . . . . . . . . . . 17
9. Security considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Morfin Expires June 18, 2009 [Page 2]
Internet-Draft Precautionary principle December 2008
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"in this
document are to be interpreted as described in [RFC2119].
2. Introduction
The IETF Precautionary duty consists in responsibly considering the
risks that may be created, on the Internet architecture and its
deployment, international relations, global economy, cultural,
societal, natural environment, people's future, etc. by the influence
of each of its engineering documents, independently from the high
quality and technical relevance that they must achieve.
The IETF adherence to this Precautionary cardinal principle is
implied as a requirement or as a need in the RFCs that define the
mission of the IETF [RFC 3935], as well as in the way it organizes
itself [RFC 2418] and processes Internet standardization [RFC 2026],
its research and development objectives [RFC 3869], and its
professional ethic in approving its documents [PROTO project] and
considering the needs for improvements that it itself has identified
[RFC 3774].
There is a general increase in users' concerns, from civil society,
the regalian domain, private sector, and international organizations
throughout the world, about technological precaution. Such a concern
necessarily extends to the Internet, which has become a key structure
for humankind. This Memo seeks to identify what precaution means
exactly when documenting the Internet as the IETF does, and to
summarize how the IETF addresses and progresses on this issue. It
also seeks to call on the contribution of all those who may help the
IETF in new ways towards a better Internet for every person on earth.
3. Better safe than sorry
Everyone knows about precaution as a responsible duty for every
individual. However, the recent technological development calls for
a rethinking of this notion within the collective standardization
process, global operations, and world governance.
3.1. Definition
The Principle of precaution is an emerging societal, ethical,
cultural, political, technical, and economic principle that states
that if an action or strategy might cause severe or irreversible
Morfin Expires June 18, 2009 [Page 3]
Internet-Draft Precautionary principle December 2008
harm, in the absence of a scientific and implementation governance
responsible consensus that harm would not ensue, the burden of proof
falls on those who would advocate taking the respective action or
following the respective strategy.
3.2. Legal status
It is not a fully juridical principle, as it still can hardly provide
regulations that are sanctioned by laws, or describe what actions to
take. In most cases, it seeks to trigger reactions in advance,
before any irreversible damage occurs. However, in some legal
systems and international agreements, the precautionary principle is
a general and compulsory principle. The principle of Precaution
appears as a new mode of collective or global action or governance,
which is often associated with subsidiarity and proportionality
principles.
In addition, many countries choose to consider consumer points of
view, and media reporting, to create a new space for debate, where
politicians, experts, and journalists are answerable to other actors
(e.g. consumer associations, juridical authorities, etc.).
3.3. Areas of applications
The precautionary principle reflects the belief that when there is
scientific or a practical deployment, uncertainty concerning a
project, an action, or a standard and their consequences, preventive
measures may be justified.
This principle is often invoked when the consequences are considered
sufficiently great to require expensive amelioration, even when the
risks are considered low. In the Internet case as well as in
Internet direct or indirect usage areas this will be invoked where
scientific evidence is insufficient, inconclusive, or uncertain and
preliminary scientific evaluation indicates that there are reasonable
grounds for concern that the potential dangerous effect on the
network, human, economic, cultural, and operational environment may
be inconsistent with the level of quality and protection that is
chosen by users or their country.
3.4. Innovation ethic
The concept includes an implicit ethical responsibility that is
assumed by engineers, governance, lead users, and every informed
person, entity, or process towards maintaining the integrity of the
common technical and natural systems and acknowledges the fallibility
of human understanding. It is very technically familiar to the
Internet operators who are, for example, constantly confronted with
Morfin Expires June 18, 2009 [Page 4]
Internet-Draft Precautionary principle December 2008
the DNS system pollution and mismanagement risks and the real-time
precaution duty that this requires.
As such, the application of the principle modifies the status of
innovation and risk assessment: it is not the risk that must be
avoided or amended, like when considering security, but rather a
potential risk that must be prevented. Thus, in the case of the
operations of scientific and engineering research and development,
there is a third party, beyond the technical scientist and engineer
side, and the regulator and operator governance: the consumer, or the
user in the Internet case.
4. Enacting the Precautionary principle
The precautionary principle is not an absolute rule. It should be
first accepted as a cultural concept helping to clarify arguments, in
particular to determine where the burden of proof lies between the
designers of a new protocol or architectural proposition, the
operators, and the users.
4.1. When does the principle apply?
It may apply everywhere, as a perfect protocol does not necessarily
deploy perfectly. Two conditions should lead to precautionary
considerations:
o a threat or a user's fear of serious or irreversible damage,
pollution, or confusion.
o a scientific and operational uncertainty as to the extent of that
respective possible damage.
Once these two conditions have been addressed, precautionary measures
can still be taken or advised, but they should be proportionate.
The principle should not be used to try to avoid all the risks or to
block a competitive project.
4.2. Investigating a possible case of application
Five points should be considered:
o whether there are scientifically or operationally rational grounds
for the concern.
o the extent of the threat: local to an application, network wide,
application level, cultural or economic impact, etc. and human
lives.
Morfin Expires June 18, 2009 [Page 5]
Internet-Draft Precautionary principle December 2008
o the perceived value of what is put at risk, the future being more
important than the past.
o if the impact can be managed or not in an acceptable manner.
o the level of public and user concerns.
4.3. Attitude to be adopted
Evaluation of the technical, scientific, and operational level of
uncertainty should consider what would constitute sufficient
evidence; the level and kind of uncertainty, the potential to reduce
uncertainty; the possibility of locally or time contained
experimentation; previous experience, etc.
If the principle applies, it shifts the burden of proof and
legitimacy.
o The decision maker must assume that the threat is real and that in
making it accepted by the concerned parties that it is negligible
or sufficiently compensated reverts back to him or her.
o The concerned parties are permitted to take preventive measures
without having to wait until the reality of the seriousness of the
threat becomes fully known. The more significant and uncertain
the threat is, the more the precaution should be required.
Decisions applying to the precautionary principle must be open,
informed, and democratic and must include the affected parties.
5. IETF mission, cardinal principles, and the standard process
The precautionary principle is implied at the core of the cardinal
principles that the IETF is in adherence to when it carries out its
mission. This mission is to produce, along the Internet standard
process [RFC 2026], high quality, relevant technical and engineering
documents that influence the way people design, use, and manage the
Internet in such a way to make the Internet work better [RFC 3935] in
every part of it, as a whole, and for everyone.
5.1. Cardinal principles
These documents describe protocols and practices for which secure and
scalable implementations of a certain impact, consistency, and
coherence are expected to have wide deployment and interoperation on
the Internet in order to form a part of the infrastructure of the
Internet, or to interoperate with technologies that are designed
outside the IETF.
Morfin Expires June 18, 2009 [Page 6]
Internet-Draft Precautionary principle December 2008
o Open process: any interested person of the IETF compatible
language and culture can directly participate in the work, know
what is being decided on, and make his or her voice heard on the
issue.
o Technical competence: the issues on which the IETF produces its
documents are issues where the IETF has the competence that is
needed to speak of them, and the IETF is willing to listen to
technically competent input from any source. Where it does not
have, and cannot gather, the competence needed to make technically
sound standards, it should not attempt to take on the leadership
role.
o Volunteer Core: the IETF participants and leadership are people
who come to the IETF because they want to do work that furthers
the IETF's goal of "making the Internet work better" in every part
of it, as a whole, and for everyone.
o Rough consensus and running code: IETF makes standards based on
the combined engineering judgment of its participants and their
real-world experience in implementing and deploying its
specifications.
o Protocol ownership: when the IETF takes ownership of a protocol or
function, it accepts the responsibility for all the aspects of the
protocol, even though some aspects may rarely or never be seen on
the Internet.
5.2. The standard process
The IETF standard process has been optimized over time to permit the
production of high quality, relevant, technical, and engineering
documents concerning the design, use, and management of the Internet
in such a way as to make it work better: it is now also necessary to
make it interoperate better with other systems, as a whole, and for
everyone. This is a broad part that is obtained through, and due to,
the quality of the Internet standard process.
This process is characterized by at least three main aspects: the
criteria used when selecting new work, the charter defining it, and
the progression of the work from WG establishment to the final
approval by the IESG. Different precautionary aspects are embedded
or are still to be ascertained.
5.2.1. Criteria for selecting new work
When determining whether it is appropriate to engage in new work,
promoters, Area Director(s), and the IESG consider the following
points that are precautionary in terms of selecting a good topic, but
also that is the best for managing the IETF resources and voluntary
participants' time and efforts.
Morfin Expires June 18, 2009 [Page 7]
Internet-Draft Precautionary principle December 2008
o Are the considered issues clear and relevant to the Internet
community, achievable within a reasonable timeframe, and are there
risks and urgency for the work?
o Is there an overlap with other currently engaged work, and
sufficient and broad enough available interest within the IETF and
expertise in the topic?
o Does a base of interested consumers (end-users) appear to exist
for the planned work? This is where a precautionary attitude will
attract the interest of lead users and of consumer organizations?
o Is the IETF the best suited place to take the lead in the "real
world?.
o Are all the known intellectual property rights that are relevant
to the proposed work issues well understood?
o Is the proposed work an open effort or an attempt to "bless" non-
IETF technology? Is their at all (inside or outside the IETF) a
good understanding of what is technically and operationally
relevant to the proposed topic: it will be a starting point for
any precaution related debate.
5.3. Charter
The formation of an IETF working group requires a charter to be
approved by the promoters and the IESG with advice from the IAB. A
charter is a contract between a working group and the IETF to perform
a set of tasks. This notion of a contract will be of the essence in
further precautionary work and considerations in order to make sure
that everyone has the same understanding of the expected influence of
the document being worked on/out.
To facilitate the evaluation of the intended work and to provide
ongoing guidance to the working group, RFC 2026 states that the
charter must describe the problem being solved and should discuss the
objectives and expected impact with respect to: architecture,
operations, security, network management, scaling, and transition
(where applicable). This list should also include concerns about the
network, international, cultural, economic, strategic, technological,
etc. environment.
The IETF acknowledges that the proposed working groups often comprise
technically competent participants who are not familiar with the
history of Internet architecture or IETF processes. This can,
unfortunately, lead to good working group consensus about a bad
design. To prevent this, Area Directors may assign a Consultant from
among the ranks of senior IETF participants. This practice should
extend to User senior experts in the non-Internet areas that may be
impacted. An example is the direct participation of the ICANN Staff
to the WG-IDNABIS.
Morfin Expires June 18, 2009 [Page 8]
Internet-Draft Precautionary principle December 2008
6. A way to address identified IETF difficulties
The precautionary principle deals with the problem of introducing
innovation in any environment. In documenting network elements, the
IETF constantly faces that kind of situation. This is why it turns
out that this principle may help the IETF to better approach, and
sometimes seamlessly address, difficulties that it has identified
over the years but where its participants have not yet perceived the
roots.
6.1. The Balance Between Research, Invention, and Adoption
The IETF has traditionally been a community for experimentation with
things that are not fully understood, the standardization of
protocols for which some understanding has been reached, and the
publication of (and refinement of) protocols that were originally
specified outside the IETF process.
The first precaution is to decide whether or not these activities
should be performed within the IETF. Then, one should not chiefly
look at the type of activity, but rather the potential benefit to the
Internet system and the Internet community - an experiment that
yields information about the fact that an approach is not viable
could be of real benefit.
6.2. The Reach of the Internet
The people interested in the Internet's evolution are from every
culture under the sun and from all walks of life. The IETF puts its
emphasis on technical competence, rough consensus, live testing and
operations, and individual participation. It, therefore, needs to be
open to competent input from any source whatever the language. The
IETF uses the English language for its final work and documents.
This may raise users concerns, provoke a lack of trust, and lead to
conflicting alternative usage developments. The IETF must,
therefore, as a precaution try out imaginative multilinguistics
propositions (multilinguistics is understood here as the methodology
to address the diversity of the phenomena of linguistic diversity).
This is why it should consider how to best benefit, as in ISO, from
the multilinguistic adage: "semantics add, pragmatics subtract".
6.3. Funding the Internet R&D
There are three observed sources of network R&D:
o the academic effort
o the commercial funding sources that more likely fund the research
that leads to a direct competitive advantage.
Morfin Expires June 18, 2009 [Page 9]
Internet-Draft Precautionary principle December 2008
o the Internet lead users that are partly visible through external
innovation the IETF uses further on [RFC 3935]
This is because no single organization (e.g., no single government,
software company, equipment vendor, or network operator) has a sense
of ownership of the global Internet infrastructure, research on the
general issues of the Internet infrastructure are often not
adequately funded.
6.3.1. Commercial funding
If there was no commercial funding for Internet research, then few
research projects would be taken to completion with implementations,
deployment, and follow-up evaluation. However, the IAB has
documented [RFC 3869] that if commercial funding is the main source
of funding for future Internet research, the future of the Internet
infrastructure could be in trouble. In addition to issues about
which projects are funded, the funding source can also affect the
content of the research, for example, towards or against the
development of open standards, or taking varying degrees of care
about the effect of the developed protocols on the other traffic on
the Internet.
6.3.2. Precautionary alternative to commercial funding
This is why self-precaution calls for the IETF to consider all of
what can be done together with the academic and lead user communities
to make them more focused on research concerning the basic, applied,
and usage architectures of the Internet and be more productively
listened to. This might also attract governments and non-commercial
sponsors, as they themselves are specialized innovative users, so
that they might sustain the necessary FLOSS funding and join forces
with the lead users, who are more interested in people/SNHN (Small
Network/Home Network - Standalone Host) centered innovation.
6.4. Difficulties of the IETF in accomplishing its Mission
The IETF has now a clearly defined and commonly understood Mission
[RFC 3935]. Its Mission Statement does not document the
Precautionary principle, but it does imply it. This has many
positive consequences. However, some identified problems [RFC 3774]
remain that a broader consideration of the Precautionary principle
might help to address.
o Working Groups can potentially be hijacked by sectional interests
to the detriment of the IETF's mission. Embedding Precautionary
considerations in the Internet process (WG work) and documents
(Drafts, PROTO evaluation, RFC) can certainly help to reduce that
Morfin Expires June 18, 2009 [Page 10]
Internet-Draft Precautionary principle December 2008
risk, in which the responsibility of the non-hijacking falls on
the hijackers themselves.
o It would be desirable to have road maps and architectural views
for portions of work that extend beyond a single working group: it
may also be the case that it is no longer possible to fit the
whole Internet within a single architecture. This is something
the external point of view of lead users and other SDOs should
help to appreciate through the expression of their own
Precautionary concerns, most probably offering cross-fertilized
views of the "good of the Internet" and how to make the Internet
useful to the greatest number of stakeholders for the long-term.
The resulting dialog can only help a general debate where the IETF
itself may in turn benefit from the application of the Precaution
principle by other SDOs and users.
o One of the requirements of the Precautionary principle is for the
IETF to issue Precautionary considerations concerning its own
engineering choices and practices, covering both the techniques
that are used to derive and verify the technical solutions needed,
and the management and organizational strategies that are expected
to help with the engineering process. This includes points such
as:
* timely, high-quality, predictable outputs, respecting the WG
Charters and timelines.
* methodology to ensure that the there is a uniform view in the
WG of the scope of the WG activity, especially over the
intended purpose of the solutions wherein the Precautionary
considerations may have to document the state-of-the-art
scientific consensus of negligible risk.
* the WG reflection road-mad that leads to that conclusion.
* the identification and articulation of the engineering trade-
offs that have been adopted without inappropriately reducing
the 'fitness for purpose' for the intended users.
* the conclusion of adequacy with no further possible refinement
in order to meet the requirements that are placed on it by the
intended purpose that is documented in the charter.
This may call for more detailed and respected charters, WG commonly
agreed upon road-maps, detailed plans, timelines to be followed,
audits on users' explicit criteria for the concerned standard
development, early reviews and dialogs with users directly or
indirectly interested in the immediate focus of the documents, and
questions about the problem areas that might arise due to
interactions with other popular IETF protocols.
This should give a clear and simple incentive that will help to
transparently address the problems listed in RFC 3774. The users'
dialog should provide metrics to measure the achievement of the
desired quality and performance of both WGs and the whole IETF: the
Morfin Expires June 18, 2009 [Page 11]
Internet-Draft Precautionary principle December 2008
shorter the users' wish list, the fewer users who would have to post
comments and the higher their trust, along with the document's
probable quality, and the better the Internet should work.
Direct cooperation with lead users, should also enable the parallel
testing of running prototype code to verify the suitability of the
documented propositions. This should also ensure improved dialog of
the WG and of the interested lead users, and probably - through them
- with other WGs.
6.5. The IETF has Difficulty Handling Large and/or Complex Problems
As RFC 3774 states it, the IETF has historically been most successful
when dealing with tightly focused problems that have few interactions
with other parts of the total problem solution. Given that the
Internet has become more complex, such tightly focused problems are
becoming the exception. IETF standardization procedures are
optimized for tightly constrained working groups and are generally
less effective if 'engineering in the large' is needed to reach a
satisfactory solution.
The IETF does not always seem to be aware of the interactions between
the protocols that are bound to be thrown off by deployment in more
complex situations and thereby the IETF fails to minimize the chances
of unwelcome consequences arising when a new protocol is deployed.
This is precisely where the Precautionary principle has a key role to
play, since the duty of precaution consists in making sure that such
unwelcome situations do not arise.
6.5.1. Engineering in the large
As we have learned more about the ways in which systems on and
outside the Internet interact, the design of components needs to take
into account increasingly external constraints. The understanding of
these constraints tends to require more engineering in the large.
Engineering in the large can encompass many aspects of system design
including:
o Architecture
o Frameworks
o Security
o Internationalization
o General systemic modeling, issues, and precaution.
It also appears that handling large and/or complex systems calls for
a deeper focus on a narrower range of issues (for practical reasons)
with a wider understanding of the system and the context in which
they will be used or in the way that they will be supported.
Morfin Expires June 18, 2009 [Page 12]
Internet-Draft Precautionary principle December 2008
There are two main ways to practice this engineering in the large:
o by way of theory, specialized studies, and inter-SDO relations:
this is the role of the IAB, which is suited to represent the deep
interests of the technology's core.
o by way of experimentation, usage, and in the field adaptation:
this is the increasing role of the "lead users" who are directly
confronted with the demands of the real world's diversity and to
its permanent operational evolution.
6.5.2. Contribution of the lead users community
A lead-user is a user that adapts what he or she purchases to the
real needs at hand rather than adapting his or her needs to what is
available on the market. This adaptation may sometimes amount to an
entire redesign or brand new development. The FLOSS phenomenon is a
good example. Lead users usually represent between 0.1 and 2 percent
of a customer population, depending on the technological level of a
sector and the cost of the engaged upgrading. They become, in some
areas, a heavy industrial trend, where the "market" actually sub-
contracts its solutions to industry.
In the Internet viral environment, they represent a strong capacity
for innovation and contribution. The IETF has not been able so far
to take full advantage from them. However, the IETF wasinitially
lead-usersengineering group. One of the reasons of the disconnect is
that, for a time, lead-users were mostly small entrepreneurs with
market priorities. This time is over as there is more and more
motivation for people to drive their own "cybercraft" and become
"home lead users". Another reason is their more user centric
distributed vision of the network, which prevails now in the WSIS
framework, while the IETF's vision is still more network centric.
There also are some remnants of the "alt-root" / "open-root" issue
about the management of the virtual DNS root. The multilaterality of
a systemic understanding of the Internet helps to merge these
visions: precautionary concerns demand their dialog since it actually
consists in the IETF convincing users that its solutions do not harm
them, which could turn out to be an excellent quality test for the
IETF deliverables.
The difficulty is a practical interface problem because visions,
languages, priorities, time-to-usage, practices, and operational
needs all differ. There is, therefore, a need to build, provide, and
maintain such interfaces. The IUCG@ietf.org mailing list and its
attached site and resources have been created to experimentally
explore that possibility in two connate directions: the community of
the users of the IETF documents, and the community of the lead users
of the Internet that documents influence the design, use, and
management.
Morfin Expires June 18, 2009 [Page 13]
Internet-Draft Precautionary principle December 2008
Based on experience, the target should be to replace the technical/
process appeal procedure. When an individual user thinks that the
Internet standard process has produced a result that is harmful to
the Internet or thinks that the IETF processes have not been adhered
to, there should be a process to aid that individual in seeking to
change that result, or to possibly even prevent the outcome in
permitting the IETF community to understand him or her better and
possibly benefit from users' conceptions and experience.
7. Precautionary considerations section
In order to prevent this kind of conflict without destabilizing their
own work, WGs or authors can choose to include a Precautionary
considerations section in their IETF document.
7.1. Approaches
This may resort from two general approaches:
o to explain that the IETF consensus, as verified by the operators'
community, considers uncertainty and risks to be negligible or
adequately compensated compared to the expected return.
o or to detail the risks and incertitudes that remain to be solved
or that may have to be met under certain circumstances u such as,
for example, security violations documented in the Security
consideration section, technological transitions or interfacing,
governance policies. or usage trends.
7.2. Practical organization
WG Chairs and WG Members may be confronted with two kinds of equally
embarrassing minority situations:
o either there is an opposition to the consequences of the WG
choices but no alternative proposition.
o or there is one or several alternative propositions to the WG
choices.
In both cases, one or several "design teams" should be created. In
the first case to document a list of points calling for clarification
or a consensual IETF precautionary position, comforted by the
Operators' community. In the second case, to try to reach a multi-
consensus where each position should be made interoperable et
published with precautionary comments by its opponents.
7.3. Conceptual terminology
Usually an IETF document treats an individual system, concept,
protocol, black box, etc. Precautionary considerations necessarily
Morfin Expires June 18, 2009 [Page 14]
Internet-Draft Precautionary principle December 2008
belong to a systemic global vision of interpenetrated systems. In
order to help differentiate the parts of the involved systems in a
multiple system network context, the following concepts may be used:
o endotem: is the system internality. This is what the document is
usually about. Its coherence and stability have been discussed at
length by the WG, designers, and reviewers.
o exotem: is the rest of the world system, which is external to the
considered system and that may be polluted or irreversibly changed
or harmed by such a considered system.
o peritem: is the interface between the endotem and exotem.
Security considers its break-ins. It is to be noted that in an
interpenetrated system (such as a virtual network, an inter-
governance mechanism, a distributed architecture, etc.) the
peritem may have top level discontinuities. In such cases it
should be extended down to the first continuous layer.
8. Proposed Precautionary oriented questionnaire
For consistency purposes, this section builds on the "RFC-to-be
draft-ietf-proto-wgchair-doc-shepherding", current template. Its aim
is to help every IESG and IAB Member, IETF Participant, and Internet
user to share the same precautionary logic based on a common
questionnaire, which can be maintained online.
o (1.a) What are the positions and who are the Shepherd (IESG) or
Mentor(s)(Users) for this document? Do they believe that this
version of the document is ready for for final review and
publication?
o (1.b) Has the document been adequately reviewed from key WG
members and from key non-WG members, including Users? Is there
any concern about the depth or breadth of the reviews that have
been performed? Have such concerns been expressed along the
regular open Internet standard process (other oppositions should
not be considered as not prepared enough).
o (1.c) Are there concerns that the document needs more review from
a particular or broader perspective, e.g., architecture, security,
operational complexity, someone familiar with AAA,
multilinguistics and internationalization, system theory,
operational deployment, usage governance, XML, and ISO standards?
o Does the document respect the Charter and the resulting WG's road
map? If not, why?
o (1.d) Are there any specific concerns or issues with this document
that one should be aware of? For example, uncomfortability with
certain parts of the document, or concerns over whether there is
really a need for some. In any event, if the WG has discussed
those issues and has indicated that it still wishes to advance the
Morfin Expires June 18, 2009 [Page 15]
Internet-Draft Precautionary principle December 2008
document, this should be detailed and answered. Has an IPR
disclosure that is related to this document been filed? If so,
the reference to the disclosure should be noted and summarized in
the WG discussion and conclusion of this issue.
o (1.e) How solid and large is the WG consensus behind this
document? How construed, shared, and deep are the concerns raised
by this document? Are there existing or investigated alternative
approaches?
o (1.f) Has anyone threatened an appeal or otherwise indicated
extreme discontent? Is the position documented? Are the
alternative or complementary propositions documented?
o (1.g) Is the document presented clearly enough for Users to
understand it, as well as for the RFC Editor to publish it?
o (1.h) Has the document split its references into normative and
informative? Are there normative references to the documents that
are not ready for advancement or are otherwise in an unclear
state? Are these normative references from the IETF, or by other
SDO(s)? If such normative references exist, what is the strategy
for their completion and expected pubication date? Are there
normative references that are downward references, as described in
[RFC3967]?
o (1.i) Does the document have an IANA consideration section and is
it consistent with the body of the document? If the document
specifies protocol extensions, are reservations requested in the
appropriate IANA registries? Are the IANA registries clearly
identified? If the document creates a new registry, does it
define the proposed initial contents of the registry and an
allocation procedure for future registrations? Is the IANA
registry created to be interoperable with external or Users'
registries that are being (or will be) used on the Internet. What
are the procedures to protect clear interoperability?
o Are there usage oriented tables or information to be gathered,
supported, and maintained? Are their metadata (and possible
additional attributes) documented online?
o (1.j) Do the sections of the document that are written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.,
validate correctly in an automated checker? If new terminology is
being used in the document, is it consistent with other
(multilingual) terminology(ies) in use in the international and
Internet standards?
o (1.k) The IESG approval announcement implies some bureaucracy .
Are there concerns related to it?
o (2.a) Which Internet Modeling perspective does the document use?
Is it adequate? Is it documented enough? Does it benefit from
reasonable support?
o (2.b) Does the document include a "Precautionary consideration
section"? Is it coherent with the "Security consideration
section"?
Morfin Expires June 18, 2009 [Page 16]
Internet-Draft Precautionary principle December 2008
o (2.c) If the Precautionary considerations section recommends
precautions, can they be deemed as complete and sufficiently
documented?
o (2.d) If the Precautionary considerations section concludes that
possible risks, uncertainty, or harm that are created by the
influence of the document are negligible: is it convincing? Does
the IESG and IAB formally support its conclusions? Would an
appeal against them succeed or fail?
o (2.e) What would be, if any, the alternatives to the document
proposition, their impact, delay, and degree of reliability? To
which extent do they imply or require an architectural model
change?
o (2.f) What is the timed deployment strategy? Is the proposition
worth its cost and delays? Does it call on external cooperation?
Were the providers of that cooperation involved in the document's
preparation?
8.1. Evolution of this questionnaire
This questionnaire should evolve with the Internet architecture and
with the digital convergence in order to consider the technological
and usage interface of the datacommunications strata the Internet
technology belongs to with the telecommunications (hardware, signal)
and the metacommunications (semiotic, meaning and semantic coherence)
strata.
9. Security considerations
The Precautionary domain is an environmental extension of security.
Failing to consider it would be a major security violation.
10. IANA considerations
The main Internet issue, until it transitions to an MDRS
(Multilingual Distributed Referential Systemic) permiting the multi-
dissemination of the user-centric metastructure necessary to support
the Multilingual and Semantic Internet, is the precaution of
protecting the IANA independence from political, strategic,
commercial interests.
This Memo gives some hints on the way to proceed, but did not intent
to discuss the non-technical Internet Governance issues.
11. References
Morfin Expires June 18, 2009 [Page 17]
Internet-Draft Precautionary principle December 2008
11.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004.
[RFC3869] Atkinson, R., Floyd, S., and Internet Architecture Board,
"IAB Concerns and Recommendations Regarding Internet
Research and Evolution", RFC 3869, August 2004.
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, October 2004.
11.2. Informative References
[PROTO] Changes are expected over time, "PROTO Shepherd Write-up",
Sept. 17 2008,
<http://www.ietf.org/IESG/content/Doc-Writeup.html>.
Appendix A. Acknowledgments
Thanks to Russ Housley for the questions he asked. And to
france@large for their help in addressing them.
Author's Address
Jean-Francois C. Morfin
INTLNET
23 rue Saint Honore
Versailles 78000
France
Phone: (33.1) 39 50 05 10
Email: jefsey@jefsey.com
URI: http://intlnet.org
Morfin Expires June 18, 2009 [Page 18]
Internet-Draft Precautionary principle December 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Morfin Expires June 18, 2009 [Page 19]
