My thoughts about the problems of the IETF

[Fred Baker]

At 04:11 PM 4/17/2003 -0400, Ralph Droms wrote:
>My understanding is that an AD does a preliminary review before
>the IESG sees a doc.  What is the AD looking for - editorial
>changes, fundamental problems with the protocol?

The AD is generally giving the document the most thorough review that the 
IESG will give it - other ADs will also make comments, but they won't 
generally even read the document until the shepherding AD advises them that 
it has met his or her muster.

So the issues that the AD is looking for are those mentioned in the 
appropriate place in RFC 2026. At the PS level, to name one, s/he is 
wondering whether he is prepared to make the following statement about the 
document: is it "generally stable", has it "resolved the known design 
choices", does any field experience exist, what is its probable operational 
effect, and what obvious "technical omissions" are there? If s/he believes 
that there are issues, s/he will send the document back to get fixed rather 
than forward it to the IESG.

A truly common technical omission is any serious consideration of security. 
Everyone yells in pain when this comes up, but frankly if the protocol 
provides a means for someone to hack your network or displays information 
that you didn't intend to be displayed, it is going to have to be fixed, 
and we are only discussing when that fix will happen. As a result, the AD 
often comes back with observations on that subject, and it is not uncommon 
for the working group to try to stare him or her down on it.

>4.1.1  Proposed Standard
>
>    The entry-level maturity for the standards track is "Proposed
>    Standard".  A specific action by the IESG is required to move a
>    specification onto the standards track at the "Proposed Standard"
>    level.
>
>    A Proposed Standard specification is generally stable, has resolved
>    known design choices, is believed to be well-understood, has received
>    significant community review, and appears to enjoy enough community
>    interest to be considered valuable.  However, further experience
>    might result in a change or even retraction of the specification
>    before it advances.
>
>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.  However, such experience is highly desirable, and will
>    usually represent a strong argument in favor of a Proposed Standard
>    designation.
>
>    The IESG may require implementation and/or operational experience
>    prior to granting Proposed Standard status to a specification that
>    materially affects the core Internet protocols or that specifies
>    behavior that may have significant operational impact on the
>    Internet.
>
>    A Proposed Standard should have no known technical omissions with
>    respect to the requirements placed upon it.  However, the IESG may
>    waive this requirement in order to allow a specification to advance
>    to the Proposed Standard state when it is considered to be useful and
>    necessary (and timely) even with known technical omissions.
>
>    Implementors should treat Proposed Standards as immature
>    specifications.  It is desirable to implement them in order to gain
>    experience and to validate, test, and clarify the specification.
>    However, since the content of Proposed Standards may be changed if
>    problems are found or better solutions are identified, deploying
>    implementations of such standards into a disruption-sensitive
>    environment is not recommended.