Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Julian Reschke wrote: ... In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, and I have updated my document with the current changes; see http://tools.ietf.org/html/draft-reschke-hab-01, in particular http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt (diffs). ... I just heard that the RFC 5741-to-be is not going to be fixed with respect to the stutter in the boilerplate, such as in: -- snip -- 3.1.6.2. Text of 'Status Of This Memo' This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc. -- snip -- (see http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2). This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Julian, You wrote: This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? We are at a point where making trivial changes to headers and boilerplates leads to discussion about more substantive matters and causes even more delay, folk wanted it done. It is unfortunate that the stutter (I agree its there and that its ugly) remains in the document. Headers and boilerplates lives on this tangent between community wishes, RFC oversight, and RFC Editor series continuity and style. Having learned from getting HB done, I believe that in the future such efforts should be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor input. FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. --Olaf [top-post, full context below.] On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote: Julian Reschke wrote: ... In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, and I have updated my document with the current changes; see http://tools.ietf.org/html/draft-reschke-hab-01, in particular http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt (diffs). ... I just heard that the RFC 5741-to-be is not going to be fixed with respect to the stutter in the boilerplate, such as in: -- snip -- 3.1.6.2. Text of 'Status Of This Memo' This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc. -- snip -- (see http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2). This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? Best regards, Julian ___ rfc-interest mailing list rfc-inter...@rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
On 2009-12-22, at 04:57, John C Klensin wrote: Let me say this a little more strongly. This proposal effectively modifies RFC 5321 for one particular domain name at the same time that it effectively (see notes by others) advocates against coding the relevant domain name into anything or treating it in a special way. That combination doesn't seem to me to work. If that's the consensus of SMTP experts, then I would be more than happy to rip that example out (or the whole section, to be honest). I was quite enthusiastic about the previous revision's conscious decision not to include examples at all. Incidentally, the other stories remark in the subject line was a reference to the fact that the document instantiates a registry which can be used by others to document particular characteristics of records in the ARPA zone. It wasn't intended to refer to the examples section (which, as I mentioned, was added only recently). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
Hi Olafur, At 21:22 21-12-2009, Olafur Gudmundsson wrote: Correction the message should have been: http://www.ietf.org/mail-archive/web/ietf/current/msg59761.html The changes that Ted Hardie asked for does not address my concern as my comment was about the example in Section 3: Installing an MX record whose RDATA includes SINK.ARPA in the EXCHANGE field ([RFC1034]) should cause compliant MTAs to make no connection: SINK.ARPA does not exist, and A and records should not be used when an MX record is present. I am aware of the operational angle and that the above has been on the SMTP shopping list for some time. I am not sure whether it solves the problem instead of the symptom. I won't suggest an informative reference to RFC 1882. :-) If SMTP is to be the topical example, you may wish to get the draft reviewed by a mail-related working group. The shortest path would be to drop the first example. This draft requires IAB review and approval. The following paragraph may require some scrutiny: INVALID is poorly characterised from a DNS perspective in [RFC2606]; that is, the specification that INVALID does not exist as a Top Level Domain (TLD) is imprecise given the various uses of the term TLD in policy forums; Section 5.1 is quite a change compared to what is in Section 2.1 of RFC 3172. The existing text says: 'The arpa sub-domains are used for those protocol object sets defined as part of the Internet Standards Process [4], and are recommended to be managed as infrastructure protocol objects.' This proposal turns it into a registry of ARPA Reserved Names where the registration procedure is IETF Standards Action and IAB approval. Unless I missed something, there is a lack of clarity about what arpa sub-domains will be used for in future. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
On Mon, 21 Dec 2009, SM wrote: If I understood the story, it is to get compliant MTAs not to attempt mail delivery to domains which do not wish to accept mail. This does not really solve the implicit MX question but that's another story. The idea of using sink.arpa as an MX target (like the null MX proposal) is to define a conventional form of MX record that indicates a domain is not a valid mail domain. It solves the implicit MX problem for sites that use it, but obviously not for sites that don't. It's much cheaper to deploy than RFC 1864 (which specifies the SMTP 521 initial greeting). Here's some text from Section 5.1 of RFC 5321: [snip] As the intended status of this draft is BCP, it may have to take into consideration the above text from RFC 5321 and see how to resolve the issue. What issue? As far as I can tell there's no conflict between Joe's draft and RFC 5321, except that the choice of words in the example needs improvement. In particular, this sentence: Installing an MX record whose RDATA includes SINK.ARPA in the EXCHANGE field ([RFC1034]) should cause compliant MTAs to make no connection: SINK.ARPA does not exist, and A and records should not be used when an MX record is present. ought to be written: Installing an MX record whose RDATA includes SINK.ARPA in the EXCHANGE field ([RFC1035]) shall cause compliant MTAs to make no connection: SINK.ARPA does not exist, and A and records shall not be used when an MX record is present. so that it agrees with the strength of the RFC 2119 mustard in RFC 5321. Also the reference to RFC 1034 should be a reference to RFC 1035 since that is where the EXCHANGE field is specified. Note that any MX target domain name with no A or RRs will do the same job as sink.arpa or . (the dns root as proposed in the null MX draft); the advantage of a conventional name is that MTAs can skip the target address lookups since they already know the MX is unusable.. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
On 2009-12-22, at 11:33, SM wrote: This draft requires IAB review and approval. You'll note that we asked for it in section 6. The following paragraph may require some scrutiny: INVALID is poorly characterised from a DNS perspective in [RFC2606]; that is, the specification that INVALID does not exist as a Top Level Domain (TLD) is imprecise given the various uses of the term TLD in policy forums; Section 5.1 is quite a change compared to what is in Section 2.1 of RFC 3172. The existing text says: 'The arpa sub-domains are used for those protocol object sets defined as part of the Internet Standards Process [4], and are recommended to be managed as infrastructure protocol objects.' This proposal turns it into a registry of ARPA Reserved Names where the registration procedure is IETF Standards Action and IAB approval. Unless I missed something, there is a lack of clarity about what arpa sub-domains will be used for in future. The goal was to provide a set of additional requirements that the IAB would take into consideration when carrying out the duties as described in 3172. For example, some far future IAB might overlook that one obscure document amongst the 50,000 that exist specifies that SINK.ARPA should not exist, if that was the only place it was documented. The proposed IANA registry would be useful for such a future IAB in that it would list all the names that required special attention, together with a reference in each case to the document that described it. My reading of the text is consistent with the goal as described above. I would not object to further clarifying the goal by spelling out that the special criteria found via the new proposed registry do not trump the opinion of the IAB (i.e. the IAB can still say no, even if the criteria are all met). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Most bogus news story of the week
Given the circumstances, it is probably premature to assume that many ITU people are aware of the proposal at issue here, it indeed it is a formal proposal at all. On Mon, Dec 21, 2009 at 3:45 AM, Florian Weimer fwei...@bfk.de wrote: * Richard L. Barnes: Is this disingenuous or has the ITU really not heard of netflow? I can understand if people are not too happy with best-effort accounting and billing. -- Florian Weimer fwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
On Mon, Dec 21, 2009 at 11:14 PM, John C Klensin john-i...@jck.com wrote: Olafur, It seems to me that Ted's message asks for more clarity about what is being specified, actual review by email-related groups of email-related records and their implications, and so on. Certainly I agree with those requests and concerns. Your response is fine, except I have no idea what is actually going to get done, and what those reviews will produce, until I see the results. And those issues are sweeping enough that I really wish the Last Call would be terminated and restarted only when those reviews, and a document that reflects them, is in place. From that point of view, I'm objecting less to the content of this proposal (as far as it goes), but to the fact that the ducks don't seem to be lined up prior to its going out to IETF Last Call. The comments below are more substantive. Hi John, My take on this is that this idea is worth exploring, and this document can take us down the right road for that by adding the caching clarification and removing the examples. Removing the apparent force of the examples by clarifying that they indicate potential future lines of exploration rather than worked updates to the relevant standards also works for me. If we want to explore the idea in a .bogus.arpa subdomain rather than using sink.arpa, I don't think that's a big deal one way or the other. The real question for me is how do we get off the chicken-and-egg problem? If we have no document specifying the behavior of a guaranteed non-existent name, it is hard to get much actual deployment and experience, and I think that's what is required here. We may well find that this works in some contexts and fails utterly in others, based on the silly domain name tricks pulled on a per-application basis. But we can't find that out easily without an agreed upon way of trying this. Maybe that makes this an experiment; maybe it makes it a likely-to-be-ephemeral best current practice. But it does get the egg hatched, and that seems to be useful to me. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
On Mon, 21 Dec 2009, John C Klensin wrote: If implicit MXs continue to be permitted, this proposal, as I understand it, would not work. I believe it will work. RFC 5321 explains it twice: If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. If MX records are present, but none of them are usable, or the implicit MX is unusable, this situation MUST be reported as an error. If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any address RRs associated with that name unless they are located using the MX RRs; the implicit MX rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
At 05:50 22-12-2009, Tony Finch wrote: What issue? As far as I can tell there's no conflict between Joe's draft and RFC 5321, except that the choice of words in the example needs improvement. The wording in the draft is at odds with what is in RFC 5321. This can be discussed in the relevant working group. At 06:23 22-12-2009, Joe Abley wrote: On 2009-12-22, at 11:33, SM wrote: You'll note that we asked for it in section 6. Yes. The goal was to provide a set of additional requirements that the IAB would take into consideration when carrying out the duties as described in 3172. For example, some far future IAB might overlook that one obscure document amongst the 50,000 that exist specifies that SINK.ARPA should not exist, if that was the only place it was documented. The proposed IANA registry would be useful for such a future IAB in that it would list all the names that required special attention, together with a reference in each case to the document that described it. If that is the goal, the draft would have to register all the arpa sub-domains. My reading of the text is consistent with the goal as described above. I would not object to further clarifying the goal by spelling out that the special criteria found via the new proposed registry do not trump the opinion of the IAB (i.e. the IAB can still say no, even if the criteria are all met). The procedures for registration are documented in Section 2.1 and Section 3.0 of RFC 3172. You could reference those sections instead of having Section 5.0 and Section 5.1. The main parts of this draft are about the eternal non-existence of sink.arpa. If the examples are removed, there isn't any text that explains the operational utility. I am not arguing for keeping the examples. The operational utility could be addressed by a project similar to AS112. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
On Tue, 22 Dec 2009, SM wrote: At 05:50 22-12-2009, Tony Finch wrote: What issue? As far as I can tell there's no conflict between Joe's draft and RFC 5321, except that the choice of words in the example needs improvement. The wording in the draft is at odds with what is in RFC 5321. This can be discussed in the relevant working group. Which wording? Which working group? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
On 2009-12-22, at 18:32, SM wrote: At 06:23 22-12-2009, Joe Abley wrote: On 2009-12-22, at 11:33, SM wrote: The goal was to provide a set of additional requirements that the IAB would take into consideration when carrying out the duties as described in 3172. For example, some far future IAB might overlook that one obscure document amongst the 50,000 that exist specifies that SINK.ARPA should not exist, if that was the only place it was documented. The proposed IANA registry would be useful for such a future IAB in that it would list all the names that required special attention, together with a reference in each case to the document that described it. If that is the goal, the draft would have to register all the arpa sub-domains. Why? My reading of the text is consistent with the goal as described above. I would not object to further clarifying the goal by spelling out that the special criteria found via the new proposed registry do not trump the opinion of the IAB (i.e. the IAB can still say no, even if the criteria are all met). The procedures for registration are documented in Section 2.1 and Section 3.0 of RFC 3172. Section 2.1 and 3.0 deal with delegations. You could reference those sections instead of having Section 5.0 and Section 5.1. Not really, since the goal is to provide a framework for inserting other records into the ARPA zone apart from those associated with delegations. The main parts of this draft are about the eternal non-existence of sink.arpa. If the examples are removed, there isn't any text that explains the operational utility. I am not arguing for keeping the examples. The operational utility could be addressed by a project similar to AS112. The purposes of the document under review is described fairly succinctly in section 1: 1. to create a new IANA registry called ARPA Reserved Names (see Section 4); 2. to define the special considerations of a single name SINK.ARPA, a name which is defined never to exist (see Section 2); 3. to allow the procedures by which the ARPA zone is maintained, as documented in [RFC3172], to be modified for names present in the ARPA Reserved Names registry according to the special characteristics of those names (see Section 5). Which of those three purposes are you suggesting the AS112 project could help with? Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. Maybe we^H^Hthe IAB should have aimed at full delegation of the boilerplate, exactly as for the Trust-maintained boilerplate. For now, there are indeed weasel words such as: However, this is not intended to specify a single, static format. Details of formatting are decided by the RFC Editor. These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below. I think this gives the RSE, in conjunction with the tools maintainers, reasonable flexibility. I also note: The changes introduced by this memo should be implemented as soon as practically possible after the document has been approved for publication. which is presumably intended to allow the tools some time to catch up, again requiring RSE/tools coordination. Regards Brian Carpenter On 2009-12-22 23:50, Olaf Kolkman wrote: Julian, You wrote: This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? We are at a point where making trivial changes to headers and boilerplates leads to discussion about more substantive matters and causes even more delay, folk wanted it done. It is unfortunate that the stutter (I agree its there and that its ugly) remains in the document. Headers and boilerplates lives on this tangent between community wishes, RFC oversight, and RFC Editor series continuity and style. Having learned from getting HB done, I believe that in the future such efforts should be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor input. FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. --Olaf [top-post, full context below.] On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote: Julian Reschke wrote: ... In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, and I have updated my document with the current changes; see http://tools.ietf.org/html/draft-reschke-hab-01, in particular http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt (diffs). ... I just heard that the RFC 5741-to-be is not going to be fixed with respect to the stutter in the boilerplate, such as in: -- snip -- 3.1.6.2. Text of 'Status Of This Memo' This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc. -- snip -- (see http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2). This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? Best regards, Julian ___ rfc-interest mailing list rfc-inter...@rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ 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: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Dave: I agree with Birain's assessment. The RFC Editor can handle this issue without delaying publication of the document. Russ At 02:39 PM 12/22/2009, Dave CROCKER wrote: Brian, This seems worth being a bit pedantic about, to make sure we all share the same understanding: I take your interpretation to mean that the RFC Editor can, on their own initiative, fix the problem(s) that Julan has raised and that it does not require changes to the about-to-be-published document. Is that correct? Do others agree? (I hope so.) d/ On 12/22/2009 11:23 AM, Brian E Carpenter wrote: FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. ... For now, there are indeed weasel words such as: However, this is not intended to specify a single, static format. Details of formatting are decided by the RFC Editor. These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below. I think this gives the RSE, in conjunction with the tools maintainers, reasonable flexibility. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ rfc-interest mailing list rfc-inter...@rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
On Dec 22, 2009, at 12:08 PM, Russ Housley wrote: Dave: I agree with Birain's assessment. The RFC Editor can handle this issue without delaying publication of the document. +1 Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
At 11:05 22-12-2009, Joe Abley wrote: Why? Some future IAB would have a list of names and the appropriate reference. The purposes of the document under review is described fairly succinctly in section 1: 1. to create a new IANA registry called ARPA Reserved Names (see Section 4); 2. to define the special considerations of a single name SINK.ARPA, a name which is defined never to exist (see Section 2); 3. to allow the procedures by which the ARPA zone is maintained, as documented in [RFC3172], to be modified for names present in the ARPA Reserved Names registry according to the special characteristics of those names (see Section 5). Which of those three purposes are you suggesting the AS112 project could help with? None of the above. I said The operational utility could be addressed by a project similar to AS112 [1]. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg59778.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
All, I agree with Birain's assessment. The RFC Editor can handle this issue without delaying publication of the document. +1 Me too. Publish the RFC. Please. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
--On Tuesday, December 22, 2009 08:55 -0800 Ted Hardie ted.i...@gmail.com wrote: ... Hi John, My take on this is that this idea is worth exploring, and this document can take us down the right road for that by adding the caching clarification and removing the examples. Removing the apparent force of the examples by clarifying that they indicate potential future lines of exploration rather than worked updates to the relevant standards also works for me. Agreed. If we want to explore the idea in a .bogus.arpa subdomain rather than using sink.arpa, I don't think that's a big deal one way or the other. I guess the issue for me is that I want to see either (i) Exactly one name allocated, with no hand waving about registries and other, similar names. In other words, if someone later wants another allocated-but-not-delegated name, they go through exactly the same process as for this one, with the added obligation of having to justify another one to the community. (ii) A subtree delegation and setup, with a registry, but with the entries in that registry applying at the third level (e.g., sink.bogus.arpa.) and not as immediate subdomains of .ARPA. The real question for me is how do we get off the chicken-and-egg problem? If we have no document specifying the behavior of a guaranteed non-existent name, it is hard to get much actual deployment and experience, and I think that's what is required here. We may well find that this works in some contexts and fails utterly in others, based on the silly domain name tricks pulled on a per-application basis. But we can't find that out easily without an agreed upon way of trying this. Maybe that makes this an experiment; maybe it makes it a likely-to-be-ephemeral best current practice. But it does get the egg hatched, and that seems to be useful to me. I'm ok with this, but it seems to me that the document now does two things. One is to set up the experiment (or possibly long-term arrangement) that you describe above. Another is to set up a registry that would make little sense unless it had multiple names in it and a mechanism for populating that registry. I'd like to either separate the two, move the registry down a level in the DNS, or both. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Document Action: 'EAP Authentication Using Only A Password' to Informational RFC
The IESG has approved the following document: - 'EAP Authentication Using Only A Password ' draft-harkins-emu-eap-pwd-12.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-harkins-emu-eap-pwd-12.txt Technical Summary This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. Working Group Summary This memo is not the product of any working group. It has been reviewed by several interested parties with relevant background. Document Quality This memo was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Internationalized Resource Identifiers (iri)
A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by January 12, 2010. Internationalized Resource Identifiers (iri) --- Last Modified: 12-12-2009 Current Status: Proposed Working Group Chair(s): TBD Applications Area Director(s): Lisa Dusseault lisa.dussea...@gmail.com Alexey Melnikov alexey.melni...@isode.com Applications Area Advisor: Alexey Melnikov alexey.melni...@isode.com Mailing Lists: TBD Description of Working Group: This working group will produce * A new version of RFC 3987: Internationalized Resource Identifiers (IRIs) using draft-duerst-iri-bis as the base * A new version of RFC 4395: Guidelines and Registration Procedures for New URI Schemes The new version of RFC 3987 may be split into separate documents, if, in the opinion of the chair(s), it would facilitate distribution of the workload and allow more focused reviews. For example, the following breakdown has been suggested: * Handling of Internationalized domain names in IRIs (BCP) * Internationalization Considerations in IRIs (guidelines for BIDI, character ranges to avoid, special considerations) (BCP) * Syntax, parsing, comparison of IRIs (Standards track) The working group starts with a relatively mature update to RFC 3987 in preparation; the primary focus of the group is to resolve conflicting uses, requirements and best practices for internationalized URLs/URIs/IRIs and various other forms, among many specifications and committees, while moving toward consistent use of IRIs among the wide range of Internet applications that use them. In particular: * The IRI specification(s) must (continue to) be suitable for normative reference with Web and XML standards from W3C specifications. The group should coordinate with the W3C working groups on HTML5, XML Core, and Internationalization, as well as with IETF HTTPBIS WG to ensure acceptability. * The IRI specification(s) should be follow best practices for domain names. The group should coordinate with the IETF IDNABIS working group and Unicode Consortium to assure acceptability. * Explicit review by experts on (and native speakers) of RTL languages, of the recommendations for BIDI languages, is required. The Working Group will examine at least one and possibly more URI/IRI schemes to check that the new specification(s) are appropriate for existing schemes. Schemes suggested for review include http:, pop:, imap:, xmpp:, mailto:, and sip:. Changes to RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax) are explicitly out of scope of this charter, and may only be considered with a charter update. Goals and Milestones: January 2010 Additional update of Internet drafts by editor(s) February 2010 Review of Internet Drafts, directions during W3C and IETF May 2010 Working group Last Call of all documents June 2010 Publish IRI documents as RFCs (BCP, standards track, as appropriate) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Messaging Abuse Reporting Format (marf)
A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by January 12, 2010. Messaging Abuse Reporting Format (marf) --- Last Modified: 12-21-2009 Current Status: Proposed Working Group Chair(s): TBD Applications Area Director(s): Lisa Dusseault lisa.dussea...@gmail.com Alexey Melnikov alexey.melni...@isode.com Applications Area Advisor: Alexey Melnikov alexey.melni...@isode.com Mailing Lists: General Discussion: abuse-feedback-rep...@mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/abuse-feedback-report Archive: http://mipassoc.org/mailman/listinfo/abuse-feedback-report Description of Working Group: Messaging anti-abuse operations between independent services often requires sending reports on observed fraud, spam virus or other abuse activity. A standardized report format enables automated processing. The Abuse Reporting Format (ARF) specification has gained sufficient popularity to warrant formal codification, to ensure and encourage future interoperability with new implementations. The primary function of this working group will be to solicit review and refinement of the existing specification. ARF was developed by a messaging trade organization independent of the IETF, and uses a format similar to a Delivery Status Notification (DSN, RFC3464) to report fraud, spam, viruses or other abusive activity in the email system. The basic format is amenable to processing by humans or software, with the latter requiring the format to be standardized, to permit interoperability between automated services, particularly without prior arrangement. ARF as initially defined is already in widespread use at large ISPs, so interoperability can be demonstrated. Some tools already exist for processing ARF messages, a few of which are open source. In order to preserve the installed base, the working group will make the minimum changes necessary to the existing specification and will seek to have backward compatibility. Furthermore, some extensions to the current proposal are of interest to the community, such as the means for an operator to advertise an email address to which abuse reports using ARF should be sent. The working group will take on the task of considering and specifying such a mechanism. The initial proposal is published as draft-shafranovich-feedback-report, and this will provide the working group's starting point. The working group should consider such factors as: * implementer experience * ability to achieve broad implementation and interoperability * existing uses of ARF * internationalization * ability to address broader use cases than may have be contemplated by the original authors * overlap with the INCH working group's work (e.g. RFC5070); it is unclear whether such overlap is appropriate or should be avoided Thus, the working group's specific tasks are as follows: 1) The group will first produce a Proposed Standard track specification of ARF. This will document current use, removing any portions that are not implemented and/or not required for a minimum implementation (to be published later as extensions). This will include not only the format of an ARF message, but must also include appropriate documentation of security considerations and creation of IANA registries for elements of ARF to support future extensions, as well as informational sections conveying current best practices. 2) The group will specify the integration of ARF into DKIM DNS key records, with draft-kucherawy-dkim-reporting as its input. It contains extensions to DKIM that are related to ARF as a means of reporting DKIM-related failures which include phishing (fraud) and as such are relevant to the ARF effort. The group will produce Proposed Standard track specification for these ARF and DKIM extensions. 3) The group will finally consider a means for publishing the address to which ARF reports should be sent. Not all ARF participants wish to use abuse@(domain), which is the current standard (RFC2142) , as the place to send automated ARF-formatted reports. The group will either conclude that the industry should continue to use this de facto standard (and thus no specification is appropriate), or will produce a Proposed Standard track document identifying the means by which that address should be advertised. The group may consider re-chartering to cover related work, such as further extensions, once these deliverables have been achieved. The working group is aware of a related activity in another group: - Open Mobile Alliance http://www.openmobilealliance.org/ SpamRep The goal is to coordinate efforts with this group as required. Goals and Milestones: Jan 2010 Issue first WG-based Internet-Draft defining ARF Mar 2010
Protocol Action: 'IMAP4 Keyword Registry' to Proposed Standard
The IESG has approved the following document: - 'IMAP4 Keyword Registry ' draft-melnikov-imap-keywords-10.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-melnikov-imap-keywords-10.txt Technical Summary Over the years, some IMAP keywords (client-defined flags) have become de-facto standard, with some specific semantics associated with them. In some cases, different client implementors have defined and used keywords with different names, but the same semantics. Some server implementors decided to map such keywords to each other automatically in order to improve cross client interoperability. In other cases, the same keywords have been used with different semantics, causing interoperability problems. This document attempts to prevent further incompatible uses of IMAP keywords by establishing an IANA registry for IMAP keywords, and by allocating a special prefix for standardized keywords. Working Group Summary Nothing to note. This is a pretty straightforward creation of an IANA registry. Document Quality The registry is seeded with some keywords that are already in use in existing implementations. Experts to be Arnt Gulbrandsen and Dave Cridland (dave.cridl...@isode.com and a...@oryx.com) RFC Editor Note Note cross client in section 2 (across a line break) should be cross-client. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Multiple AoR reachabiliTy InformatioN Indication (martini)
A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Multiple AoR reachabiliTy InformatioN Indication (MARTINI) - Last Modified: 2009-12-08 Proposed Chair(s): Spencer Dawkins spen...@wonderhamster.org Bernard Aboba bernard_ab...@hotmail.com Real-time Applications and Infrastructure Area Director(s): Robert Sparks rjspa...@nostrum.com Cullen Jennings flu...@cisco.com Real-time Applications and Infrastructure Area Advisor: Cullen Jennings flu...@cisco.com Technical Advisor(s): Mailing Lists: General Discussion: mart...@ietf.org To Subscribe: martini-requ...@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/martini/index.html Description of Working Group The MARTINI working group is chartered to specify a means by which an entity that is authoritative for SIP URIs can dynamically register reachability information for multiple Addresses of Record (AORs) with a service provider. The SIP protocol [RFC 3261 and its extensions] supports multiple means of obtaining the connection information necessary to deliver out-of-dialog SIP requests to their intended targets. When a SIP Proxy needs to send a request to a target AOR within its domain, it can use a location service to obtain the registered contact URI, together with any associated path information [RFC 3327], and build a route set to reach the target UA(s). The SIP REGISTER method can be used to register contact URIs and path information. SIP-outbound [RFC 5626] enhances this mechanism to cater for UAs behind NATs and firewalls. When a SIP UA or Proxy needs to send a request to a target for which it is not authoritative, the UA/Proxy can use RFC3263 procedures for using DNS to resolve the next-hop connection information. In practice, many small and medium-sized businesses use a SIP-PBX that is authoritative for tens or hundreds of SIP AoRs. This SIP-PBX acts as a registrar/proxy for these AoRs for clients hosted by the SIP-PBX. UAs register with the SIP-PBX on behalf of the AoRs concerned. A SIP Service Provider (SSP) provides SIP peering/trunking capability to the SIP PBX. The SIP-PBX must be reachable from the SSP so that the SSP can route inbound SIP requests for the AoRs addressed to the SIP PBX, routing these requests to the SIP-PBX itself for onward delivery to registered UAs. Experience has shown that existing mechanisms are not always sufficient to support SIP-PBXs for small/medium businesses. Since a single SSP may support multiple thousands of such SMB SIP-PBX's, it is impractical and cost-prohibitive to manually provision their IP addresses in every SIP node along paths to those SIP-PBXs. Furthermore, IP addresses can be dynamically assigned and therefore can potentially change relatively frequently. In current deployments, dynamic reachability mechanisms based on the SIP REGISTER method are commonly used. Effectively, a single REGISTER request registers the AoR of the SIP-PBX, so that any out-of-dialog request targeted at a SIP URI for which the SIP-PBX is authoritative can be delivered from the SSP to the SIP-PBX. However, implementations of this mechanism vary in details, leading to interoperability issues between SIP-PBXs and SSPs, and the need for equipment to support different variants. The task of this working group is to to standardize a multiple-AoR registration mechanism for SIP that can be widely deployed by service providers at large scale. The solution will support AoRs with E.164 addresses at a minimum, although support for other classes of AoRs may be included. The solution will utilize existing SIP mechanisms to the extent possible, although it is anticipated that small protocol extensions are likely to be required, and hence a standards track (rather than BCP) deliverable is expected. The solution will accommodate existing SIP extensions relating to registration (e.g., Path, Service-Route [RFC 3608] and SIP-outbound) by ensuring that they are not precluded from use in the context of multiple AoR registrations. The solution will incorporate a compatibility mechanism to ensure a deterministic outcome when interworking with entities that do not support multiple AoR registration. The working group will coordinate with SIP Forum and other industry groups on requirements and will coordinate its work with other IETF working groups including DRINKS and SIPCORE. Goals and Milestones Dec 2009 Solicit solution-space drafts Jan 2010 Interim meeting Jan 2010 Adopt Working Group draft Feb 2010 First Working Group Last Call Mar 2010 Second Working Group Last Call Apr 2010 Multiple AoR Registration specification to IESG (PS) Jul 2010 Close or recharter working group ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-6man-iana-routing-header (IANA Allocation Guidelines for the IPv6 Routing Header) to Proposed Standard
The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'IANA Allocation Guidelines for the IPv6 Routing Header ' draft-ietf-6man-iana-routing-header-00.txt as 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 i...@ietf.org mailing lists by 2010-01-12. Exceptionally, comments may be sent to i...@ietf.org 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-6man-iana-routing-header-00.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19120rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
MARTINI Virtual Interim Meeting
What: MARTINI Virtual Interim Meeting January 7, 2010 from 11 AM - 1 PM Pacific Time Topics: - Discussions of currently deployed mechanisms for multiple AOR registration, and their pros and cons - Drafts describing solutions that (hopefully) improve upon existing deployed mechanisms Logistics: we'll request WebEx, so please watch the MARTINI mailing list at http://www.ietf.org/mail-archive/web/martini/current/maillist.html for logistic details ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
