[rfc-i] comment: draft-iab-streams-headers-boilerplates-05.txt
olaf at NLnetLabs.nl
Thu Jan 22 09:45:28 PST 2009
On Jan 16, 2009, at 11:47 PM, Dave CROCKER wrote:
> Thomas Narten wrote:
>>> Users of RFCs should be aware that while all Internet standards-
>>> documents are published as RFCs, not all RFCs are Internet
>>> standards-related documents.
>> I.e, one can certainly quibble today as to whether "all Internet
>> standards-related documents are RFCs". There are lots of other SDOs
>> things that very much relate to the Internet.
>> That said, I am not advocating we go down that rathole, as I don't
>> see a
>> simple fix.
> How about:
> Users of RFCs should be aware that while all IETF standards-
> documents are published as RFCs, not all RFCs are IETF standards.
While that would work in section 2 it would break consistency with the
rest of the document.
> But in following this list, there have been many times when I
>> think saying "IETF Standard" would have been a lot more precise than
>> "Internet Standard".
I agree with that but there is a reason to be consistent with the rest
of the terminology we've been using in the IETF for years.
In other words, I do want to keep this can of worms where it is, in a
>>> For other categories This document is not an Internet Standards
>>> specification; <it is published for other purposes>.
>> BCPs have always been sort of funny. Are they "Standards" or not?
> RFC 2026:
> "Some RFCs standardize the results of community deliberations about
> statements of principle or conclusions about what is the best way
> perform some operations or IETF process function. These RFCs form
> the specification has been adopted as a BCP"
> "5. BEST CURRENT PRACTICE (BCP) RFCs
> The BCP subseries of the RFC series is designed to be a way to
> standardize practices and the results of community deliberations."
> Historically Internet standards have generally been concerned with
> the technical specifications for hardware and software required for
> computer communication across interconnected networks.
> While these guidelines are generally different in scope and style
> from protocol standards, their establishment needs a similar
> for consensus building.
> on the other hand:
> "Not all specifications of protocols or services for the Internet
> should or will become Internet Standards or BCPs."
> "5.1 BCP Review Process
> Unlike standards-track documents, the mechanisms described in BCPs"
> Basically, we seem to make a distinction between "standard" and
> "standards-track", with a BCP qualifying as a kind of standard,
> albeit not one
> on the standards-track. Messy.
> Personally, I think it entirely accurate to call BCPs standards,
> because they
> make normative statements and they go through formal IETF approval.
> To me, that
> combination is the essence of the meaning standard.
> The fact that it is a one-step process, rather than multiple steps
> is important
> in terms of bookkeeping but not in terms of a useful public view of
> IETF work.
That is a similar reasoning as I had when drafting that language.
Olaf M. Kolkman NLnet Labs
Science Park 140,
http://www.nlnetlabs.nl/ 1098 XG Amsterdam
NB: The street at which our offices are located has been
renamed to the above.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20090122/d8e0c2d8/PGP.bin
More information about the rfc-interest