Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Hi. All of these questions have come up before on the various lists where this draft was developed, but I suppose it's worth going through them again. On the other hand, I have a few questions: the first one, why Proposed standard? Is it really a good idea to standardize these lists (most being badly managed)? Why not just Informational if we just want to document what people are doing? The decscription of IPv4 DNSBLs/DNSWLs and most of the description of domain DNSBLs document existing practice. There aren't any v6 DNSBLs yet, other than for testing, but there certainly will be, and my hope here is to preemptively nail down the bits that are arbitrary choices, e.g., the test addresses, so that software that uses v6 DNSBLs will continue to interoperate, and DNSBL users continue to be able to select the most effective lists by changing lines in a config file rather than reprogramming. Hence proposed standard. Second question, the document indeed standardizes many things which are not in common use but does not point towards a rationale, so some choices are puzzling. Why TXT records to point to an URL and not NAPTR? That's what nearly all DNSBLs do now. As the draft says in section 2.1, the contents of the TXT are useful to put into a 5xx SMTP rejection message or the report from a scoring spam filter. Is this because of current usage in DNSxL? If so, this should be noted. But why IPv6 lists use a A record and not a ? Because the value isn't an address, it's a 32 bit value typically interpreted as bitfields, which happens to be most easily transmitted in an A record. I've rewritten that part of the doc a few times trying to make that clear, but I'd be happy to accept language which makes it clearer. Incidentally, although it may still be the conventional wisdom in the IETF that DNSBLs don't work and aren't useful, in the outside world where 95% or more of mail is spam, they're essential tools to run a mail server. Although there are indeed lots of stupid DNSBLs, those aren't the ones that people use, and there are widely used ones that have vanishingly low false positive rates that let you knock out most of the spam cheaply so you can afford to do more expensive filtering on what's left. Spamhaus estimates, based on the systems that pay for their data feeds, that there are about 1.4 billion mailboxes whose mail is filtered using their lists, and they're the biggest but hardly the only popular high quality DNSBL. It's pretty clear that there are a lot more mail systems that do use DNSBLs than don't. R's, John PS: I noticed a buglet -- in section 5 it says that the apex of a DNSxL zone may have an A record that points to a web server that contains explanatory material. It should of course say A and/or record. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Fri, Nov 07, 2008 at 02:18:21PM -, John Levine [EMAIL PROTECTED] wrote a message of 55 lines which said: All of these questions have come up before on the various lists where this draft was developed, but I suppose it's worth going through That's the point of an IETF-Wide Last Call. I'm not a participant in the ASRG. Because the value isn't an address, it's a 32 bit value typically interpreted as bitfields, which happens to be most easily transmitted in an A record. I've rewritten that part of the doc a few times trying to make that clear, but I'd be happy to accept language which makes it clearer. After Each entry in the DNSxL MUST have an A record., add The A record MUST NOT be interpreted as an IPv4 address. It is an opaque value, whose presence simply means that the name or address queried is actually listed in the DNSxL. Incidentally, although it may still be the conventional wisdom in the IETF that DNSBLs don't work and aren't useful, No, it's just experience. The last funny case is inside France Telecom (French largest ISP) where one mail server refused another one because it was blacklisted :-) orange.net #4.0.0 X-SMTP-Server; delivery temporarily suspended: host relais-ias89.francetelecom.com[193.251.215.89] refused to talk to me: 450 4.7.1 Service temporarily unavailable; Client host [193.252.22.118] blockedusing Trend Micro Network Reputation Service. Please see http://www.mail-abuse.com/cgi-bin/lookup?ip_address=193.252.22.118; Mailfrom 193.252.22.118 deferred using Trend Micro Email Reputation database.Please see http://www.mail-abuse.com/cgi-bin/lookup?193.252.22.118 It should of course say A and/or record. Or use RFC 5321 vocabulary and write address record. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
After Each entry in the DNSxL MUST have an A record., add The A record MUST NOT be interpreted as an IPv4 address. It is an opaque value, whose presence simply means that the name or address queried is actually listed in the DNSxL. Seems reasonable. No, it's just experience. The last funny case is inside France Telecom (French largest ISP) where one mail server refused another one because it was blacklisted :-) Orange/Wanadoo/FT has a dreadful spam problem, so bad that I've locally had blacklist about half of their outbound mail servers. If the point of the blacklist entry in question was to keep spam out of recipients' mailboxes, it was probably doing what it was supposed to. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-dac-vbr (Vouch By Reference) to Proposed Standard
At 10:35 PM -0800 11/6/08, SM wrote: The IANA Considerations section is missing. I suggest registering the header as specified in RFC 3864. We purposely did not make this extensible in this document. From talking to many of the companies that would be certifiers, there was no interest in making the list extensible. One option is to litter the IANA web site with yet another registry that lists the values from the RFC that created the registry and nothing else, as is all too common. Instead, we thought it was better to leave out the registry; if someone has a good reason for adding a new value, they can write an RFC for it and create the registry at that time. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Stephane Bortzmeyer wrote: On Fri, Nov 07, 2008 at 02:18:21PM -, John Levine [EMAIL PROTECTED] wrote All of these questions have come up before on the various lists where this draft was developed, but I suppose it's worth going through That's the point of an IETF-Wide Last Call. I'm not a participant in the ASRG. Stephane, Your view of the role of IETF Last Call does not match my reading of RFC 2418, IETF Working Group Guidelines and Procedure: Last-Call is intended as a brief, final check with the Internet community, to make sure that no important concerns have been missed or misunderstood. The Last-Call should not serve as a more general, in-depth review. You seem to be calling for an in-depth review. Last Call gives the community a chance to actively put forward concerns, not to passively wait and require a detailed exposition by the working group. You note that you were not a participant. Yet that is exactly how someone who is concerned about the detailed history is supposed to obtain information about the detailed process (and affect its outcome.) Sometimes, specification do contain rationales. This is one of the things that distinguishes IETF specifications from most other standards groups. But there is no requirement for this in IETF documents. They are specifications, not tutorials. Incidentally, although it may still be the conventional wisdom in the IETF that DNSBLs don't work and aren't useful, No, it's just experience. The last funny case is inside France Telecom (French largest ISP) where one mail server refused another one because it was blacklisted :-) That's a problem with administration and operation, not with specification of the format. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Dave == Dave CROCKER [EMAIL PROTECTED] writes: Dave Stephane Bortzmeyer wrote: On Fri, Nov 07, 2008 at 02:18:21PM -, John Levine [EMAIL PROTECTED] wrote All of these questions have come up before on the various lists where this draft was developed, but I suppose it's worth going through That's the point of an IETF-Wide Last Call. I'm not a participant in the ASRG. Dave Stephane, Dave Your view of the role of IETF Last Call does not match my Dave reading of RFC 2418, IETF Working Group Guidelines and Dave Procedure: It seems quite clear to me that RFC 2418 does not apply at all to the output of an RG. From a process and consensus building standpoint, this last call needs to be treated the same as an individual submission, not WG output. RGs are not required to maintain the level of openness, minutes, etc that WGs do. Thus, they don't get the presumption of consensus that a WG does and the comments in 2418 about last calls do not apply. Even if a particular RG is open, it's still not a WG; just as we would expect input from an external organization to be treated through the individual process regardless of the openness of that organization, we should do the same for IRTF output. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-dac-vbr (Vouch By Reference) to Proposed Standard
The IANA Considerations section is missing. I suggest registering the header as specified in RFC 3864. We purposely did not make this extensible in this document. I think you're talking past each other here. I read SM's message as adding VBR-Info: to the list of known mail header lines here: http://www.iana.org/assignments/message-headers/perm-headers.html That seems reasonable. I agree (having talked to the same companies) that there is no point in making the header itself extensible at this point. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-dac-vbr (Vouch By Reference) to Proposed Standard
At 5:13 PM + 11/7/08, John Levine wrote: The IANA Considerations section is missing. I suggest registering the header as specified in RFC 3864. We purposely did not make this extensible in this document. I think you're talking past each other here. I read SM's message as adding VBR-Info: to the list of known mail header lines here: http://www.iana.org/assignments/message-headers/perm-headers.html sigh That's right, I misread SM's message. We'll include this in the next draft. Oh, and also fix the misspelling he found. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The purpose of a Last Call
Sam Hartman wrote: It seems quite clear to me that RFC 2418 does not apply at all to the output of an RG. Sam, I've looked around and the WG Guidelines doc happens to be the only place I could find that defines the purpose of a Last Call. The mere fact that the title of document is about working groups doesn't obviously limit the scope of that definition. Please explain. Perhaps there is documentation for the individual and RG avenues that I missed? From a process and consensus building standpoint, this last call needs to be treated the same as an individual submission, not WG output. RGs are not required to maintain the level of openness, minutes, etc that WGs do. Thus, they don't get the presumption of consensus that a WG does and the comments in 2418 about last calls do not apply. Even if a particular RG is open, it's still not a WG; just as we would expect input from an external organization to be treated through the individual process regardless of the As John said, there was quite a bit of history to this work. All of it entirely open. So I suspect this boils down to a question of whether there is a concern about actual history or formality of history, and whether you are suggesting that a Last Call for RG or Ind. Sub. carries an affirmative obligation for the submitters to provide a detailed review of the decision-making history for their work? Again: If someone sees a specific problem, presents it and explains why they think it is a problem, then having the submitters respond with details about the specific history of the relevant decision(s) makes complete sense. This, to me, is the essence of what a Last Call should deal with, no matter the source of the document. If, on the other hand, Last Call is an open invitation for an unbounded series of why did you make this decision? challenges, I'll ask you to explain how this is a community benefit, absent a broad consensus of concern, rather than its primarily serving to make the IETF approval process arbitrarily indeterminate. We have the real and concrete submission of a specification that documents existing practice and, so far, a solid demonstration of support for it. So what is the purpose of encouraging individuals to lodge open-ended challenges? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-behave-dccp-04
On Friday 07 November 2008 13:00:19 ext Christian Vogt, you wrote: Whether it's of any use depends on the connection model (or lack thereof) of the transport protocol. I don't want to presume that this would make sense for all future transport protocols. [...] I don't agree. A reason for recommending endpoint-independent mapping and filtering is to enable applications to refer each other to a host behind a NAT. This is desirable independent of the transport protocol. But whether this is useful depends on the transport protocol and/or connection model. It does help for unicast UDP (and UDP-Lite). It does help for TCP, only if simultaneous open is supported by the application, the operating system and the middleboxes. If does help for DCCP _only_ if the DCCP stack implements the simultaneous open option, which is _not_ in the baseline DCCP document. It does not help with, e.g. multicast UDP. It does not mean anything for port-less protocol, including ICMP, proto-41, etc. It is insufficient for SCTP. Who knows how it applies to would-be future transports? Besides, I think it's too late for a factorized BEHAVE specification. Good news: we have much of the baseline in the BEHAVE-UDP RFC. The other documents already borrow quite a lot from it, especially the general concepts and terminology. REQ-6: If a NAT includes ALGs, they MUST NOT affect DCCP. Make it even clearer: REQ-6: If a NAT includes ALGs, the ALGs MUST NOT affect DCCP. Right. -- Rémi Denis-Courmont Maemo Software, Nokia Devices RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Tue, Nov 04, 2008 at 10:59:46AM -0800, The IESG [EMAIL PROTECTED] wrote a message of 26 lines which said: - 'DNS Blacklists and Whitelists ' draft-irtf-asrg-dnsbl-07.txt as a Proposed Standard Well, it is certainly very important that the DNSxL are documented, given their widespread use. And the I-D is a good document. On the other hand, I have a few questions: the first one, why Proposed standard? Is it really a good idea to standardize these lists (most being badly managed)? Why not just Informational if we just want to document what people are doing? Second question, the document indeed standardizes many things which are not in common use but does not point towards a rationale, so some choices are puzzling. Why TXT records to point to an URL and not NAPTR? Is this because of current usage in DNSxL? If so, this should be noted. But why IPv6 lists use a A record and not a ? I am not aware of existing IPv6 lists so this cannot be the current usage? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-behave-dccp-04
Rémi - (2) On requirements 1 and 3: REQ-1: A NAT MUST have an Endpoint-Independent Mapping behavior for DCCP. REQ-3: If application transparency is most important, it is RECOMMENDED that a NAT have an Endpoint-independent filtering behavior for DCCP. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an Address-dependent filtering behavior. These requirements are general and not specific to DCCP. Would it make sense to specify them in a separate RFC for NATs in general, independent of any specific transport protocol? Whether it's of any use depends on the connection model (or lack thereof) of the transport protocol. I don't want to presume that this would make sense for all future transport protocols. [...] I don't agree. A reason for recommending endpoint-independent mapping and filtering is to enable applications to refer each other to a host behind a NAT. This is desirable independent of the transport protocol. (3) On requirement 6: REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP. This requirement is not 100% clear. I am assuming it means: If a NAT includes ALGs, the NAT MUST NOT affect DCCP packets that are processed by one of those ALGs. Suggest to reword the requirement in this way. This reads worse to me. An ALG cannot process DCCP packets if it does not affect in any way. There is already a IESG discuss on this. What about this? REQ-6: If a NAT includes ALGs, they MUST NOT affect DCCP. Make it even clearer: REQ-6: If a NAT includes ALGs, the ALGs MUST NOT affect DCCP. - Christian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Incidentally, although it may still be the conventional wisdom in the IETF that DNSBLs don't work and aren't useful, in the outside world where 95% or more of mail is spam, they're essential tools to run a mail server. Although there are indeed lots of stupid DNSBLs, those aren't the ones that people use, and there are widely used ones that have vanishingly low false positive rates that let you knock out most of the spam cheaply so you can afford to do more expensive filtering on what's left. Spamhaus estimates, based on the systems that pay for their data feeds, that there are about 1.4 billion mailboxes whose mail is filtered using their lists, and they're the biggest but hardly the only popular high quality DNSBL. It's pretty clear that there are a lot more mail systems that do use DNSBLs than don't. As an operator of a large mail domain, I'd like to reiterate John's comments above. DNSBLs work, are very cost (and computationally) effective, and are in widespread use. Regards Jason ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Nov 7, 2008, at 3:17 AM, Stephane Bortzmeyer wrote: On Tue, Nov 04, 2008 at 10:59:46AM -0800, The IESG [EMAIL PROTECTED] wrote a message of 26 lines which said: - 'DNS Blacklists and Whitelists ' draft-irtf-asrg-dnsbl-07.txt as a Proposed Standard Well, it is certainly very important that the DNSxL are documented, given their widespread use. And the I-D is a good document. On the other hand, I have a few questions: the first one, why Proposed standard? Is it really a good idea to standardize these lists (most being badly managed)? Why not just Informational if we just want to document what people are doing? Agreed. Second question, the document indeed standardizes many things which are not in common use but does not point towards a rationale, so some choices are puzzling. Why TXT records to point to an URL and not NAPTR? Is this because of current usage in DNSxL? If so, this should be noted. But why IPv6 lists use a A record and not a ? I am not aware of existing IPv6 lists so this cannot be the current usage? In putting together planning for IPv6 block-lists, one soon confronts the enormity of its potential data-set and the incredible complexity related to carrier grade NATs, tunneling protocols, and third-party translation services. :^( On the other hand, the DKIM signature domain and an accurate on- behalf-of value as a tuple offers a safer and simpler basis for acceptance with perhaps only a two order increase in the data-set. In today's budget cutting and tight schedules, even establishing a DKIM list is not easy where ADSP needs to be modified before this can happen. :^( Perhaps years from now, part of the overhead for sourcing from IPv6 will be to include DKIM signatures with accurate on-behalf-of values. The on-behalf-of values should be opaque in most cases. Today it would seem email wants to pretend to authenticate, rather than indicate what is actually authenticated, even when using opaque values. :^( It is seldom that a person's email-address represents the source of abuse. Instead, it is often the result of compromised systems somewhere in the message stream. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The purpose of a Last Call
On 11/7/08 at 9:38 AM -0800, Dave CROCKER wrote: Sam Hartman wrote: It seems quite clear to me that RFC 2418 does not apply at all to the output of an RG. I've looked around and the WG Guidelines doc happens to be the only place I could find that defines the purpose of a Last Call. The mere fact that the title of document is about working groups doesn't obviously limit the scope of that definition. Please explain. Perhaps there is documentation for the individual and RG avenues that I missed? http://tools.ietf.org/rfc/rfc4844.txt http://tools.ietf.org/id/draft-irtf-rfcs-03.txt We have (IMO) historically screwed up with regard to IRTF and individual documents and not given them a proper stream to the RFC Editor. The above documents are dealing with that problem. However, for this particular case, I'm with Sam: An IRTF document that is going into the *IETF* standards track is pretty much akin to an any other organizations documents going into the IETF standards track. It may be the case that the IETF and IRTF have a lot more sharing of resources and visibility, than say the IETF and ITU or IEEE, and therefore the hand-off should be quite a bit easier. However, there is no doubt that this is *different* than a WG handing off a document to the IESG for standards track approval. A WG has (ostensibly) been subject to the direct observation of an AD all along and therefore the IESG should have a pretty full understanding of the IETF-wide consensus that has built up around any document coming out of that WG by the time the Last Call comes around. That's not going to be the case for an IRTF (or individual or other external organization) document. Yes, this is a less-than-efficient use of IETF Last Call. But if you want to make efficient use of the process for an *IETF* standards track document, work on it in the IETF. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The purpose of a Last Call
Pete == Pete Resnick [EMAIL PROTECTED] writes: Pete http://tools.ietf.org/rfc/rfc4844.txt Pete http://tools.ietf.org/id/draft-irtf-rfcs-03.txt Pete We have (IMO) historically screwed up with regard to IRTF Pete and individual documents and not given them a proper stream Pete to the RFC Editor. The above documents are dealing with that Pete problem. As far as I can tell we're in agreement. Implicit in my comment was that this document was being published through the IETF stream. (I'll leave as an excersise for the pedants what happens if the IRTF tries to publish an informational document for the IETF stream.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The purpose of a Last Call
+1 If it's going to be an IETF Standard, it has to have IETF consensus. This seems consistent with the way individual (i.e., non-WG) submissions are handled through the IESG. Leslie. Pete Resnick wrote: On 11/7/08 at 9:38 AM -0800, Dave CROCKER wrote: Sam Hartman wrote: It seems quite clear to me that RFC 2418 does not apply at all to the output of an RG. I've looked around and the WG Guidelines doc happens to be the only place I could find that defines the purpose of a Last Call. The mere fact that the title of document is about working groups doesn't obviously limit the scope of that definition. Please explain. Perhaps there is documentation for the individual and RG avenues that I missed? http://tools.ietf.org/rfc/rfc4844.txt http://tools.ietf.org/id/draft-irtf-rfcs-03.txt We have (IMO) historically screwed up with regard to IRTF and individual documents and not given them a proper stream to the RFC Editor. The above documents are dealing with that problem. However, for this particular case, I'm with Sam: An IRTF document that is going into the *IETF* standards track is pretty much akin to an any other organizations documents going into the IETF standards track. It may be the case that the IETF and IRTF have a lot more sharing of resources and visibility, than say the IETF and ITU or IEEE, and therefore the hand-off should be quite a bit easier. However, there is no doubt that this is *different* than a WG handing off a document to the IESG for standards track approval. A WG has (ostensibly) been subject to the direct observation of an AD all along and therefore the IESG should have a pretty full understanding of the IETF-wide consensus that has built up around any document coming out of that WG by the time the Last Call comes around. That's not going to be the case for an IRTF (or individual or other external organization) document. Yes, this is a less-than-efficient use of IETF Last Call. But if you want to make efficient use of the process for an *IETF* standards track document, work on it in the IETF. pr -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Under no circumstances should any kind of Blacklists or Whitelists be accepted by IETF as standards-track documents. These lists are responsible for huge numbers of illegitimate delivery failures. We should no more be standardizing such lists than to be standardizing spam. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
DNSBLs work to degrade the interoperability of email, to make its delivery less reliable and system less accountable for failures. They do NOT meet the no known technical omissions criterion required of standards-track documents. The fact that they are widely used is sad, not a justification for standardization. As an operator of a large mail domain, I'd like to reiterate John's comments above. DNSBLs work, are very cost (and computationally) effective, and are in widespread use. Regards Jason ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-dac-vbr (Vouch By Reference) to Proposed Standard
Hi John, At 09:13 07-11-2008, John Levine wrote: I think you're talking past each other here. I read SM's message as adding VBR-Info: to the list of known mail header lines here: http://www.iana.org/assignments/message-headers/perm-headers.html Thanks, that's what I meant. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
--On Tuesday, 21 October, 2008 08:02 -0700 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IESG Procedures for Handling of Independent and IRTF Stream Submissions ' draft-housley-iesg-rfc3932bis-04.txt as a BCP Russ, Harald, and IESG, While the version listed in the Last Call was -04, I note that -05 has been posted and my comments are addressed to it. As a procedural observation, my recollection is that, for many years, the IESG has been discouraging posting of new versions of documents during Last Call, precisely to avoid confusion about which version to comment on. While this document is much improved from earlier versions, I believe it is not nearly ready for BCP publication. I see sweeping and more specific issues as well as several nits. Sweeping Issue: The assertion of harm is a very serious one. We claim that the Internet is incredibly robust and that there are few proposed changes that can actually cause significant damage. If the places in which harm is used in this document are really intended to mean contrary to the spirit of the IETF standards process or even damaging to the effectiveness of the standards process, then say that. Note that the first example in Section 4 is clearly about something that is problematic for the standards process with no need to believe that the alternate path is harmful to the Internet, while the second one falls into the category of an inappropriate extension (more discussion on that below). Even getting from hard-to-debug interoperability problems to harm to the Internet would be a stretch (if the authors had been able to produce a careful explanation of how to experiment with those bits in an escape-proof walled garden, the document might still describe a bad idea, but that would become a technical judgment --one that this document asserts the IESG is not supposed to make-- and it would not have been, a priori, harmful. I believe that the assertion of harm to the Internet is a sufficiently strong one that the IESG should not make it without clear evidence of community consensus, starting with an explanation of why it thinks there is a problem (nor merely asserting harm) and including an IETF-wide Last Call on the assertion and explanation. Specific Issues (1) The IESG should never make an assertion that is known to be false. This has been an issue since 3932 was published and then interpreted in a way that several of us did not anticipate; a revision should not require the IESG to lie (or continue lying). The fact is that, subject to publication delay, this document and RFC 4846 permit publication of documents considered by WGs and rejected. In addition, some Independent Submissions receive very extensive review in the IETF. I hope we are not moving into the sort of lawyer-land in which formally disclaiming knowledge --counter to observable fact that the knowledge exists-- may have a special meaning. Even if the IESG has not reviewed a document, it doesn't imply that the IETF has not. If we are not moving to that part of lawyer-land, then it may be appropriate to say that the IETF takes no position on whether a document meets certain criteria or that there was no determination of IETF consensus, but it is not appropriate to say that the IETF disclaims knowledge (or has no knowledge) without a case-by-case determination of whether any significant review within the IETF occurred. The third paragraph of the Introduction should be modified to change are not reviewed to are not required to be reviewed or equivalent. The second sentence of that paragraph should be removed entirely unless the IESG wants to deprive itself of flexibility to formally ask for community input by prohibiting the use of Last Calls on Independent Submission drafts (a flexibility that language in 4846 was intended to preserve). As a further example of this problem, consider the last paragraph of the Introduction, where the text talks about the IESG pushing a document into the Independent stream that had been submitted to the IETF. Such documents are often reviewed in the IETF before being called to the IESG's attention via a publication request and then presumably reviewed and discussed by the IESG (or at least parts of it). (2) The numbered list in Section 3 is the substantive core of this document. Harmful in Item 3 is potentially damaging to, or problematic for, the IETF Standards Process, not harmful to the Internet. Potentially is important there too. The IESG should not be expected to foretell possible futures or provide an analysis of how damage might occur: it should merely have to have a reasonable basis for believing that WG or other standards process disruption might occur or that an end-run is being attempted. Item 5, when read in the context of paragraph 5 of that section (The last two...) is a horse of a different color. Let me restate what is
Last Call: draft-ietf-geopriv-pdif-lo-profile (GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations) to Proposed Standard
The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations ' draft-ietf-geopriv-pdif-lo-profile-13.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-11-30. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-13.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=13287rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'A Hitchhiker's Guide to the Session Initiation Protocol (SIP)' to Informational RFC
The IESG has approved the following document: - 'A Hitchhiker's Guide to the Session Initiation Protocol (SIP) ' draft-ietf-sip-hitchhikers-guide-06.txt as an Informational RFC This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-06.txt Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are TO BE ADDED BY THE AD.' RFC Editor Note OLD Core: The essential SIP specifications that are expected to be utilized for every session or registration. NEW Core: The SIP specifications that are expected to be utilized for a wide variety of sessions or registrations. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-arkko-arp-iana-rules (IANA Allocation Guidelines for the Address Resolution Protocol (ARP)) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Allocation Guidelines for the Address Resolution Protocol (ARP)' draft-arkko-arp-iana-rules-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-12-05. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-arkko-arp-iana-rules-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17805rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'A Hitchhiker's Guide to the Session Initiation Protocol (SIP)' to Informational RFC
The IESG has approved the following document: - 'A Hitchhiker's Guide to the Session Initiation Protocol (SIP) ' draft-ietf-sip-hitchhikers-guide-06.txt as an Informational RFC This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-06.txt Technical summary. The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. Working group summary. There is strong consensus in the working group to publish this document. Document Quality This document is a summary or compendium of the IETF publications relating to SIP, and as such, contains no requirements or RFC 2119 language, and as such there is no requirement for implementation of this document. The document underwent thorough review by a number of experts in both working group last call, and through the RAI area review process. It should be noted that once published as an RFC, this is a document that will need to be regularly revised, as and when sufficient new SIP material is published to justify a new version. Personnel The document shepherd for this document was Keith Drage. The responsible Area Director was Douglas Adams with some procedural mistakes from Cullen Jennings. RFC Editor Note OLD Core: The essential SIP specifications that are expected to be utilized for every session or registration. NEW Core: The SIP specifications that are expected to be utilized for a wide variety of sessions or registrations. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
