IETF mission (RE: pausable explanation for the Document Series)

[John C Klensin]

--On Thursday, 05 June, 2003 12:33 +0200 Harald Tveit Alvestrand 
<harald at alvestrand.no> wrote:

>> Depends upon how you look at things.  I would say that the
>> more-core problem is that our quality control may be less
>> than ideal.  As the IETF is not a protocol enforcement
>> agency, what the industry does with what we make is beyond
>> our control, in my opinion.
>
> actually this comes back to the IETF mission statement
> thing....
>
> if the mission of the IETF is to "make the Internet work",
> with our particular task in pursuit of that mission being to
> "make high quality, timely standards for the Internet", then
> flaws in the standards that the industry runs on are signs
> that we haven't achieved our mission.
>...
> RFC 2026 invented the term "applicability statements" - that's
> a term that seems to have fallen by the wayside......

Actually, unless my memory has gone _very_ bad, we have had 
applicability statements as tools in the collection for a long 
time, certainly before 2026.  I think they were even called 
that.  We haven't used them very much because it has been 
extremely difficult to get energy and focus for those efforts -- 
they are hard to do, and rarely as rewarding as developing a 
technology standard.  Note that RFC 1122 and 1123 are definitely 
AS documents, as is RFC 1812.  If you go through the RFC list 
looking for the word "requirements", you will find it in several 
other places as the term is used by an AS in the 2026 sense.

The term "applicability statement" appears in RFC 2000 (and 
probably earlier, I haven't had time to go back through that 
thread).

<tirade>
The fact that these are hard to get done doesn't imply that we 
should have written them off, which we essentially have done... 
except by accident, when we call them something else.

We have created a lot of confusion by also using the term 
"requirements" to describe "things we really think this protocol 
ought to have in it".  We also devalued ASs by claiming, of 
late, that attempts at ASs must be published only as 
Informational, and then telling anyone who will listen that 
Informational documents don't count, despite the fact that 2026 
explicitly identifies them with standards track maturity levels. 
That doctrine has been imposed, and dropped, more or less at the 
convenience (I'm tempted to say "whim") of the IESG.  For 
example, using the definitions of 2026, RFC 3454 meets the 
criteria for an AS: it is a profile of an external standard that 
specifies how to use parts of that standard in the Internet and 
in other IETF protocols.  And it is definitely standards-track, 
but the term AS was never, as far as I know, used during its 
development or approval process.

Speaking of tools we have stopped using, section 3.3 of 2026 
describes requirement levels (formerly "status", see below) for 
documents -- required/ recommended/ elective/ limited use/ not 
recommended.   Those statements, or ones similar to them, should 
be (or should have been) much more important tools for vendors 
and others in determining what documents to use than the 
orthogonal standards-track maturity levels.  Before we dropped 
them --about the same time, if I recall, that we dropped the 
notion of conformity clauses in standards-track documents -- 
they appeared regularly and were attached to _every_ 
protocol-specifying RFC.   See 1083 for examples.

</tirade>

Incidentally, reading RFC 1083, especially section 2, can be 
very illuminating with regard to where some of 2026 ultimately 
came from.  Interestingly, it uses "proposed protocol", and not 
"proposed standard".   The term "standard" is introduced only at 
"draft", as in "draft protocol standard".   And it is very clear 
about what "draft" means in the context of the discussions 
recently on this list: "[This] draft standard state is 
essentially a warning to the community that unless an objection 
is raised or a flaw is found this protocol will become a 
'standard'".  I wonder whether we might have reduced some 
confusion had we preserved that particular distinction --not 
using the term "standard" at all to refer to proposed-level 
documents --in wording.

 regards,
    john