[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 > > >
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Dave CROCKER
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Joe Touch
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Dave CROCKER
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Joe Touch
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… SM
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… John Levine
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Bob Hinden
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Ross Callon
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… John Levine
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Joe Touch
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… SM
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Brian E Carpenter
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Dave Thaler
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Frank Ellermann
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Frank Ellermann
- [rfc-i] Fwd: Re: Informational RFC to be: <draft-… Olaf Kolkman
- [rfc-i] Fwd: Fwd: Re: Informational RFC to be: <d… Scott O Bradner