Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Monday, May 20, 2013 06:44 -0700 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS' draft-jabley-dnsext-eui48-eui64-rrtypes-03.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 ietf@ietf.org mailing lists by 2013-06-17. 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. This is not my primary (or even secondary) area of expertise but, given that the RR space is not unlimited even though it is large, wouldn't it be better to have a single RRtype for IEEE-based EUIs with a flag or other indicator in the DATA field as to whether a 48 bit or 64 bit identifier was present? In addition to saving an RRTYPE slot, my recollection of the uses of EUI-64 is that an application trying to look up an EUI may not, in the general case, know whether the device and its EUI are of the 48 or 64 bit persuasions. If that is correct, a single RRTYPE and a length/type indicator in the DATA would avoid a two-stage lookup and/or unnecessary use of QTYPE=ANY. The same one RRTYPE model would, with even a modicum of good design, make transition easier when the IEEE goes interplanetary or interstellar and discovers a need for EUI-128 (or some other length 64). If there really are significant advantages to having two separate RRTYPEs that override the considerations above, it seems to me that the reasoning for doing so should at least be briefly explained in the document. john
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 5/20/13 7:18 AM, John C Klensin wrote: --On Monday, May 20, 2013 06:44 -0700 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS' draft-jabley-dnsext-eui48-eui64-rrtypes-03.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 ietf@ietf.org mailing lists by 2013-06-17. 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. This is not my primary (or even secondary) area of expertise but, given that the RR space is not unlimited even though it is large, wouldn't it be better to have a single RRtype for IEEE-based EUIs with a flag or other indicator in the DATA field as to whether a 48 bit or 64 bit identifier was present? the basis for assignment of rr-types is expert review. Whether the draft advances or not the rr-types have been assigned. http://tools.ietf.org/html/rfc6895#section-3.1.1 http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-3 In addition to saving an RRTYPE slot, my recollection of the uses of EUI-64 is that an application trying to look up an EUI may not, in the general case, know whether the device and its EUI are of the 48 or 64 bit persuasions. If that is correct, a single RRTYPE and a length/type indicator in the DATA would avoid a two-stage lookup and/or unnecessary use of QTYPE=ANY. The same one RRTYPE model would, with even a modicum of good design, make transition easier when the IEEE goes interplanetary or interstellar and discovers a need for EUI-128 (or some other length 64). If there really are significant advantages to having two separate RRTYPEs that override the considerations above, it seems to me that the reasoning for doing so should at least be briefly explained in the document. john
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Monday, May 20, 2013 07:53 -0700 joel jaeggli joe...@bogus.com wrote: ... This is not my primary (or even secondary) area of expertise but, given that the RR space is not unlimited even though it is large, wouldn't it be better to have a single RRtype for IEEE-based EUIs with a flag or other indicator in the DATA field as to whether a 48 bit or 64 bit identifier was present? the basis for assignment of rr-types is expert review. Whether the draft advances or not the rr-types have been assigned. http://tools.ietf.org/html/rfc6895#section-3.1.1 http://www.iana.org/assignments/dns-parameters/dns-parameters. xml#dns-parameters-3 Joel, I don't know who the current expert is and, for the moment, am glad I don't and don't intend to check. I believe there is broad consensus in the community that having something as significant as an RRTYPE documented in the RFC Series is a good idea. Certainly leaving the reference pointing, long-term, to an I-D would not be a good idea (and would violate several other principles). However, if (i) the expert review consists largely of making sure that the template contains the right information and the ducks are not obviously out of line rather than a design/architectural review with at least meaningful potential for community review of the request, and (ii) the response to a design/architectural concern raised during IETF LC is essentially too late, code points already allocated, and (iii) Proposed Standard still does not imply recommended and the alternative to approving the I-D for that category is non-publication, then I would like to understand, as a procedural matter, what the IETF Last Call is about. Certainly it is not for editorial review; that is the RFC Editor's job and there are, IMO, no glaring editorial problems. If the RRTYPEs have been allocated and can't be un-allocated and this is in use, then there is nothing to propose as an individual submission for standardization: an informational document to inform the community about what this is about would be both appropriate and sufficient. Beyond that, your shepherd's report implies that the issue I raised may have been discussed and successfully resolved in DNSEXT. If that is the case, an explanation in the document about the tradeoffs and decision would still be appropriate. Alternatively and especially if there wasn't clear consensus in DNSEXT, if this really is to be processed as a Proposed Standard, then a suggestion during IETF Last Call that the IETF Standard way to represent EUIs in the DNS should be a single RRTYPE with length/type information in the DATA is still in order: the community could reasonably conclude that the single RRTYPE is a better solution, that the single type should be allocated, and that these two types should be deprecated. We have certainly done similar things before with other protocols and parameters that were already in use before standardization was proposed from an individual submission. john p.s. I've tried reading your shepherd writeup now in three different browsers. It appears to be formatted for extremely long (paragraph-length) lines, with no provision for automatic wrapping to fit the page frame. That means that trying to read and understand it requires extensive horizontal scrolling, which is a fairly large impediment and, although I assume unintentionally, a way to discourage anyone but the most determined of readers from actually reading it. May I suggest that the IESG, on a priority basis, either get the format of those writeup pages changed so that they wrap appropriately or that it insist that writeups conform to RFC/I-D norms for line lengths.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On May 20, 2013, at 8:56 AM, John C Klensin john-i...@jck.com wrote: However, if (i) the expert review consists largely of making sure that the template contains the right information and the ducks are not obviously out of line rather than a design/architectural review with at least meaningful potential for community review of the request, and (ii) the response to a design/architectural concern raised during IETF LC is essentially too late, code points already allocated, and (iii) Proposed Standard still does not imply recommended and the alternative to approving the I-D for that category is non-publication, then I would like to understand, as a procedural matter, what the IETF Last Call is about. Whether or not the document clear enough for an implementor to create interoperable software from. That's what the IETF is supposed to be doing, yes? Certainly it is not for editorial review; that is the RFC Editor's job and there are, IMO, no glaring editorial problems. Correct. If the RRTYPEs have been allocated and can't be un-allocated and this is in use, then there is nothing to propose as an individual submission for standardization: an informational document to inform the community about what this is about would be both appropriate and sufficient. ...only if the authors don't care about interoperability between implementations. An author asking for IETF-wide review seems like something that should be encouraged, not pecked to death. --Paul Hoffman
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Hi John, On Mon, May 20, 2013 at 11:56 AM, John C Klensin john-i...@jck.com wrote: --On Monday, May 20, 2013 07:53 -0700 joel jaeggli joe...@bogus.com wrote: ... This is not my primary (or even secondary) area of expertise but, given that the RR space is not unlimited even though it is large, wouldn't it be better to have a single RRtype for IEEE-based EUIs with a flag or other indicator in the DATA field as to whether a 48 bit or 64 bit identifier was present? the basis for assignment of rr-types is expert review. Whether the draft advances or not the rr-types have been assigned. http://tools.ietf.org/html/rfc6895#section-3.1.1 http://www.iana.org/assignments/dns-parameters/dns-parameters. xml#dns-parameters-3 Joel, I don't know who the current expert is and, for the moment, am glad I don't and don't intend to check. I believe there is broad consensus in the community that having something as significant as an RRTYPE documented in the RFC Series is a good idea. Certainly leaving the reference pointing, long-term, to an I-D would not be a good idea (and would violate several other principles). There has been a long term fight to make RRTYPEs easy to get, a fight in which substantial victory has only recently been achieved (RFC6895). The result of tight control over RRTYPEs is that most new uses just take the path of least resistance and overload the TXT RRTYPE, something which requires no one's permission but, as per RFC 5507, has significant long term disadvantages. One lesson of the Internet has been the benefits of FREEDOM TO INNOVATE. In my opinion, most IETF WGs impose tighter control over code points that necessary most of the time (note most, not all). However, if (i) the expert review consists largely of making sure that the template contains the right information and the ducks are not obviously out of line rather than a design/architectural review with at least meaningful potential for community review of the request, and The guidelines are in RFC 6895 which I recommend you consult. There is no requirement for community review. A primary concern is that the RRTYPE can be safely handled an unknown RRTYPE (or is an ignorable meta RRTYPE). The community has people that will complain about and delay andy new RRTYPE. How is an RRTYPE any more earth-shaking than, say, an AFN number, a range of which are available on a first-come, first-served basis? What are these principles you refer to above that require RFC documentation of RRTPYEs when no documentation whatsoever is required for some AFN numbers? (ii) the response to a design/architectural concern raised during IETF LC is essentially too late, code points already allocated, and (iii) Proposed Standard still does not imply recommended and the alternative to approving the I-D for that category is non-publication, then I would like to understand, as a procedural matter, what the IETF Last Call is about. Certainly it is not for editorial review; that is the RFC Editor's job and there are, IMO, no glaring editorial problems. If the RRTYPEs have been allocated and can't be un-allocated and this is in use, then there is nothing to propose as an individual submission for standardization: an informational document to inform the community about what this is about would be both appropriate and sufficient. Perhaps it should be informational. I believe the author was originally going to submit as an Informational Independent submission. Others, including myself, suggested different paths. Perhaps we were mistaken. The perfect is always the enemy of the good. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Beyond that, your shepherd's report implies that the issue I raised may have been discussed and successfully resolved in DNSEXT. If that is the case, an explanation in the document about the tradeoffs and decision would still be appropriate. Alternatively and especially if there wasn't clear consensus in DNSEXT, if this really is to be processed as a Proposed Standard, then a suggestion during IETF Last Call that the IETF Standard way to represent EUIs in the DNS should be a single RRTYPE with length/type information in the DATA is still in order: the community could reasonably conclude that the single RRTYPE is a better solution, that the single type should be allocated, and that these two types should be deprecated. We have certainly done similar things before with other protocols and parameters that were already in use before standardization was proposed from an individual submission. john p.s. I've tried reading your shepherd writeup now in three different browsers. It appears to be formatted for extremely long (paragraph-length) lines, with no provision for automatic wrapping to fit the page
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Just on the writeup tooling question: p.s. I've tried reading your shepherd writeup now in three different browsers. It appears to be formatted for extremely long (paragraph-length) lines, with no provision for automatic wrapping to fit the page frame. That means that trying to read and understand it requires extensive horizontal scrolling, which is a fairly large impediment and, although I assume unintentionally, a way to discourage anyone but the most determined of readers from actually reading it. May I suggest that the IESG, on a priority basis, either get the format of those writeup pages changed so that they wrap appropriately or that it insist that writeups conform to RFC/I-D norms for line lengths. This happens in a number of places in the datatracker, and there's an open ticket for the tools team to make a general fix. In the meantime, we have to try to remember to put in line-breaks manually. When I encounter something that doesn't have them, I just copy/paste into my favourite local editor, and read it there. Barry
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On Fri, May 17, 2013 at 6:29 PM, Keith Moore mo...@network-heretics.comwrote: On 05/17/2013 04:36 PM, Yoav Nir wrote: On May 17, 2013, at 6:37 PM, Dave Crocker d...@dcrocker.net wrote: On 5/17/2013 7:01 AM, Keith Moore wrote: But WGs should be able to periodically summarize what they're doing - what problem they're trying to solve, what approach they're taking, what technologies they're using, what major decisions they've made, what the current sticking points seem to be, what problems are as yet unresolved, what potential for cross-group and cross-area effects have been identified, and what efforts have been made to get the affected parties in the loop. For most groups that summary should be maybe 2-3 pages. The ADs should be able to verify that those summaries are accurate and reasonably complete, or appoint a trusted WG observer other than the chair to review each summary. ADs and other members of the community should be able to view those summaries and comment on their accuracy. The idea that working groups should be required to issue periodic project progress reports seems strikingly reasonable and useful. This makes the folks who are the most knowledgeable responsible for assessing their work, and should facilitate public review. Recording the sequence of reports into the wg datatracker could nicely allow evaluating progress over time. It also, of course, nicely distributes the work. d/ From: WG Chair To: ietf@ietf.org Sunbject: Progress Report - Foo WG There has been zero activity on the FOO list in the last three months (except for that Fake Conference message everybody got last month). I've tried emailing the WG document authors twice, but they're not answering my emails. So, the WG has 2 documents: draft-ietf-foo-use-cases-03, and draft-ietf-foo-proto-01. The use case document is just about done, but we haven't really started discussing the proto document. We haven't met in Orlando, and are unlikely to meet in Berlin That's it for this report. Cheers WGC Instead of a WG progress report, what I had in mind was a separate report for each work item. The report should briefly describe 1. The purpose of the work being undertaken 2. A description of the work being undertaken (including mention of major technologies on which the work is based) 3. All known parties and interests likely to be affected by the work 4. The current state of the work (what's been done, what hasn't been done) 5. Any major issues that have been identified but not resolved 6. Pointers to the WG's charter, the datatracker pages for each of the current draft document(s) associated with that work item, and any other useful material (e.g. open issues list, summaries of design decisions already taken and the rationale for each) A person who is knowledgeable about current Internet protocols should be able to read that single document and understand what the WG is doing with this particular work item, what state it's in, whether or not it will affect that person's are of interest, and where to look for detailed information. This seems like a good idea, although maybe a bit formal. IMO, big surprises at the tail end that cause lots of work to be thrown out are evidence of a management failure. The IESG and WG chairs should be more proactive wrt/ avoiding late surprises from ever happening. I notice that nowhere on this list is any mention of the charter milestones or dates. Is the Foo Proto draft due in 14 months or is it 14 months behind schedule? If the latter, why isn't the Foo WG meeting at the IETF? Keith Andy
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On Fri, May 17, 2013 at 7:29 PM, Keith Moore mo...@network-heretics.comwrote: On 05/17/2013 10:21 PM, Andy Bierman wrote: I notice that nowhere on this list is any mention of the charter milestones or dates. Is the Foo Proto draft due in 14 months or is it 14 months behind schedule? If the latter, why isn't the Foo WG meeting at the IETF? I don't think milestones will be useful unless and until: (a) they're defined in terms of not only concrete but also meaningful goals (e.g. complete problem definition, identify affected parties and groups representing their interests, complete outline of initial design, but NOT revise document X); (b) we start automatically suspending the activities of groups that fail to meet them (no meetings, no new I-Ds accepted, mailing list traffic blocked), until such groups are formally rechartered; and (c) IESG is reluctant to recharter groups that have repeatedly failed to meet milestones, especially if those groups haven't produced evidence of significant progress. I think we can find some middle ground between ignore charter milestones completely and autobot to terminate WGs behind schedule. :-) Keith Andy
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 5/20/13 8:56 AM, John C Klensin wrote: --On Monday, May 20, 2013 07:53 -0700 joel jaeggli joe...@bogus.com wrote: ... This is not my primary (or even secondary) area of expertise but, given that the RR space is not unlimited even though it is large, wouldn't it be better to have a single RRtype for IEEE-based EUIs with a flag or other indicator in the DATA field as to whether a 48 bit or 64 bit identifier was present? the basis for assignment of rr-types is expert review. Whether the draft advances or not the rr-types have been assigned. http://tools.ietf.org/html/rfc6895#section-3.1.1 http://www.iana.org/assignments/dns-parameters/dns-parameters. xml#dns-parameters-3 Joel, I don't know who the current expert is and, for the moment, am glad I don't and don't intend to check. I believe there is broad consensus in the community that having something as significant as an RRTYPE documented in the RFC Series is a good idea. IETF consensus tends to indicate that is is better to assign new RR-types then it is to keep having developers jam these usages into text RRs. Certainly leaving the reference pointing, long-term, to an I-D would not be a good idea (and would violate several other principles). an ISE submission for documentary purposes would minimal impediment and documentary value would be preserved an rr-type assignement might well point at an external resource. However, if (i) the expert review consists largely of making sure that the template contains the right information and the ducks are not obviously out of line rather than a design/architectural review with at least meaningful potential for community review of the request, and (ii) the response to a design/architectural concern raised during IETF LC is essentially too late, code points already allocated, and IETF LC should be, can we live with this? The document has been discussed in dnsext and reviews were requested, I was prevailed on to take it on as that WG is supposed to be shutting down. (iii) Proposed Standard still does not imply recommended and the alternative to approving the I-D for that category is non-publication, then I would like to understand, as a procedural matter, what the IETF Last Call is about. Certainly it is not for editorial review; that is the RFC Editor's job and there are, IMO, no glaring editorial problems. If the RRTYPEs have been allocated and can't be un-allocated and this is in use, then there is nothing to propose as an individual submission for standardization: an informational document to inform the community about what this is about would be both appropriate and sufficient. Beyond that, your shepherd's report implies that the issue I raised may have been discussed and successfully resolved in DNSEXT. If that is the case, an explanation in the document about the tradeoffs and decision would still be appropriate. Alternatively and especially if there wasn't clear consensus in DNSEXT, if this really is to be processed as a Proposed Standard, then a suggestion during IETF Last Call that the IETF Standard way to represent EUIs in the DNS should be a single RRTYPE with length/type information in the DATA is still in order: the community could reasonably conclude that the single RRTYPE is a better solution, that the single type should be allocated, and that these two types should be deprecated. We have certainly done similar things before with other protocols and parameters that were already in use before standardization was proposed from an individual submission. So, I don't have a problem philosophically or otherwise with the fact that there my be a better solution out there. It takes somebody to do that work. The can obviously get an rr-type for that application. In the use cases associated with provisioning systems I would expect that knowledge of media type would drive usage of one rr type or another e.g. if you're provisioning 6lowpan/zigbee/802.15.4 devices you probably don't have to query for eui48. john p.s. I've tried reading your shepherd writeup now in three different browsers. It appears to be formatted for extremely long (paragraph-length) lines, with no provision for automatic wrapping to fit the page frame. I can fix that by editing the text. a tool fix for that is forthcoming iirc. That means that trying to read and understand it requires extensive horizontal scrolling, which is a fairly large impediment and, although I assume unintentionally, a way to discourage anyone but the most determined of readers from actually reading it. May I suggest that the IESG, on a priority basis, either get the format of those writeup pages changed so that they wrap appropriately or that it insist that writeups conform to RFC/I-D norms for line lengths.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
At 06:44 20-05-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS' draft-jabley-dnsext-eui48-eui64-rrtypes-03.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 ietf@ietf.org mailing lists by 2013-06-17. Exceptionally, comments may be This draft is about putting MAC addresses in the DNS. The purpose is for IP address tracking by vendors. As the RRTYPE has already been allocated it is useful to document the format. In my humble opinion it is not a good idea to put MAC address in the DNS. There is some text in Section 9 about why it may not be a good idea. In Section 9: These potential concerns can be mitigated through restricting access to zones containing EUI48 or EUI64 RRs or storing such information under a domain name whose construction requires that the querier already know some other permanent identifier. The querier already know some other permanent identifier reminds me of security through obscurity. I'll do some selective quoting from another document: Once the MAC-derived suffix mechanism was standardized, it was perceived to be required and therefore became part of compliance suites, which continue to compel implementations to support it many years after the associated vulnerabilities have been identified. A comprehensive privacy threat model was never developed (which seems to be a recurring theme with older protocol development efforts) The write-up mentions: The intended status is standards track with the label of propsed standard. Why is the intended status Proposed Standard? As a comment to Joe, the first line in Appendix A.2 was entertaining. :-) Regards, -sm
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
People were already storing MAC addresses in DNS for the reason given in the draft and perhaps others, it is just that they were doing so in a variety of proprietary ways. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Mon, May 20, 2013 at 12:48 PM, SM s...@resistor.net wrote: At 06:44 20-05-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS' draft-jabley-dnsext-eui48-eui64-rrtypes-03.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 ietf@ietf.org mailing lists by 2013-06-17. Exceptionally, comments may be This draft is about putting MAC addresses in the DNS. The purpose is for IP address tracking by vendors. As the RRTYPE has already been allocated it is useful to document the format. In my humble opinion it is not a good idea to put MAC address in the DNS. There is some text in Section 9 about why it may not be a good idea. In Section 9: These potential concerns can be mitigated through restricting access to zones containing EUI48 or EUI64 RRs or storing such information under a domain name whose construction requires that the querier already know some other permanent identifier. The querier already know some other permanent identifier reminds me of security through obscurity. I'll do some selective quoting from another document: Once the MAC-derived suffix mechanism was standardized, it was perceived to be required and therefore became part of compliance suites, which continue to compel implementations to support it many years after the associated vulnerabilities have been identified. A comprehensive privacy threat model was never developed (which seems to be a recurring theme with older protocol development efforts) The write-up mentions: The intended status is standards track with the label of propsed standard. Why is the intended status Proposed Standard? As a comment to Joe, the first line in Appendix A.2 was entertaining. :-) Regards, -sm
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Monday, May 20, 2013 09:55 -0700 joel jaeggli joe...@bogus.com wrote: I don't know who the current expert is and, for the moment, am glad I don't and don't intend to check. I believe there is broad consensus in the community that having something as significant as an RRTYPE documented in the RFC Series is a good idea. IETF consensus tends to indicate that is is better to assign new RR-types then it is to keep having developers jam these usages into text RRs. I certainly agree with that. If I had my druthers, the IETF would have loosened up on registrations and issued a strong statement discouraging the use of text RRs for anything other than what I believe was their original purpose -- unstructured textual comments to be read by humans. So no disagreement there.But even in the pre-1999 IANA days and with registries that were almost purely FCFS, the then-universal expert reviewer felt it was reasonable to deal with an application for two code points by saying something equivalent to hey, can't you use one and a different data structure?. It is, IMO, an obvious question and, other issues aside, I think the answer should be explained in the document. How strong should is depends on another consideration; see below. Certainly leaving the reference pointing, long-term, to an I-D would not be a good idea (and would violate several other principles). an ISE submission for documentary purposes would minimal impediment and documentary value would be preserved an rr-type assignement might well point at an external resource. Yes. And?I didn't say no external reference, I said no permanent reference to an I-D. Remember that not an archival series, reference only as work in progress, etc., stuff? Again, see below. However, if (i) the expert review consists largely of making sure that the template contains the right information and the ducks are not obviously out of line rather than a design/architectural review with at least meaningful potential for community review of the request, and (ii) the response to a design/architectural concern raised during IETF LC is essentially too late, code points already allocated, and IETF LC should be, can we live with this? The document has been discussed in dnsext and reviews were requested, I was prevailed on to take it on as that WG is supposed to be shutting down. See below. (iii) Proposed Standard still does not imply recommended and the alternative to approving the I-D for that category is non-publication, ... So, I don't have a problem philosophically or otherwise with the fact that there my be a better solution out there. It takes somebody to do that work. The can obviously get an rr-type for that application. ... Somewhat informed by your note and the other responses to my original one, let me clarify what I'm suggesting... (1) As indicated above, I think that an easy application and registration process is A Good Thing for RRTYPEs (and lots of other things). Unless there is some substantial reason to not do so, I think that such registrations should be bound to sufficient information to make interoperability easy or at least feasible. In the general case, I don't think it makes any difference where that information is recorded as long as the document location or maintenance arrangements are sufficiently stable to create a plausible expectation of long-term accessibility of the description. I note that the latter has been an IANA requirement since before there was an IETF and that occasional exceptions have been made for almost that long. (2) I think publication of descriptions of RRTYPE values (and other parameters) in the RFC Series is generally A Good Thing and that it should be encouraged. If that results in better quality documentation or documentation that is easier to interpret in ways that increase interoperability, that is great. (3) However, if someone wants both a code point (in this case, RRTYPE) or two and an IETF Standards Track document, they should expect to conform to IETF norms about standards track specifications. I think those norms include the expectation of a meaningful IETF Last Call that could, e.g., question design decisions, expect substantive responses, and expect changes if the consensus leads that way. The situation with a WG document being processed inside a WG and with an individual submission for Standards Track ought to be the same: design decisions belong to the WG or IETF, not the authors. A registration procedure should not be able to be used to create a back door and preempt that principle, so the would-be registrants can use the expert process to register whatever they would like but, in doing so, they should accept that, if they want to publish in the RFC Series, the result will be Informational. Or, if they want whatever value that IETF Standardization adds, they need to make a proposal to the IETF and
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Publication of EUI-48 or EUI-64 addresses in the global DNS may result in privacy issues in the form of unique trackable identities. This might also result in such MAC addresses being spoofed, thereby allowing some sort of direct attack. So it isn't just a privacy concern. ... These potential concerns can be mitigated through restricting access to zones containing EUI48 or EUI64 RRs or storing such information under a domain name whose construction requires that the querier already know some other permanent identifier. This can be seems too weak. Shouldn't we have a MUST here? Also, I doubt that the second option (a shared secret) is sufficient. Regards Brian Carpenter
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Tuesday, May 21, 2013 08:08 +1200 Brian E Carpenter brian.e.carpen...@gmail.com wrote: These potential concerns can be mitigated through restricting access to zones containing EUI48 or EUI64 RRs or storing such information under a domain name whose construction requires that the querier already know some other permanent identifier. This can be seems too weak. Shouldn't we have a MUST here? Also, I doubt that the second option (a shared secret) is sufficient. I'd guess that, in the actual use cases, a MUST would be ignored and am consequently would be reasonably happy with the existing text even if it said less, thereby reducing the sensation of hand waving. A shared secret or other mechanism for obscuring a name might be sufficient if the privacy requirement was to prevent casual data mining and resulting attacks. What is, or is not, sufficient really depends on the risk analysis and assessment of how serious a failure might be, an analysis that is missing from the document. That said, if serious protection were needed, wouldn't it make sense to incorporate some provision for data encryption in the RRTYPE itself rather than trying to use an obscured domain name? I wouldn't really propose that. Instead, I think the bottom line is closer to if some data really need to be secure and private, the public DNS is probably not the right place to put them. Comparing this to my earlier comments, I think an IETF Proposed Standard really needs to discuss and resolve these issues and that Brian's question is important in that context. If hand waving is appropriate, it should say why. If an obscured identifier is sufficient, it should explain why that is the case or the circumstances under which it is the case.The same problems could be solved with an Informational document by clearly describing the RRTYPE and then, if this sort of information is needed at all, making it clear that it represents the authors' opinion and how they expect their RRTYPE to be used rather than, e.g., IETF consensus. john
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
At Mon, 20 May 2013 10:18:21 -0400, John C. Klensin wrote: This is not my primary (or even secondary) area of expertise but, given that the RR space is not unlimited even though it is large, wouldn't it be better to have a single RRtype for IEEE-based EUIs with a flag or other indicator in the DATA field as to whether a 48 bit or 64 bit identifier was present? Short answer: Probably not, but it depends on the application. Longer answer: See RFC 5507.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Hi Donald, At 12:10 20-05-2013, Donald Eastlake wrote: People were already storing MAC addresses in DNS for the reason given in the draft and perhaps others, it is just that they were doing so in a variety of proprietary ways. Thanks for the explanation. I'll make a general comment. From what I understand the use case is about Canadian ISPs using AXFR to (privately) transfer information about IP addresses, EUI-48 and EUI-64 addresses. A MAC address is usually tied to a device [1][2]. I understand the interoperability argument. That is addressed by the code point allocation. I personally do not think that it is a good idea to encourage [3] storing MAC addresses in the (public) DNS even though people might already be doing that. It has become difficult to reconcile what a proposed standard is about. I prefer that it does not mean just what I choose it to mean - neither more nor less. Regards, -sm 1. http://www.canlii.org/eliisa/highlight.do?language=ensearchTitle=British+Columbiapath=/en/bc/bcca/doc/2005/2005bcca334/2005bcca334.html 2. http://www.priv.gc.ca/media/sp-d/2011/sp-d_20110125_pk_e.asp 3. I could not find an appropriate word.
Deployment of standards compliant nameservers
I call upon the IESG to discuss with IANA, the RIRs, ICANN and TLD operators how to deal with the problems caused by the deployment of non standards compliant nameservers. For a long time there have been operational problems cause by the deployment of non standards compliant nameservers that fail to respond to DNS queries directed at them or respond incorrectly. The biggest problem with respect to deployment of new types is nameservers that fail to respond to types they don't understand. RFC 1034 allows for several different responses: * name error * no error no data * not implemented * refused * formerr Name error and no error no data are the expected responses for queries with unknown types. This is reinforced by RFC 3597. But any of the other responses is acceptable. Failure to respond however is not acceptable. It introduces systematic timeouts which are indistinguishable from network errors without extended analysis of query response behaviour. While the percentage of nameservers misbehaving like this are relatively small they have a disproportionate effect on protocol development. They are also easily identifiable when looked for by querying for a know type at a name that is know to exist, the zone apex, that is supported by virtually all nameservers (e.g. A) and querying for a random unallocated type, then querying again for the original type. If you get a answer, no response, answer then the nameserver in question almost certainly has this issue and you are not looking at a dead server or network congestion issue. I'm not sure what the solution should be but regular audits of delegated nameservers by infrastructure operator and removal of delegations after a grace period to correct the faulty nameserver and checking of nameserver behaviour at registration time would go a long way to addressing the problem. Removal of the delegation is one of the suggested remediations identified in RFC 1034 for nameservers that are causing operational problems. It is not the first step by it is a step in the process. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deployment of standards compliant nameservers
I believe that there are a couple of problems with this plea… 1) - The IETF has -never- tested for or assured compliance with their document series. 2) - The only DNS test suite I am aware of is the older TAHI test suite from http://www.tahi.org/ - which was focused on IPv6 development and is now closed. 3) - The full DNS standards fail to include the RFC 2026 language that would suggest mandatory capabilities. So, while a nice idea, it is hardly practical from an IETF (or any top-down) perspective… /bill On 20May2013Monday, at 17:26, Mark Andrews wrote: I call upon the IESG to discuss with IANA, the RIRs, ICANN and TLD operators how to deal with the problems caused by the deployment of non standards compliant nameservers. For a long time there have been operational problems cause by the deployment of non standards compliant nameservers that fail to respond to DNS queries directed at them or respond incorrectly. The biggest problem with respect to deployment of new types is nameservers that fail to respond to types they don't understand. RFC 1034 allows for several different responses: * name error * no error no data * not implemented * refused * formerr Name error and no error no data are the expected responses for queries with unknown types. This is reinforced by RFC 3597. But any of the other responses is acceptable. Failure to respond however is not acceptable. It introduces systematic timeouts which are indistinguishable from network errors without extended analysis of query response behaviour. While the percentage of nameservers misbehaving like this are relatively small they have a disproportionate effect on protocol development. They are also easily identifiable when looked for by querying for a know type at a name that is know to exist, the zone apex, that is supported by virtually all nameservers (e.g. A) and querying for a random unallocated type, then querying again for the original type. If you get a answer, no response, answer then the nameserver in question almost certainly has this issue and you are not looking at a dead server or network congestion issue. I'm not sure what the solution should be but regular audits of delegated nameservers by infrastructure operator and removal of delegations after a grace period to correct the faulty nameserver and checking of nameserver behaviour at registration time would go a long way to addressing the problem. Removal of the delegation is one of the suggested remediations identified in RFC 1034 for nameservers that are causing operational problems. It is not the first step by it is a step in the process. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE:+61 2 9871 4742 INTERNET: ma...@isc.org
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Monday, May 20, 2013 19:49 -0400 Rob Austein s...@hactrn.net wrote: At Mon, 20 May 2013 10:18:21 -0400, John C. Klensin wrote: This is not my primary (or even secondary) area of expertise but, given that the RR space is not unlimited even though it is large, wouldn't it be better to have a single RRtype for IEEE-based EUIs with a flag or other indicator in the DATA field as to whether a 48 bit or 64 bit identifier was present? Short answer: Probably not, but it depends on the application. Longer answer: See RFC 5507. Rob, I've reread 5507 and did so again before writing my second note today. I don't see that it helps. I haven't heard anyone proposing use of TXT (or any existing RRTYPE) instead, so that is presumably a non-issue. The discussion in 3.1 clearly applies to relatively complex schemes like NAPTR, but it is not clear that it has anything to do with this case. In particular, if I correctly understand the IEEE's allocation scheme for longer identifiers (and I may not) than a given device gets only one -- this is not analogous to a dual-stack IPv4/IPv6 arrangement -- and an application gets back whatever it gets back (whether the query is addressed to the DNS, read off a label on the device and entered manually, or something else). If so, then one RRTYPE with the appropriate identifier in the data is the right answer. If not... if, for example, different types of applications will look for only one type-length of identifier and will either find it or give up (not try falling back to the other because that would make no sense), then the use of two RRTYPEs is entirely reasonable. But, if that is the case and this is going to be standards track, I expect to see an explanation in the document. That explanation could be as simple as a statement to that effect and an example or two of the types of applications that would use each identifier and/or a reference to IEEE materials that describe the circumstances under which one example or the other is used. I'm not opposed to having two separate RRTYPEs -- I just want to see the rationale. And what passes for use cases in the draft appears to me to be completely silent on that issue. john
Re: Deployment of standards compliant nameservers
In message 6a13ceb4-8906-4ec5-9210-571d5474e...@isi.edu, manning bill writes: I believe that there are a couple of problems with this plea. 1) - The IETF has -never- tested for or assured compliance with their document series. Which has what to do with requesting that a known problem get fixed? One that is clearly caused by nameservers operating outside the expected behaviour of nameservers. 2) - The only DNS test suite I am aware of is the older TAHI test suite from http://www.tahi.org/ - which was focused on IPv6 development and is now closed. Well I didn't ask for a complete compliance test to be run. I ask for a specific test for a known problematic issue to be run. 3) - The full DNS standards fail to include the RFC 2026 language that would suggest mandatory capabilities. And this has what to do with the issue? Yes older RFCs don't all use the formal language of RFC 2026. That doesn't mean that the intent was not clear or that one should not address operational issues that arise. So, while a nice idea, it is hardly practical from an IETF (or any top-down) perspective. /bill On 20May2013Monday, at 17:26, Mark Andrews wrote: I call upon the IESG to discuss with IANA, the RIRs, ICANN and TLD operators how to deal with the problems caused by the deployment of non standards compliant nameservers. For a long time there have been operational problems cause by the deployment of non standards compliant nameservers that fail to respond to DNS queries directed at them or respond incorrectly. The biggest problem with respect to deployment of new types is nameservers that fail to respond to types they don't understand. RFC 1034 allows for several different responses: * name error * no error no data * not implemented * refused * formerr Name error and no error no data are the expected responses for queries with unknown types. This is reinforced by RFC 3597. But any of the other responses is acceptable. Failure to respond however is not acceptable. It introduces systematic timeouts which are indistinguishable from network errors without extended analysis of query response behaviour. While the percentage of nameservers misbehaving like this are relatively small they have a disproportionate effect on protocol development. They are also easily identifiable when looked for by querying for a know type at a name that is know to exist, the zone apex, that is supported by virtually all nameservers (e.g. A) and querying for a random unallocated type, then querying again for the original type. If you get a answer, no response, answer then the nameserver in question almost certainly has this issue and you are not looking at a dead server or network congestion issue. I'm not sure what the solution should be but regular audits of delegated nameservers by infrastructure operator and removal of delegations after a grace period to correct the faulty nameserver and checking of nameserver behaviour at registration time would go a long way to addressing the problem. Removal of the delegation is one of the suggested remediations identified in RFC 1034 for nameservers that are causing operational problems. It is not the first step by it is a step in the process. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deployment of standards compliant nameservers
On May 20, 2013, at 6:23 PM, Mark Andrews ma...@isc.org wrote: In message 6a13ceb4-8906-4ec5-9210-571d5474e...@isi.edu, manning bill writes: I believe that there are a couple of problems with this plea. 1) - The IETF has -never- tested for or assured compliance with their document series. Which has what to do with requesting that a known problem get fixed? One has to test for compliance in order to determine if the problem exists in a particular implementation. One that is clearly caused by nameservers operating outside the expected behaviour of nameservers. No offense, but your view of clearly and expected have sometimes been at odds with other folks in the DNS protocol community. Your request that the IETF do conformance testing might first be based on assurance that the DNS protocol community agrees on those. After that, someone can probably do testing. And after that, someone might be able to get people to take action against non-conformant implementations. --Paul Hoffman
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 21/05/2013 13:06, John C Klensin wrote: --On Monday, May 20, 2013 19:49 -0400 Rob Austein s...@hactrn.net wrote: At Mon, 20 May 2013 10:18:21 -0400, John C. Klensin wrote: This is not my primary (or even secondary) area of expertise but, given that the RR space is not unlimited even though it is large, wouldn't it be better to have a single RRtype for IEEE-based EUIs with a flag or other indicator in the DATA field as to whether a 48 bit or 64 bit identifier was present? Short answer: Probably not, but it depends on the application. Longer answer: See RFC 5507. Rob, I've reread 5507 and did so again before writing my second note today. I don't see that it helps. I haven't heard anyone proposing use of TXT (or any existing RRTYPE) instead, so that is presumably a non-issue. The discussion in 3.1 clearly applies to relatively complex schemes like NAPTR, but it is not clear that it has anything to do with this case. In particular, if I correctly understand the IEEE's allocation scheme for longer identifiers (and I may not) than a given device gets only one -- this is not analogous to a dual-stack IPv4/IPv6 arrangement -- and an application gets back whatever it gets back (whether the query is addressed to the DNS, read off a label on the device and entered manually, or something else). If so, then one RRTYPE with the appropriate identifier in the data is the right answer. If not... if, for example, different types of applications will look for only one type-length of identifier and will either find it or give up (not try falling back to the other because that would make no sense), then the use of two RRTYPEs is entirely reasonable. But, if that is the case and this is going to be standards track, I expect to see an explanation in the document. That explanation could be as simple as a statement to that effect and an example or two of the types of applications that would use each identifier and/or a reference to IEEE materials that describe the circumstances under which one example or the other is used. I'm not opposed to having two separate RRTYPEs -- I just want to see the rationale. And what passes for use cases in the draft appears to me to be completely silent on that issue. Especially since there is an IEEE-defined method for representing a 48-bit address in the 64-bit format. Now you mention it, why can't that be used in all cases? Brian
Re: Deployment of standards compliant nameservers
It seems like a first step might be to set up a web page and/or write up an I-D with a) a description of the problem b) documentation a procedure and/or code that can be used to test name server software for compliance c) recommendations for zone operators that delegate to other zones The next step might be for TLD operators to encourage the TLD registrars to (a) inform their customers of this issue, (b) test their customers' servers, and report the test results to their customers. Ideally those registrars would be able to refer their customers to updated or improved servers. Longer term it might be appropriate to do some other things, like a) define standard tests for compliance b) define a mechanism by which a server could be queried to find out its implementation name, version, etc. Keith p.s. I wonder if the problem you describe might at least partially be caused by DNS proxies and interception proxies, including but not limited to those incorporated in consumer-grade routers. On 05/20/2013 08:26 PM, Mark Andrews wrote: I call upon the IESG to discuss with IANA, the RIRs, ICANN and TLD operators how to deal with the problems caused by the deployment of non standards compliant nameservers. For a long time there have been operational problems cause by the deployment of non standards compliant nameservers that fail to respond to DNS queries directed at them or respond incorrectly. The biggest problem with respect to deployment of new types is nameservers that fail to respond to types they don't understand. RFC 1034 allows for several different responses: * name error * no error no data * not implemented * refused * formerr Name error and no error no data are the expected responses for queries with unknown types. This is reinforced by RFC 3597. But any of the other responses is acceptable. Failure to respond however is not acceptable. It introduces systematic timeouts which are indistinguishable from network errors without extended analysis of query response behaviour. While the percentage of nameservers misbehaving like this are relatively small they have a disproportionate effect on protocol development. They are also easily identifiable when looked for by querying for a know type at a name that is know to exist, the zone apex, that is supported by virtually all nameservers (e.g. A) and querying for a random unallocated type, then querying again for the original type. If you get a answer, no response, answer then the nameserver in question almost certainly has this issue and you are not looking at a dead server or network congestion issue. I'm not sure what the solution should be but regular audits of delegated nameservers by infrastructure operator and removal of delegations after a grace period to correct the faulty nameserver and checking of nameserver behaviour at registration time would go a long way to addressing the problem. Removal of the delegation is one of the suggested remediations identified in RFC 1034 for nameservers that are causing operational problems. It is not the first step by it is a step in the process. Mark
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Hi, On Mon, May 20, 2013 at 9:06 PM, John C Klensin john-i...@jck.com wrote: ... ... The discussion in 3.1 clearly applies to relatively complex schemes like NAPTR, but it is not clear that it has anything to do with this case. In particular, if I correctly understand the IEEE's allocation scheme for longer identifiers (and I may not) than a given device gets only one -- this is not analogous to a dual-stack IPv4/IPv6 arrangement -- and an application gets back whatever it gets back (whether the query is addressed to the DNS, read off a label on the device and entered manually, or something else). If so, then one RRTYPE with the appropriate identifier in the data is the right answer. If you are getting an address to connect with a device on an Ethernet link, you just have to know what the right address size is. After whatever start of frame mark there is, it is just DA-SA and using the wrong size MAC addresses isn't going to work. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com If not... if, for example, different types of applications will look for only one type-length of identifier and will either find it or give up (not try falling back to the other because that would make no sense), then the use of two RRTYPEs is entirely reasonable. But, if that is the case and this is going to be standards track, I expect to see an explanation in the document. That explanation could be as simple as a statement to that effect and an example or two of the types of applications that would use each identifier and/or a reference to IEEE materials that describe the circumstances under which one example or the other is used. I'm not opposed to having two separate RRTYPEs -- I just want to see the rationale. And what passes for use cases in the draft appears to me to be completely silent on that issue. john
Re: Deployment of standards compliant nameservers
In message 7e5b1b3d-8af1-4ffe-bda2-47efb6d35...@vpnc.org, Paul Hoffman writes: On May 20, 2013, at 6:23 PM, Mark Andrews ma...@isc.org wrote: In message 6a13ceb4-8906-4ec5-9210-571d5474e...@isi.edu, manning bill writes: I believe that there are a couple of problems with this plea. 1) - The IETF has -never- tested for or assured compliance with their document series. Which has what to do with requesting that a known problem get fixed? One has to test for compliance in order to determine if the problem exists in a particular implementation. It doesn't have to be the IETF that does the testing. In fact the IETF doesn't have access to the list of servers that need to be tested however the operators of the parent zones do. Alternatively it can be done on a piecemeal basis by examine logs and then looking up whois entries and complaining that the nameservers are causing operational problems to the operators, the complaining to the parent zone, then complaining to the courts when the parent zone operators fail to take action as directed by RFC 1034. One that is clearly caused by nameservers operating outside the expected behaviour of nameservers. No offense, but your view of clearly and expected have sometimes been at odds with other folks in the DNS protocol community. Your request that the IETF do conformance testing might first be based on assurance that the DNS protocol community agrees on those. After that, someone can probably do testing. And after that, someone might be able to get people to take action against non-conformant implementations. RFC 1034 describes how to answer a query. It clearly states that new query types are expected. However, the domain system is intentionally extensible. Researchers are continuously proposing, implementing and experimenting with new data types, query types, classes, functions, etc. Thus while the components of the official protocol are expected to stay essentially unchanged and operate as a production service, experimental behavior should always be expected in extensions beyond the official protocol. Experimental or obsolete features are clearly marked in these RFCs, and such information should be used with caution. It also states how to constuct a response and it doesn't state only known types. 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: a. If the whole of QNAME is matched, we have found the node. If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. The DNS also has response codes to say that a nameserver doesn't implement a part if the specification, that it don't want to answer a particular query, that a internal error occured, that you don't understand or can parse the query. These response codes cover just about any conceivable error condition. It is a query/response protocol and a response is expected except under exceptional circumstances. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deployment of standards compliant nameservers
as mentioned earlier, only -ONE- known, public DNS conformance test suite has existed and it was shut down last year due to lack of use. since you want the courts involved, you are making some significant presumptions about the liability of adherence to voluntary standards. dead issue … move on. Or persuade Yokogawa Electric Corporation to spin the test suite back up. /bill On 20May2013Monday, at 19:20, Mark Andrews wrote: In message 7e5b1b3d-8af1-4ffe-bda2-47efb6d35...@vpnc.org, Paul Hoffman writes: On May 20, 2013, at 6:23 PM, Mark Andrews ma...@isc.org wrote: In message 6a13ceb4-8906-4ec5-9210-571d5474e...@isi.edu, manning bill writes: I believe that there are a couple of problems with this plea. 1) - The IETF has -never- tested for or assured compliance with their document series. Which has what to do with requesting that a known problem get fixed? One has to test for compliance in order to determine if the problem exists in a particular implementation. It doesn't have to be the IETF that does the testing. In fact the IETF doesn't have access to the list of servers that need to be tested however the operators of the parent zones do. Alternatively it can be done on a piecemeal basis by examine logs and then looking up whois entries and complaining that the nameservers are causing operational problems to the operators, the complaining to the parent zone, then complaining to the courts when the parent zone operators fail to take action as directed by RFC 1034. One that is clearly caused by nameservers operating outside the expected behaviour of nameservers. No offense, but your view of clearly and expected have sometimes been at odds with other folks in the DNS protocol community. Your request that the IETF do conformance testing might first be based on assurance that the DNS protocol community agrees on those. After that, someone can probably do testing. And after that, someone might be able to get people to take action against non-conformant implementations. RFC 1034 describes how to answer a query. It clearly states that new query types are expected. However, the domain system is intentionally extensible. Researchers are continuously proposing, implementing and experimenting with new data types, query types, classes, functions, etc. Thus while the components of the official protocol are expected to stay essentially unchanged and operate as a production service, experimental behavior should always be expected in extensions beyond the official protocol. Experimental or obsolete features are clearly marked in these RFCs, and such information should be used with caution. It also states how to constuct a response and it doesn't state only known types. 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: a. If the whole of QNAME is matched, we have found the node. If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. The DNS also has response codes to say that a nameserver doesn't implement a part if the specification, that it don't want to answer a particular query, that a internal error occured, that you don't understand or can parse the query. These response codes cover just about any conceivable error condition. It is a query/response protocol and a response is expected except under exceptional circumstances. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deployment of standards compliant nameservers
In message 519ad17d.8040...@network-heretics.com, Keith Moore writes: It seems like a first step might be to set up a web page and/or write up an I-D with a) a description of the problem b) documentation a procedure and/or code that can be used to test name server software for compliance c) recommendations for zone operators that delegate to other zones The next step might be for TLD operators to encourage the TLD registrars to (a) inform their customers of this issue, (b) test their customers' servers, and report the test results to their customers. Ideally those registrars would be able to refer their customers to updated or improved servers. Ack. Longer term it might be appropriate to do some other things, like a) define standard tests for compliance b) define a mechanism by which a server could be queried to find out its implementation name, version, etc. Keith p.s. I wonder if the problem you describe might at least partially be caused by DNS proxies and interception proxies, including but not limited to those incorporated in consumer-grade routers. When the problems exist on the nameservers of Fortune 500 companies nameservers it isn't consumer-grade routers. It is badly designed nameservers or their load distributing front ends. This is similar to the name error issue a nameserver vendor had when responding to unknown types (e.g. ) in the past. The BBC's nameservers were a prime example at the time (now fixed). They returned name error for a existing name (www.bbc.co.uk from memory). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Tuesday, May 21, 2013 13:42 +1200 Brian E Carpenter brian.e.carpen...@gmail.com wrote: ... I'm not opposed to having two separate RRTYPEs -- I just want to see the rationale. And what passes for use cases in the draft appears to me to be completely silent on that issue. Especially since there is an IEEE-defined method for representing a 48-bit address in the 64-bit format. Now you mention it, why can't that be used in all cases? I think that just proves the point I was trying to make while stumbling around in ignorance. No need at all for two RRTYPEs or even for an indicator in the data other than IEEE's own methods. Or do I misunderstand your comment? john
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
At Mon, 20 May 2013 21:06:53 -0400, John C. Klensin wrote: I've reread 5507 and did so again before writing my second note today. I don't see that it helps. I was mostly referring to the discussion in section 3.1. The discussion in 3.1 clearly applies to relatively complex schemes like NAPTR, but it is not clear that it has anything to do with this case. In particular, if I correctly understand the IEEE's allocation scheme for longer identifiers (and I may not) than a given device gets only one -- this is not analogous to a dual-stack IPv4/IPv6 arrangement -- and an application gets back whatever it gets back (whether the query is addressed to the DNS, read off a label on the device and entered manually, or something else). If so, then one RRTYPE with the appropriate identifier in the data is the right answer. If not... if, for example, different types of applications will look for only one type-length of identifier and will either find it or give up (not try falling back to the other because that would make no sense), then the use of two RRTYPEs is entirely reasonable. The usual criteria are: - Does the entire set of records need to be retrieved as an atomic unit (eg, to avoid internal consistency problems)? If so, it should be a single RRset, thus a single new type. - If there's no internal consistency requirement, might an application reasonably want to retrieve only one flavor of data (eg, 48-bit EUIs in this case)? If so, multiple RRsets make more sense, thus multiple new types. - Is the total size of an RRset likely to be large if all cases are lumped into a single type? If so, multiple new types might be better, because large RRsets are a problem (amplification attacks, message truncation, DNSSEC verification failure due to truncation, etcetera ad nausium). If none of the above apply, it's mostly a matter of taste. My own bias is against sub-typing, both because we've been burned before by misguided (albeit well-intentioned) use of sub-typing and also because, other things being equal, I prefer the simplest RDATA structure that will get the job done (parsing code for this stuff is often written in low-level languages which make stupid coding mistakes all too easy, so, other things being equal, I prefer to reduce the number of gratuitous opportunities for code exploits). But if there really is no reason to expect that an application retrieving EUIs have any sane need to say it only wants the 48-bit ones or whatever, then a single RR type may be appropriate. I don't understand the intended uses well enough to have an informed opinion. But, if that is the case and this is going to be standards track, I expect to see an explanation in the document. That explanation could be as simple as a statement to that effect and an example or two of the types of applications that would use each identifier and/or a reference to IEEE materials that describe the circumstances under which one example or the other is used. I'm not opposed to having two separate RRTYPEs -- I just want to see the rationale. And what passes for use cases in the draft appears to me to be completely silent on that issue. Fair enough.
Last Call: draft-ietf-xrblock-rtcp-xr-discard-14.txt (RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count metric Reporting) to Proposed Standard
The IESG has received a request from the Metric Blocks for use with RTCP's Extended Report Framework WG (xrblock) to consider the following document: - 'RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count metric Reporting' draft-ietf-xrblock-rtcp-xr-discard-14.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 2013-06-03. 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. Abstract This document defines an RTP Control Protocol(RTCP) Extended Report (XR) Block that allows the reporting of a simple discard count metric for use in a range of RTP applications. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-discard/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-discard/ballot/ No IPR declarations have been submitted directly on this I-D.
