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, . 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]