Re: draft-housley-two-maturity-levels-00

Scott Lawrence wrote:
> >   The main drawback of this would be
> > >  that a document would sometimes need to exist for longer as an I-D while
> > >  implementations are developed, but balancing that is the fact that those
> > >  implementations would then inform the first RFC version rather than some
> > >  subsequent update, and it would be harder to get an RFC published for
> > >  something no one is really going to build.
> >      
On 2010-06-23 0:48, Russ Housley wrote:
> This would seem to encourage publication as Informational (perhaps on
> the Independent Submission Stream) as a first step.  I'm not sure that
> really reduces the work load, but it does shift it out of the standards
> track
I think that Experimental would be more appropriate, but (and I hate to 
bring this into it yet again because I agree that what Russ has 
suggested is a useful step and that we should not make the perfect the 
enemy of the better), I think that there is a more fundamental 'brand 
management' issue here that just must be faced:
Hardy anyone not active in the IETF (and apparently some who are) 
understands that there is a difference between the various document 
types (Informational, Experimental, Historical, and the different 
flavors of Standard Track) within the RFC series.  Product managers and 
customers rarely ask 'is this standards track in the IETF?'; they ask 
'is there an RFC for this?'.
I think that a different numbering series needs to be created so that 
'RFC' means what most people (incorrectly) think that it means now: that 
something is a standard that has passed the IETF review and approval 
process.  Only standards track documents should get an RFC number, and 
all others (Informational, Experimental, Historic, and any other 
archival documents we invent that are not standards track) should get 
numbers in this new series (IAP - Internet Archived Publication ?) 
instead.  Yes, I know that the 'STD' and/or 'BCP' numbering schemes were 
supposed to do something of this kind, but they are 1) not understood at 
all outside the IETF, and 2) not really archival, since what they point 
to can change (which from an implementation and conformance point of 
view actually makes them less useful, I think).
Many people don't even make a distinction between an I-D and an RFC, 
despite the plain boilerplate text in every I-D that explains it; once 
upon a time, the fact that an I-D disappeared helped, but the web and 
search engines demolished the practical difficulty of that years ago.  
This argues that making the distinction I suggest may be futile, but I 
still think that it's important.
There are a lot of people out there that think 'RFC' means something 
that it actually does not, and I think we have established that we can't 
change this misconception, so I think we should just agree that from now 
on that's what it means, and create one or more new labels to mean other 
things.


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf