POISSON Todd Glassey Internet Draft TGC Document: 07-2003 Category: Informational The definitions of 'fair and open' and their implication as used in IETF Standards Process defined in RFC2026 v3 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This document tracks the use of the terms Fair and Open as used in RFC2026, and their impact on the processes of the IETF Operations. It also summarizes a set of requirements for other changes to the governance models so stay in concert with the concept that the IETFÆs processes be fair and open. 2. Intended Audience This document is intended for all members of the IETF and those concerned with the ISOCÆs Internet Standards process 3. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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 RFC-2119 [2]. Glassey Informational û 12/2003 1 draft-glassey-fairopen2026-00.txt 07-2003 The following Terms are taking from the current efforts within the IPR working Group. 3.1 assumed ideas One key thought that needs to be stated here is that the IETF was originally created so that anyone, anywhere, and as a part of any effort could participate. That the process that they were participating in was both open in that it allowed them to participate, and that it was also fair, in that it accords all initiatives and participants the same facilities and capabilities. 4. Setting the stage - Fair and Open RFC2026 has the instances of the terms Fair and Open, or forms thereof in no less than 8 separate instances. We see these terms constraining the global and high level format and process for all IETF operations. Section three then encompasses a review of all of the uses of the terms fair and open in RFC2026 and its meaning and effect in these sections of the Standards Track BCP that RFC2026 is. 4.1 RFC2026 - SS 1.2 the Internet Standards Process In RFC2026 SS1.2 we find: The goals of the Internet Standards Process are: o technical excellence; o prior implementation and testing; o clear, concise, and easily understood documentation; o openness and fairness; and o timeliness. The procedures described in this document are designed to be fair, open, and objective; to reflect existing (proven) practice; and to be flexible. o These procedures are intended to provide a fair, open, and objective basis for developing, evaluating, and adopting Internet Standards. They provide ample opportunity for participation and comment by all interested parties. At each stage of the standardization process, a specification is repeatedly discussed and its merits debated in open meetings and/or public electronic mailing lists, and it is made available for review via world-wide on-line directories. In the opening of SS 1.2 which describes the standards process at the highest levels, the use of the terms ôopen and fairö in describing the IETFÆs Standards Process and organizational platform. Glassey Informational û 12/2003 2 draft-glassey-fairopen2026-00.txt 07-2003 Notice that in the context stated these terms are clearly meant to set a paradigm where all of the components of the process are known and available to all, and that all are accorded the same access and capabilities within the IETFÆs organization, WGÆs and before the IESG with regard as to whether their initiatives have completed the stepwise milestones necessary for advancement to their next stage. 4.2 RFC2026 - SS 6.5 Conflict Resolution and Appeals In Section 6.5 we find also statements on the requirements in dispute resolution for open and fair processes as demonstrated by the following excerpt Disputes are possible at various stages during the IETF process. As much as possible the process is designed so that compromises can be made, and genuine consensus achieved, however there are times when even the most reasonable and knowledgeable people are unable to agree. To achieve the goals of openness and fairness, such conflicts must be resolved by a process of open review and discussion. This section specifies the procedures that shall be followed to deal with Internet standards issues that cannot be resolved through the normal processes whereby IETF Working Groups and other Internet Standards Process participants ordinarily reach consensus. Part of the high level problem these words create is that the IETF has here a mandate to create a process where conflicts arise in as few instances as possible. What this means is that ultimately since todayÆs WGÆs only support the ôconstituencyö of one standard initiative per type, there must be a formal method of an incumbent protocolÆs being replaced, not just revised. Otherwise this mandate eliminates any possible operating models where only a single discipline or initiative is accepted in a WG. 4.2.1 SS 6.5.2 û Process failures While the process Failures section means well, it has a couple of fundamental paradoxes which render it almost non-functional. 6.5.2 Process Failures This document sets forward procedures required to be followed to ensure openness and fairness of the Internet Standards Process, and the technical viability of the standards created. The IESG is the principal agent of the IETF for this purpose, and it is the IESG that is charged with ensuring that the required procedures have been followed, and that any necessary prerequisites to a standards action have been met. This first paragraph of SS 6.5.2 defines the totality of the IESGÆs responsibility and the breadth of its reasonable actions. Glassey Informational û 12/2003 3 draft-glassey-fairopen2026-00.txt 07-2003 The IESG is constrained like the IETF in producing a set of reports on the status of any initiative as to whether they have met all the standards requirements as defined herein and if so the issuance of the standard will proceed. If not, when those issues that have not been addressed are, the IESG will then escalate the initiative to the next step of the standards process. If an individual should disagree with an action taken by the IESG in this process, that person should first discuss the issue with the ISEG Chair. If the IESG Chair is unable to satisfy the complainant then the IESG as a whole should re-examine the action taken, along with input from the complainant, and determine whether any further action is needed. The IESG shall issue a report on its review of the complaint to the IETF. In traditional audit models this circumstance, an instance where the IESG Chair was petitioned to resolve a dispute with a decision they (as the IESG chair) were personally a part of, would be noted as a clear conflict of interest. Another interesting constraint here is that the IESG chair by themselves is not capable of resolving issues of failures in the IESGÆs performance, and by any sane mind would be seen as adversarial since what was being disagreed with was the IESGÆs actions in the first place. Should the complainant not be satisfied with the outcome of the IESG review, an appeal may be lodged to the IAB. The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing and report to the IETF on the outcome of its review. So we see here that the IAB may æresolve the matterÆ in a method of its choosing, but the problems are that the IAB cannot resolve the matter at all, only recommend a resolution therein. Read onà If circumstances warrant, the IAB may direct that an IESG decision be annulled, and the situation shall then be as it was before the IESG decision was taken. Which means a ôbad decisionö can be reversed, but this only works when an initiative is pointedly past over inside the Standards Track. It has no effect on the prevention of malfeasance in the standards process being used to inhibit any one initiativeÆs advancement or initial submission. The IAB may also recommend an action to the IESG, or make such other recommendations as it deems fit. The IAB may not, however, pre-empt the role of the IESG by issuing a decision, which only the IESG is empowered to make. Which effectively is to say, that the IAB may not force the IESG to accept an initiative. And that the IESG still has the last word in what is and is not an Internet Standard no matter what the IAB Glassey Informational û 12/2003 4 draft-glassey-fairopen2026-00.txt 07-2003 sayÆs, so in reality there is arguably no escalation or adjudication of complaints functionally beyond the IESG in this model. This is further supported in the last paragraph wherein we see: The IAB decision is final with respect to the question of whether or not the Internet standards procedures have been followed. What this last paragraph effectively puts in place is a model where the decision of the IAB cannot actually effect the outcome of the IESGÆs efforts or intent with regard to this initiative is final? Which means exactly what to the bigger picture? This is a process question that must be asked and answered to fully understand if the dispute resolution process has any possibility of actually working and working fairly in all situations. 4.2.2 SS 6.5.3 û Questions of Applicable Procedure In 6.5.3 û Questions of Applicable Procedure we see the ôlast chanceö in the dispute resolution process. The text reads as follows: Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Effectively the above paragraph allows one ôfinal bite at the appeals appleö by challenging the underlying process as faulty. What has to happen in this instance is that one would have to prove that the process(es) in question are invalid or have flaws such that one of the key goals was not possible to implement, like being fair and open for instance. Claims on this basis may be made to the Internet Society Board of Trustees. The above sentence specifies that claims are to be submitted to the Board of trusteeÆs, but it doesnÆt specify what is to be submitted or to whom the actual service happens. Or moreover what will satisfy the required form of service. The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. Glassey Informational û 12/2003 5 draft-glassey-fairopen2026-00.txt 07-2003 The above paragraph segment states that the president of the ISOC will acknowledge the appeal within two weeks and at that time advise the appellant of the time frame for the presentation and review of the appeal. What is missing again is any semblance of a description of what the appeal process actually entails other than the Board of trusteeÆs meeting to do some magic, one would think. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute. Here again there is ambiguity as to the ôwhatö and the ôhowö of the review process, such that this section of RFC2026, V3 is probably of very limited value if its possible to implement at all. 4.3 The Cost of participating As a side note, we also in SS 1.2 find a formal acknowledgement of the cost of participating and some hints to the financial value of an IETF Internet Standards Process in the following excerpts àThe goal of technical competence, the requirement for prior implementation and testing, and the need to allow all interested parties to comment all require significant time and effortà àThe process is believed to be as short and simple as possible without sacrificing technical excellence, thorough testing before adoption of a standard, or openness and fairness. The commitment of ôsignificant time and effortö has an obvious financial cost, so there is a clearly identifiable costing to the participation in the IETF whether its just working on its mailing lists or its standards in general. Glassey Informational û 12/2003 6 draft-glassey-fairopen2026-00.txt 07-2003 5. The Term ôFairö The term Fair is used in both an adjective and adverb form in RFC2026. Its intent is to mandate that all processes and procedures be ôequal for allö and ôthat all players and initiatives get an equal opportunityö within the IETFÆs Standards Process and Community. The term ôfairö is one of the conceptual cornerstones of the IETF process and must be an overriding principal in the qualification to all changes to the participation and governance models. To formally define the term fair we look to OxfordÆs Online Dictionary and find: ôFairö û Oxford Online Dictionary - http://dictionary.cambridge.org/define.asp?key=fair*1+0&dict=A fair (RIGHT) adjective treating someone in a way that is right or reasonable, or treating people equally and not allowing personal opinions to influence your judgment fairly (adverb) It's the responsibility of a judge to treat both sides fairly. 5.1 The Term ôFairö and its operational requirements. In order to be ôfairö all IETF processes must be available to all participants. This means that any individual can submit any protocol specification, BCP, or other informational disclosure to the IETFÆs publications and they, to be fair to all, must likewise publish the submittal, without exception. Anything less is a restraint of participation and may in fact cause irreparable harm to the parties and their intellectual properties and likewise expose the IETF and its ADÆs and WG Chairs potentially to being instrumental in causing tort damages. As a part of this embodiment of being fair, the IETFÆs management teams and governance working groups must add a test for compliance to being Fair and Open to each revision of the Governance Working Documents. Glassey Informational û 12/2003 7 draft-glassey-fairopen2026-00.txt 07-2003 6. The Term ôOpenö and its meaning, and operational requirements. In RFC2026, The term Open is used in both a adjective and adverb forms. It intent is to mandate that all processes and procedures be ôunhiddenö and ôavailableö to all participants. This term is also a conceptual cornerstone of the IETF process and must be an overriding principal in the qualification to all changes to the participation and governance models. open (NOT SECRET) adjective 1 not secret: There has been open hostility between them ever since they had that argument last summer. 2 honest and not secretive: He's quite open about his weaknesses. I wish you'd be more open with me, and tell me what you're feeling. She has an honest, open face. And openness noun [U] honesty: If these discussions are to succeed, we'll need openness from/on both sides. 6.1 Applying Fair and Open to the IETF standards process In RFC2026 we also see ss 9.2 with the following words with regards to variances in the general operations models set forth in the previous sections of RFC2026: 9.2 Exclusions No use of this procedure may lower any specified delays, nor exempt any proposal from the requirements of openness, fairness, or consensus, nor from the need to keep proper records of the meetings and mailing list discussions. Specifically, the following sections of this document must not be subject of a variance: 5.1, 6.1, 6.1.1 (first paragraph), 6.1.2, 6.3 (first sentence), 6.5 and 9. Which furthers serves to reinforce that the concepts of Fair and Open may not be abridged in any form within the IETFÆs processes, except by a vote of the standardÆs issuing committee, the IESGà making the concept of Open and Fair essentially a convenience instead of an ethical boundary. Glassey Informational û 12/2003 8 draft-glassey-fairopen2026-00.txt 07-2003 The real issues in moving forward are in addressing the requirements that any changes to the processes also meet an ôOpen and Fairö sniff test, prior to being implemented. This is critically true of IP and IPR efforts within the IETF and the larger ISOC as a whole. 7. Requirements Summary These words, open and fair, constrain a set of high level overriding requirements that all changes to the standards process and IETF IP Publishing mechanisms meet the requirements set forth in RFC2026 ss 9.2. 7.1 The IETF Standards Processes The net-net of these words are that if the IETFÆs standards process is to be fair and open it must be capable of allowing and supporting more than one protocol per technology or it must provide a formal manner for a challenging protocol to unseat and capture the status as ôthe IETF standardö for any given physical protocol or discipline, or the process becomes a ômonarchyö. 7.2 Publish all submittals As part of this fairness and openness, the IETF must accept and publish all submittals which are submitted in compliance with its publication requirements, i.e. that are properly formatted, pertinent to the IETFÆs mission, and properly IP-released, without fail. Any exceptions to this must come in the form of restraining orders or formal notices from the IETF counsel stating that this submittal cannot be accepted and then specifying the causes therein. 7.3 Equal access to vetting resources It must also subject each and every protocol effort to the same sets of diligence and vetting, and in all instances where the effort qualifies, the IETF and IESG staff must not æstand in the wayÆ of any initiative, else the IETF and its processes become adversarial in nature to anyoneÆs efforts that is not part æof the inner circleÆ so to speak. 7.4 Complaint(s) and Adjudication(s) Likewise in regards to complaints and adjudications of complaints issued on the IETFÆs actions, processes, conflicts within an Area or Working Group must also be addressed with openness and fairness. This means that complaints are heard in a timely manner and each one is formally addressed. Failing to meet this particular need may also open the IETF and its management staff and possibly also their sponsors to damage claims as well. Glassey Informational û 12/2003 9 draft-glassey-fairopen2026-00.txt 07-2003 8. Security Considerations The security and integrity of the IETFÆs processes are specifically what this I-D is about. 9. References 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3. Bradner, Scott ôThe Internet Standards Processö, Revision 3, RFC2026 V3, 1996. 4. Postel, J., "Internet Official Protocol Standards", STD 1, USC/Information Sciences Institute, March 1996. 5. Postel, J., "Introduction to the STD Notes", RFC 1311, USC/Information Sciences Institute, March 1992. 6. Postel, J., "Instructions to RFC Authors", RFC 1543, USC/Information Sciences Institute, October 1993. 7. Huitema, C., J. Postel, and S. Crocker "Not All RFCs are Standards", RFC 1796, April 1995. 9.1 Terms IETF Area: A management division within the IETF. An Area consists of Working Groups related to a general æarea of interestÆ such as routing. Area Director: The manager of an IETF Area. An Area is managed by one or two Area Directors who also serve as that AreaÆs voting representative to the IESG, the Internet Engineering Steering Group (IESG). Internet Architecture Board (IAB: An appointed group that assists in the management of the IETF standards process and serves as the final layer of dispute resolution services in maintaining the integrity of the IETFÆs processes. Glassey Informational û 12/2003 10 draft-glassey-fairopen2026-00.txt 07-2003 Internet Engineering Steering Group (IESG): A group comprised of the IETF Area Directors and the IETF Chair. The IESG is responsible for the direct management and operations of the IETF along with the IAB, and it serves as is the standards approval board for the IETF, and as the first layer of the IETFÆs oversight models. Working Group: An IETF group chartered by the IETF to work on a particular discipline, or specific specification, set of specifications, BCPÆs or other related topic. The formation of a working group involves the creation of a formal and sanctioned IETF initiative. IETF initiative: Any IPÆs submitted for consideration or as an IETF protocol effort, or as part of a vetting effort through its publishing services, as disclosed on any of its mailing lists under the IETF Note Well policy, or in any of the IETFÆs working groupÆs, meetings, or other formally operated forums. 10. Acknowledgments Gotta acknowledge Scott Bradner, Christian Huitma, Jon Postel, and of course the hundreds of others for their tireless work in starting and guiding the IETF through its growth and pain, which has gotten us to a point where real fair play rules are necessary! 11. Author's Addresses Todd Glassey TGC Menlo Park, Ca., 94025 Email: todd at glassey.com Glassey Informational û 12/2003 11 draft-glassey-fairopen2026-00.txt 07-2003 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Glassey Informational û 12/2003 12