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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf