[rfc-i] Fwd: Re: Informational RFC to be: <draft-irtf-asrg-bcp-blacklists-10.txt>

[Dave Thaler]

+1 to Brian's responses.

-Dave

> -----Original Message-----
> From: rfc-interest-bounces at rfc-editor.org [mailto:rfc-interest-bounces at rfc-
> editor.org] On Behalf Of Brian E Carpenter
> Sent: Tuesday, September 27, 2011 5:09 PM
> To: dcrocker at bbiw.net
> Cc: RFC Interest
> Subject: Re: [rfc-i] Fwd: Re: Informational RFC to be: <draft-irtf-asrg-bcp-
> blacklists-10.txt>
> 
> ...
> > As such, I think that non-IETF streams MUST NOT:
> >
> >    1.  Claim to follow RFC 2026 (The Internet Standards Process --
> > Revision 3)
> 
> More precisely - must not claim to be the result of the IETF process [BCP9].
> IRTF documents are supposed to be the result of the IRTF process, which is
> in fact [BCP8].
> 
> But they may claim to have followed a consensus process similar to the IETF
> process, even though [BCP8] specifically does not require consensus: "Since
> the products are research results, not Internet standards, consensus of the
> group is not required."
> The boilerplate variants suggested in [RFC4741] seem quite adequate to me.
> 
> >    2.  Claim to conform to  RFC 2119 (Key words for use in RFCs to
> > Indicate Requirement Levels)
> 
> I don't see why not. Many non-IETF documents claim to conform to  this;
> they are quite useful definitions for any technical specification, whatever its
> origin or status.
> 
> >
> >    3.  Have a title that asserts that the document is a standard or
> > BCP
> 
> I agree. I don't see any case in which "experimental specification" doesn't
> make more sense than "experimental standard" anyway, and BCP is a term
> of art in an RFC.
> 
> However, the draft in question specifically says "Best Practise"
> which is (a) a solecism and (b) not the same as "BCP".
> 
>    Brian
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest