Internet DRAFT - draft-glassey-fairopen2026
draft-glassey-fairopen2026
POISSON Todd Glassey
Internet Draft TGC
Document: <draft-glassey-fairopen2026-00.txt> 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
