[rfc-i] comment: draft-iab-streams-headers-boilerplates-05.txt

[Olaf Kolkman]

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-  
>>> related
>>> 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  
>> doing
>> 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- 
> related
>      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".
>
> +1
>

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  
rathole...

>
>>> For other categories  This document is not an Internet Standards  
>>> Track
>>> 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  
> to
>    perform some operations or IETF process function.  These RFCs form
>    the specification has been adopted as a BCP"
>
> and:
>
>   "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  
> process
>    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."
>
> and
>
>   "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







-----------------------------------------------------------
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...
Name: PGP.sig
Type: application/pgp-signature
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