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

sob at harvard.edu (Scott O Bradner) Thu, 29 September 2011 13:08 UTC

From: "sob at harvard.edu"
Date: Thu, 29 Sep 2011 09:08:19 -0400
Subject: [rfc-i] Fwd: Fwd: Re: Informational RFC to be: <draft-irtf-asrg-bcp-blacklists-10.txt>
References: <mailman.16.1317147172.2381.rfc-interest@rfc-editor.org>
Message-ID: <A850665A-F1EA-48EA-B505-49FB695CFF96@harvard.edu>

resend

> On Sep 27, 2011, at 12:30 PM, Dave CROCKER wrote:
> 
>> Folks,
>> 
>> This note raises an interesting cross-stream issue.  The IESG is being entirely polite and formally appropriate, IMO, but I think the issue they raise is fundamental.
>> 
>> While streams do need reasonable independence from each other -- I'm relatively less worried about "end run" efforts to bypass the standards process than most folks seem to be -- I do think that RFCs from non-IETF tracks need to be particularly careful to avoid language and labels that create confusion with our actual standards process.
>> 
>> As such, I think that non-IETF streams MUST NOT:
>> 
>>  1.  Claim to follow RFC 2026 (The Internet Standards Process -- Revision 3)
> 
> not so clear - some non-IETF IDs were IETF IDs earlier in life (e.g. proposals that did
> not get consensus and are being published as part of the record)
> 
>> 
>>  2.  Claim to conform to  RFC 2119 (Key words for use in RFCs to Indicate Requirement Levels)
> 
> 
> not so easy - see RFC 2418 the end of section 1
> the terms can still be useful
> 
>> 
>>  3.  Have a title that asserts that the document is a standard or BCP
> 
> fully agree
> 
>> 
>> Thoughts?
> 
> I hope so
> 
> Scott
> 
>> 
>> d/
>> 
>> -------- Original Message --------
>> Subject: Re: Informational RFC to be: <draft-irtf-asrg-bcp-blacklists-10.txt>
>> Date: Tue, 27 Sep 2011 07:45:02 -0700
>> From: The IESG <iesg-secretary at ietf.org>
>> To: irsg at irtf.org
>> CC: johnl at iecc.com, iana at iana.org, The IESG <iesg at ietf.org>, ietf-announce at ietf.org
>> 
>> The IESG has no problem with the publication of 'Overview of Email DNSBL
>> Best Practise' <draft-irtf-asrg-bcp-blacklists-10.txt> as an
>> Informational RFC.
>> 
>> The IESG wants to make the IRSG aware of its concern that there is
>> a potential for confusion between the IETF "Best Current Practice" (BCP)
>> series and the use of the term "Best Practise" in the title and the abstract
>> as well as the use of the acronym "BCP" in the page header of each
>> page and in sections 1.2 and 3.6. Anything that the IRSG can do to
>> avoid this confusion would be appreciated.
>> 
>> The IESG would also like the IRSG to review the comments in
>> the datatracker
>> (http://datatracker.ietf.org/doc/draft-irtf-asrg-bcp-blacklists/) related
>> to this document and determine whether or not they merit incorporation
>> into the document. Comments may exist in both the ballot and the comment
>> log.
>> 
>> A URL of this Internet Draft is:
>> http://datatracker.ietf.org/doc/draft-irtf-asrg-bcp-blacklists/
>> 
>> The process for such documents is described at
>> http://www.rfc-editor.org/indsubs.html
>> 
>> Thank you,
>> 
>> The IESG Secretary
>> 
>> 
>> 
>> 
>> Technical Summary
>> 
>>  The rise of spam and other anti-social behavior on the Internet has
>>  led to the creation of shared DNS-based lists ("DNSBLs") of IP
>>  addresses or domain names intended to help guide email filtering.
>>  This memo summarizes guidelines of accepted best practise for the
>>  management of public DNSBLs by their operators as well as for the
>>  proper use of such lists by mail server administrators (DNSBL users),
>>  and it provides useful background for both parties.  It is not
>>  intended to advise on the utility or efficacy of particular DNSBLs or
>>  the DNSBL concept in general, nor to assist end users with questions
>>  about spam.
>> 
>> Working Group Summary
>> 
>>  This document is a product of the Anti-Spam Research Group and
>>  represents the consensus of that group.
>> 
>> Document Quality
>> 
>>  This document is a research publication of the IRTF.
>> 
>> Personnel
>> 
>>  Pete Resnick <presnick at qualcomm.com> is the responsible Area Director.
>> 
>> IESG Note
>> 
>>  The IESG has concluded that this work is related to IETF work done
>>  in the MARF WG and the as-yet-unchartered REPUTE BOF, but this relationship
>>  does not prevent publishing.
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce at ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> 
>> 
>> -- 
>> 
>> Dave Crocker
>> Brandenburg InternetWorking
>> bbiw.net
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 
> 
>