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 Jun 19, 2013, at 9:29 AM, joel jaeggli joe...@bogus.com wrote: Given that this document was revved twice and had it's requested status change during IETF last call in response to discussion criticism and new contribution I am going to rerun the last call. I reviewed this version and I think this is a fine document that I support. In particular the document goes out of its way to address the issues raised in prior IETF last call to the extent possible. The document is going to be the specification of two DNS RRtypes that have been allocated via expert review, we (DNS community) want to encore that any such allocations be published as RFC's for future references. This document is not a product of any working group. Olafur (DNSEXT co-chair)
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
Olafur, Based on reviewing the current draft and the handling of my objections and other of others to the prior ones, I agree that the document is ready for publication. However, I feel a need to comment on one of your observations below because it seems to lie at the core of why this particular document took up so much IETF list time and correspondence. Most of that could have been avoided, IMO, and I think there is something to be learned from it to which I hope you, the DNSEXT WG, and Ted (as responsible AD) will pay attention. --On Thursday, June 20, 2013 09:39 -0400 Olafur Gudmundsson o...@ogud.com wrote: The document is going to be the specification of two DNS RRtypes that have been allocated via expert review, we (DNS community) want to encore that any such allocations be published as RFC's for future references. The IETF has historically had strong opinions about change control, consensus, and the nature of recommendations. Personally, I hope those opinions will continue and, if anything, get stronger. It seems to me that it is reasonable to say we want a lightweight registration procedure that imposes few if any requirements on allocating an RR TYPE or you can say want to ensure RFC publication but that you don't get to say both at once, especially when Standards Track or the IETF Stream are involved. If you (and DNSECT) want the very lightweight registration procedure, then you should reasonably expect to make sure that any documents are clearly informational (in content and category) and to take your chances about publication: Informational in either the IETF Stream or the Independent Submission Stream could result in a no answer or, more likely, requirements to justify the design decisions behind the RRTYPEs as a condition of publication. You can't ensure anything because the relevant groups really do get to evaluate both document quality and appropriateness for use. By contrast, if the WG really does want to ensure... then it would be appropriate to change the registration procedure so that the I-Ds are posted and RFC publication is agreed to before the RRTYPEs are registered so everyone can be sure that the two match.That could be coupled with some sort of provisional arrangement while document review is in progress, if the WG thought that was necessary. Howver the bottom line, IMO, is that, if you want RFCs and want those RFCs to accurately describe an RRTYPE and there is going to be open review during the RFC development process, you can't have lightweight registration and then insist that an RFC be published to match... at least IMO and, if the discussions of the recent Last Calls are indicative, a significant part of the the community may share that view. So some review of the DNSEXT-specified procedures and expectations may be in order. regards, 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 Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote: So some review of the DNSEXT-specified procedures and expectations may be in order. I encourage you, then, to organize the BOF session that will spin up the WG to achieve this. DNSEXT is only still alive because our last document hasn't been published. But more generally, as a practical matter it is better that people register their stuff with us than that they don't. We have, in the wild, a used EDNS0 option code that is all over the Internet. It is undocumented, and the code point isn't actually registered. That state of affairs is surely worse than that the IETF didn't get to provide good advice to authors. DNSEXT already tried to be the DNS cops, and has failed miserably, partly because of the usual get-off-my-lawn crowd and partly because people unfamiliar with the IETF find its procedures a little arcane. My view is that we need to be more pragmatic. A -- Andrew Sullivan a...@anvilwalrusden.com
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 06/20/2013 09:36 AM, Andrew Sullivan wrote: On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote: So some review of the DNSEXT-specified procedures and expectations may be in order. I encourage you, then, to organize the BOF session that will spin up the WG to achieve this. DNSEXT is only still alive because our last document hasn't been published. But more generally, as a practical matter it is better that people register their stuff with us than that they don't. We have, in the wild, a used EDNS0 option code that is all over the Internet. It is undocumented, and the code point isn't actually registered. That state of affairs is surely worse than that the IETF didn't get to provide good advice to authors. DNSEXT already tried to be the DNS cops, and has failed miserably, partly because of the usual get-off-my-lawn crowd and partly because people unfamiliar with the IETF find its procedures a little arcane. My view is that we need to be more pragmatic. I agree with at least a little of what each of Olafur, John, and Andrew have said; but I think there's a middle ground between throw the doors wide open and everything we have tried before didn't work. At least I hope there is. Perhaps we could have a non-WG mailing list so that people could submit proposals for review prior to the expert review process. Even some of the get off my lawn crowd offered good suggestions for this EUI case (make 1 record with a size field rather than 2 records) that could have made this whole process a lot smoother. Doug
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 Jun 20, 2013, at 1:04 PM, Doug Barton do...@dougbarton.us wrote: Perhaps we could have a non-WG mailing list so that people could submit proposals for review prior to the expert review process. Even some of the get off my lawn crowd offered good suggestions for this EUI case (make 1 record with a size field rather than 2 records) that could have made this whole process a lot smoother. You mean like namedroppers?
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 6/20/13 10:04 AM, Doug Barton wrote: I agree with at least a little of what each of Olafur, John, and Andrew have said; but I think there's a middle ground between throw the doors wide open and everything we have tried before didn't work. At least I hope there is. Well recall that we still have DNSOP, which along with the dnsext mailing list once the wg is closed is probably a reasonable place to get/look for feedback. Perhaps we could have a non-WG mailing list so that people could submit proposals for review prior to the expert review process. Even some of the get off my lawn crowd offered good suggestions for this EUI case (make 1 record with a size field rather than 2 records) that could have made this whole process a lot smoother. My impression of the outcome of the procedure change for the registry is the wg didn't feel that there should be any particular obstacle beyond expert review for registration. It is possible that reasonable people should disagree on the application of given rr-types and that they should be registered anyway. In 30 years we've allocated ~120 rrtypes most of which we don't use anymore. Doug
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 Thu, Jun 20, 2013 at 10:04:54AM -0700, Doug Barton wrote: Perhaps we could have a non-WG mailing list so that people could submit proposals for review prior to the expert review process. The WG list isn't going away with the WG. The list is explicitly called out as a good place to try out proposals, so people can in fact do that today. Best, A -- Andrew Sullivan a...@anvilwalrusden.com
namedroppers (wasRe: 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 Thu, Jun 20, 2013 at 05:10:20PM +, Ted Lemon wrote: You mean like namedroppers? If only we still had that list. Alas, it was the victim of politics. Perhaps Randy Bush will bring it back to life. A -- Andrew Sullivan a...@anvilwalrusden.com
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 06/20/2013 10:27 AM, Andrew Sullivan wrote: On Thu, Jun 20, 2013 at 10:04:54AM -0700, Doug Barton wrote: Perhaps we could have a non-WG mailing list so that people could submit proposals for review prior to the expert review process. The WG list isn't going away with the WG. The list is explicitly called out as a good place to try out proposals, so people can in fact do that today. I would argue that a fresh start here might be appropriate, although I wouldn't argue it strongly, and wouldn't object to using dnsext@ if that was the consensus.
Re: namedroppers (wasRe: 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)
You mean like namedroppers? If only we still had that list. any reports of its death are from questionable sources it was the victim of politics. like much of life randy
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 Thursday, June 20, 2013 12:36 -0400 Andrew Sullivan a...@anvilwalrusden.com wrote: On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote: So some review of the DNSEXT-specified procedures and expectations may be in order. ... But more generally, as a practical matter it is better that people register their stuff with us than that they don't. We have, in the wild, a used EDNS0 option code that is all over the Internet. It is undocumented, and the code point isn't actually registered. That state of affairs is surely worse than that the IETF didn't get to provide good advice to authors. DNSEXT already tried to be the DNS cops, and has failed miserably, partly because of the usual get-off-my-lawn crowd and partly because people unfamiliar with the IETF find its procedures a little arcane. My view is that we need to be more pragmatic. Andrew, Just to be clear, I completely agree. I thought that should have been clear from the context of my note (context that you omitted above). I think that what I have referred to as the lightweight registration procedure is just fine. What I have objected to since the first time a Last Call on the present document was initiated is any assertion that, because something is registered, it is entitled to be documented in the RFC Series. I object even more strongly to any implication that such a registered RRTYPE should be accepted as a Standards Track document without any further review because it is registered already. I thought that issue had been settled for this document by reclassifying its intended status to Informational and clarifying the relationship of the RRTYPEs to other consideration, particularly privacy ones. IMO, that clarification along makes it worth publishing as an RFC, but the notion of entitlement was, I thought, put to rest. Consequently, I was mildly astonished when Olafur's comment (which included the information that he is co-chair of DNSEXT) included ...we (DNS community) want to encore [sic] that any such allocations be published as RFC's for future references. So, once again and in short sentences: (1) The present registration procedure does nothing to ensure any such thing. (2) There is nothing else in either IETF or RFC Editor procedures that ensures RFC publication. If a document describing an already-registered RRTYPE is submitted and some AD wants to sponsor it for publication as an individual submission and puts it into a Last Call on that basis, the community may pick at it, insist on changes, or even reach consensus that it should not be published. (3) I think the above is fine. If someone (else) thinks that RFC publication should be ensured for any RRTYPE allocation, then they need to persuade whomever needs to be persuaded to modify the registration procedure. I would, personally, oppose that change if it eliminated the possibility of quick, lightweight, registrations but my opinion probably doesn't count for much relative to the DNS community for which Olafur and/or you are speaking. best, 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
Given that this document was revved twice and had it's requested status change during IETF last call in response to discussion criticism and new contribution I am going to rerun the last call. Thanks joel On 5/20/13 6:44 AM, 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 sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended Unique Identifiers (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g. ethernet. This document defines two new DNS resource record types, EUI48 and EUI64, for encoding ethernet addresses in the DNS. The file can be obtained via http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ballot/ No IPR declarations have been submitted directly on this I-D.
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
Given that this document was revved twice and had it's requested status change during IETF last call in response to discussion criticism and new contribution I am going to rerun the last call. the recent changes resolved my issue. thanks joe and joel. randy
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
In message m2mwqlyglu.wl%ra...@psg.com, Randy Bush writes: Given that this document was revved twice and had it's requested status change during IETF last call in response to discussion criticism and new contribution I am going to rerun the last call. the recent changes resolved my issue. thanks joe and joel. randy I have read -05 and in my opinion it is good to go.o 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
I am told that draft has been revved again in response to discussion on the list. http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsext-eui48-eui64-rrtypes-05 Please direct your attention to the security considerations section. If it turns out that informational documentation of the two RR-Type assignments remains controversial, I will likely withdraw my sponsorship of this draft. Thanks joel On 5/27/13 5:40 PM, joel jaeggli wrote: On 5/20/13 6:44 AM, 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 I would direct the attention of the commentors to draft 04 http://www.ietf.org/internet-drafts/draft-jabley-dnsext-eui48-eui64-rrtypes-04.txt Which addresses concerns expressed in IETF last call over the intended status. It also incorporates edits proposed by John Klensin in his review. Notes: from the author: - changed intended status to informational - incorporation of John's suggestions in the Terminology section, to indicate that we're using 2119 keywords even though this is not a standards track document - added a couple of sentences to the security considerations sections to underscore the fact that this document specifies optional mechanisms that people might well not use if privacy considerations dictate otherwise 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. Abstract 48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended Unique Identifiers (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g. ethernet. This document defines two new DNS resource record types, EUI48 and EUI64, for encoding ethernet addresses in the DNS. The file can be obtained via http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ballot/ No IPR declarations have been submitted directly on this I-D.
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
I am told that draft has been revved again in response to discussion on the list. http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsext-eui48-eui64-rrtypes-05 Please direct your attention to the security considerations section. If it turns out that informational documentation of the two RR-Type assignments remains controversial, I will likely withdraw my sponsorship of this draft. the addition of This document recommends that EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. alleviates my worst fears. though i wish it was a MUST NOT, i will not insist. thanks joe and joel. randy
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
while i appreciate joe's listening to my other comments on the draft, i still strongly object to publication of this draft as an rfc for the reasons made very clear in the sec cons. please read the summary section of rfc 2804. While the RFC should not be materially misleading, I don't think there is a requirement for Informational RFCs to guarantee any particular level or security or privacy. that the draft now tries to slide by as info does not change that it specified protocol elements and how they are to be used. and the draft makes very clear that this is juristiction specific and a serious privacy problem. RFC 2804 is about i am very well aware what 2804 contains RFC 2804 doesn't seem to me to be particularly applicable. i disagree. i believe the first two bullets in section one are very applicable to joe's draft. - The IETF, an international standards body, believes itself to be the wrong forum for designing protocol or equipment features that address needs arising from the laws of individual countries, because these laws vary widely across the areas that IETF standards are deployed in. Bodies whose scope of authority correspond to a single regime of jurisdiction are more appropriate for this task. - The IETF sets standards for communications that pass across networks that may be owned, operated and maintained by people from numerous jurisdictions with numerous requirements for privacy. In light of these potentially divergent requirements, the IETF believes that the operation of the Internet and the needs of its users are best served by making sure the security properties of connections across the Internet are as well known as possible. At the present stage of our ignorance this means making them as free from security loopholes as possible. randy
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 21:09 27-05-2013, Donald Eastlake wrote: While the RFC should not be materially misleading, I don't think there is a requirement for Informational RFCs to guarantee any particular level or security or privacy. Yes. In my opinion a best effort is preferable or else the Security Considerations section in RFCs is useless. In theory the IETF does not publish RFCs to suit the regulations of one country (see use-case in draft-jabley-dnsext-eui48-eui64-rrtypes-04). In practice, the IETF has published a RFC to suit the requirements (it was a voluntary measure instead of a formal requirement) of one country. draft-jabley-dnsext-eui48-eui64-rrtypes-04 is an odd case. My guess is that the requirements were set because of a problem of monopoly. I have not looked into whether the transfer of data violates the expectations of the user. I understand that the draft is about standardizing [1] a data format and not the transfer of data. Section 8 of the draft says everything correctly except that it doesn't provide adequate security guidance. I believe that Joe tried to do the right thing. I am not comfortable objecting to publication as I don't know the path forward. I personally would not support publication. That can easily be overcome and I won't do anything about it. Regards, -sm 1. I did read Section 2 carefully.
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 2013-05-28, at 3:38, SM s...@resistor.net wrote: In theory the IETF does not publish RFCs to suit the regulations of one country (see use-case in draft-jabley-dnsext-eui48-eui64-rrtypes-04). In practice, the IETF has published a RFC to suit the requirements (it was a voluntary measure instead of a formal requirement) of one country. Note that there's no suggestion that these RRTypes are required by the CRTC. The example given was for a situation where Interop would have been beneficial (so that cable resellers have an obvious, stable and supported way of encoding this kind of information. draft-jabley-dnsext-eui48-eui64-rrtypes-04 is an odd case. My guess is that the requirements were set because of a problem of monopoly. The opposite actually: cable operators are required to provide access to subscribers on behalf of third parties in order to promote competition. There are multiple such cable providers and multiple such resellers. (TekSavvy is one such reseller of multiple cable companies' access networks.) I have not looked into whether the transfer of data violates the expectations of the user. The CRTC's decisions are public, and one might hope they would show their working. The Canadian courts have been pretty protective of user privacy in general, I would say. I understand that the draft is about standardizing [1] a data format and not the transfer of data. Section 8 of the draft says everything correctly except that it doesn't provide adequate security guidance. Feel free to point out the gaps, and/or to suggest text. I believe that Joe tried to do the right thing. I am not comfortable objecting to publication as I don't know the path forward. I personally would not support publication. That can easily be overcome and I won't do anything about it. Thanks for the thoughtful review. Joe
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 Joe, At 03:12 28-05-2013, Joe Abley wrote: Note that there's no suggestion that these RRTypes are required by the CRTC. The example given was for a situation where Interop would have been beneficial (so that cable resellers have an obvious, stable and supported way of encoding this kind of information. Ok. The opposite actually: cable operators are required to provide access to subscribers on behalf of third parties in order to promote competition. There are multiple such cable providers and multiple such resellers. Yes. (TekSavvy is one such reseller of multiple cable companies' access networks.) Ok. Feel free to point out the gaps, and/or to suggest text. I'll give it a try. I suggest talking to the Area Director to see what's workable. I would drop Section 6 of the draft as I no longer need a use case to get an RRTYPE assignment. There is a typo for RRTPES in Section 7. I would start Section 9 with There are privacy concerns I would replace the third paragraph with: The user should be provided with a disclosure statement that clearly mentions: - How the EUI addresses published in DNS will be used and protected - What privacy policies are applicable The disclosure statement is to enable the user to make an informed decision about whether the disclosure of the information is acceptable considering local laws and customs. I would rename Section 9 as Privacy Considerations. I don't know what to put in the new Security Considerations section. Maybe Publishing EUI addresses in DNS lowers the security of the Internet. 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 5/28/13 9:41 AM, SM wrote: Hi Joe, At 03:12 28-05-2013, Joe Abley wrote: Note that there's no suggestion that these RRTypes are required by the CRTC. The example given was for a situation where Interop would have been beneficial (so that cable resellers have an obvious, stable and supported way of encoding this kind of information. Ok. The opposite actually: cable operators are required to provide access to subscribers on behalf of third parties in order to promote competition. There are multiple such cable providers and multiple such resellers. Yes. (TekSavvy is one such reseller of multiple cable companies' access networks.) Ok. Feel free to point out the gaps, and/or to suggest text. I'll give it a try. I suggest talking to the Area Director to see what's workable. I would drop Section 6 of the draft as I no longer need a use case to get an RRTYPE assignment. There is a typo for RRTPES in Section 7. I would start Section 9 with There are privacy concerns I would replace the third paragraph with: For some background. The usecase facilitates discussion and justification of the draft. It is not about justifying the RRtype (which was assigned under the rules of that registry). It's in there because the sponsoring AD requested it after feedback during the dnsext dicussion. The user should be provided with a disclosure statement that clearly mentions: - How the EUI addresses published in DNS will be used and protected - What privacy policies are applicable The disclosure statement is to enable the user to make an informed decision about whether the disclosure of the information is acceptable considering local laws and customs. I would rename Section 9 as Privacy Considerations. I don't know what to put in the new Security Considerations section. Maybe Publishing EUI addresses in DNS lowers the security of the Internet. 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 5/20/13 6:44 AM, 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 I would direct the attention of the commentors to draft 04 http://www.ietf.org/internet-drafts/draft-jabley-dnsext-eui48-eui64-rrtypes-04.txt Which addresses concerns expressed in IETF last call over the intended status. It also incorporates edits proposed by John Klensin in his review. Notes: from the author: - changed intended status to informational - incorporation of John's suggestions in the Terminology section, to indicate that we're using 2119 keywords even though this is not a standards track document - added a couple of sentences to the security considerations sections to underscore the fact that this document specifies optional mechanisms that people might well not use if privacy considerations dictate otherwise 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. Abstract 48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended Unique Identifiers (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g. ethernet. This document defines two new DNS resource record types, EUI48 and EUI64, for encoding ethernet addresses in the DNS. The file can be obtained via http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ballot/ No IPR declarations have been submitted directly on this I-D.
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
while i appreciate joe's listening to my other comments on the draft, i still strongly object to publication of this draft as an rfc for the reasons made very clear in the sec cons. please read the summary section of rfc 2804. randy
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 Mon, May 27, 2013 at 7:54 PM, Randy Bush ra...@psg.com wrote: while i appreciate joe's listening to my other comments on the draft, i still strongly object to publication of this draft as an rfc for the reasons made very clear in the sec cons. please read the summary section of rfc 2804. While the RFC should not be materially misleading, I don't think there is a requirement for Informational RFCs to guarantee any particular level or security or privacy. RFC 2804 is about the security of communications content, not the security of statically stored address information. I'm not denying the applicability of some security considerations, I'm just saying that RFC 2804 doesn't seem to me to be particularly applicable. In any case, the final part of the summary section of RFC 2804 calls for the publication of specifications that might affect security. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com randy
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
With respect to the question of proposed standard. What changes if the requested status is informational? I think just get rid of the normative language - SHOULDs, MUSTs, etc. that is orthogonal to info/ps next unnecessary rathole, please randy
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
joe, i spent time actually reading the document and commenting on it, one was a substantive comment, at least to me. any chance you could pull yourself away from the exemplary anti-productive nitpicking maelstrom for a few minutes and respond? thanks. randy
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 Randy, On 2013-05-21, at 11:23, Randy Bush ra...@psg.com wrote: i have read the draft. if published, i would prefer it as a proposed standard as it does specify protocol data objects. Noted, thanks. It does seem that the main objection to the standards track for this document is that I accidentally erred on the side of running code before the document was last-called. This does seem like a poor reason to move the document to informational, but since my primary goal with this has always been to provide a specification (and since the specification is trivial) it's not especially clear to me why a fight for the standards track would have more than semantic benefits. where you goin' with that gun in your hand? Going to kill my old lady. Not really. i am not at all sanguine about the issues raised in the in sec cons. i accept that NTRE038D may have asked that these be in the dns, but seems to me that it is ill advised and some other means to meet their actual needs might be found. e.g. what's the matter with logs? I agree it was a strange implementation decision, almost as though more neutral, technical common sense might have been helpful in the process, an unusual situation for a regulator to find themselves in, no doubt. But at this point, it is what it is. The distaste of many here notwithstanding, the DNS is widely used today as a convenient distributed database for the storage of non-public data. I've had feedback from others who say that they are doing similar things with TXT records, and who welcomed the availability of a specific type, so regardless of the merits of NTRE038D the idea seems to have more general applicability. The text in the Security Considerations section was a response to concerns raised on the dnsext list that someone might look at the RRType spec and conclude that publishing subscriber (or other privacy-busting) link-layer addresses in the public namespace was something that was desirable or necessary. I don't personally see that as a great concern (I don't think operators are sufficiently naive) but the warning that subsequently appeared in section 8 did not seem inappropriate. nits you are welcome to ignore. 1 - intro - do we have a standard way to refer to the dns specs as tuned in 42 subsequent rfcs since 1035? No, as Andrew mentioned. 3.2 and 4.2 the presentation format specs might be simpler if the examples in 5 were moved there Good idea. 6 - the example use case is as much or more a motivation as an example It was certainly the motivation for the draft; the ugly and varied RR schemas used made me reach for grep to find the sensible way to store MAC-48 addresses in the DNS; there wasn't one. In a brief moment of spring-cleaning fervour I decided to try and make things better for the next person who has to parse this kind of stuff. I could just as well have made that section title Motivation for Bothering but Example Use Case seemed like a better fit for the context I imagined future readers might have. Joe
Re: Proposed Standards and Expert Review (was: 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))
From: John C Klensin john-i...@jck.com My problem here, which I hope was clear from the note from which you quoted, is that a request/document in the second category was proposed for Standards Track and then that comments that would be entirely appropriate for a Last Call on a Standards Track document were essentially rejected on the grounds that they would require changes to already-registered RRTYPEs. This seems to be the only truly controversial point, and it is very important. The IETF does not promote something to a standard just because someone (or even lots of people) are already doing it. It is, however, perfectly acceptable to document it, and even to document that some other group has anointed it as a standard within *their* practice. Dale
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
From: Keith Moore mo...@network-heretics.com On 05/21/2013 10:04 AM, Joe Abley wrote: With respect, *my* question as the author of this document is simply whether the specification provided is unambiguous and sufficient. It was my understanding that this was the question before the community in this last call. The criteria for Proposed Standard are quite a bit higher than that. See RFC 2026 section 4.1.1. Coming into this from the outside, the issues are interesting. I originally thought RRTYPEs are scarce, since all the ones I was aware of are less than 256. But it turns out that RRTYPEs are 16 bit integers, and we've only consumed about 110 of them in ~25 years; we have about 15,000 years' supply of them. So they can be handed out rather generously. There actually is a standard for allocating RRTYPEs, which is RFC 6195 (section 3.1). RRTYPEs are to be handed out rather freely. OTOH, the standards for Proposed Standard are stricter. In regard to the question of whether to use one RRTYPE or two, it seems that the question is whether, in practice, it is common to want to query for both EUI-48 and EUI-64 for the same domain name at the same time. In regard to *how* to subtype a single RRTYPE, the resource records themselves contain a DATA length field (RDLENGTH, see RFC 1035 section 3.2.1), so if we used only one RRTYPE, the RDLENGTH field would differentiate EUI-48 from EUI-64. There are 768 RFCs that have INFORMATIONAL status and contain the word MUST -- and that is over 10% of the total number of RFCs published to date. So it looks like RFC 2119 terminology is commonly used in informational RFCs. Personally, it seems like a good idea. If you want to notify the world of a privately-developed protocol, you want to be able to say MUST and SHOULD; labeling it as INFORMATIONAL makes clear that the IETF hasn't endorsed the protocol. Dale
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 Wed, May 22, 2013 at 10:03 PM, Dale R. Worley wor...@ariadne.com wrote: ... Coming into this from the outside, the issues are interesting. I originally thought RRTYPEs are scarce, since all the ones I was aware of are less than 256. But it turns out that RRTYPEs are 16 bit integers, and we've only consumed about 110 of them in ~25 years; we have about 15,000 years' supply of them. So they can be handed out rather generously. There actually is a standard for allocating RRTYPEs, which is RFC 6195 (section 3.1). RRTYPEs are to be handed out rather freely. Obsoleted by RFC 6895 but not too much change. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com
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 6:42 PM, Brian E Carpenter wrote: 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? two observations If you have an iab range the eui label would get inserted in the middle of the IAB base value iirc. that sounds sort of appauling to read/decode. Second it's not just a representation it's an encapsulation (you could if you so choose use a mac-48 on an eui-64 supporting link layer legitimately using the encapsulation). I'm sure some ugly bridge device that I want nothing to do with will do that some time in the future, it does therefore seem slightly desirable to render them as they are rather than in some canonical form that is both. Brian
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 05/20/2013 04:08 PM, Brian E Carpenter wrote: 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. And yet, multifaced DNS is also a bad idea, and probably not the sort of thing that IETF should encourage with a MUST. Publishing EUI-XX addresses in the DNS is a bad idea. I get the impression that we're bending over backwards to try to create new security risks with this document, and people are trying to justify it by citing freedom to innovate. IMO, that's not the kind of innovation that IETF should be endorsing. Keith
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 2013-05-21, at 09:36, Keith Moore mo...@network-heretics.com wrote: Publishing EUI-XX addresses in the DNS is a bad idea. With respect, *my* question as the author of this document is simply whether the specification provided is unambiguous and sufficient. It was my understanding that this was the question before the community in this last call. There has been very little review of the actual specification in this thread to date. RRType assignments are made based on expert review, not IETF consensus, document published, or any other criteria. In this case, the RRTypes have been assigned and are known to have three independent implementations. I'm not sure how the Internet benefits from not publishing a specification in a sensible place (and the RFC series is surely the most sensible place). *I* think it's a good idea for this specification to be published as an RFC. The topics of whether the current RRType assignment process is appropriate, or whether storing these IEEE addresses in the DNS is a good or bad idea or whether sub-typing would be useful in any as-yet unknown future use case seem entirely tangential. This is not to say they are not useful topics, but I don't see how they relate to this document. Whether or not this document proceeds has nothing to do with any of that. I get the impression that we're bending over backwards to try to create new security risks with this document, and people are trying to justify it by citing freedom to innovate. IMO, that's not the kind of innovation that IETF should be endorsing. I have no real idea where you get that impression. The goal of this document is to document the use of RRTypes that have already been assigned, to provide a more structured option for encoding data that is already published in the DNS using non-interoperable and clumsy encoding schemes. Nothing more. Joe
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 05/21/2013 10:04 AM, Joe Abley wrote: On 2013-05-21, at 09:36, Keith Moore mo...@network-heretics.com wrote: Publishing EUI-XX addresses in the DNS is a bad idea. With respect, *my* question as the author of this document is simply whether the specification provided is unambiguous and sufficient. It was my understanding that this was the question before the community in this last call. The criteria for Proposed Standard are quite a bit higher than that. See RFC 2026 section 4.1.1. TThe topics of whether the current RRType assignment process is appropriate, or whether storing these IEEE addresses in the DNS is a good or bad idea or whether sub-typing would be useful in any as-yet unknown future use case seem entirely tangential. Assignment of the RR types (though IMO unfortunate) is a separate issue.Granting Proposed Standard status would essentially be an endorsement of this practice by IETF. This is not to say they are not useful topics, but I don't see how they relate to this document. Whether or not this document proceeds has nothing to do with any of that. I get the impression that we're bending over backwards to try to create new security risks with this document, and people are trying to justify it by citing freedom to innovate. IMO, that's not the kind of innovation that IETF should be endorsing. I have no real idea where you get that impression. The goal of this document is to document the use of RRTypes that have already been assigned, to provide a more structured option for encoding data that is already published in the DNS using non-interoperable and clumsy encoding schemes. Nothing more. Perhaps Informational or Experimental would be a better label for this document, then. Keith
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 2013-05-21, at 10:18, Keith Moore mo...@network-heretics.com wrote: Perhaps Informational or Experimental would be a better label for this document, then. Informational was my original plan; I was persuaded by Some People that the standards track was more appropriate. As I mentioned, my objective is simply to publish the specification. If the community is more comfortable with the publication objective being met with informational rather than standards track, I'm fine with that. Joe
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 10:04 -0400 Joe Abley jab...@hopcount.ca wrote: ... There has been very little review of the actual specification in this thread to date. RRType assignments are made based on expert review, not IETF consensus, document published, or any other criteria. In this case, the RRTypes have been assigned and are known to have three independent implementations. I'm not sure how the Internet benefits from not publishing a specification in a sensible place (and the RFC series is surely the most sensible place). *I* think it's a good idea for this specification to be published as an RFC. Joe, as the person with the dubious distinction of having started this thread when the Last Call was announced, I'm not questioning the desirability of good documentation of any RRTYPE, nor do I doubt the fact that these were properly assigned and are deployed. I also agree with you that questions about the expert review process belong elsewhere (and I don't know that I'd want to change it in any formal way). Had you written this document as a this is how it is -- this is to tell the community about what is deployed informational one that described the RRTYPEs and asked that it be published as Informational, I wouldn't have been likely to raise any objections. Had the Security Considerations section or privacy discussion described the risks, possibly explained how they might be mitigated, but basically said if those are a big enough problem for you, don't use this facility, that wouldn't have been a problem for me: I can't speak for Keith, but you might have not heard from him either. But the document has been Last Called as an Proposed Standard, not that type of informational document. That, at least to me, makes both discussions of your design decisions and the relevant security and privacy mechanisms entirely appropriate because Proposed Standard requires IETF consensus approval of the whole package, quite independently of your ability to register a new RRTYPE (or two or three). All I'm asking for is that, if you want this as a Proposed Standard you carefully and convincingly describe your design rationale. I want that both because it seems generally appropriate in this case and because, if someone comes along and wants to register the EUI64-with-embedding or EUI-with-48-64-switch RRTYPEs and there is pushback because EUI48 and EUI64 are already registered, I think it is important that pushback be based on documented and well-reasoned design choices, not an appeal to the supposed authority of the IETF. You wrote a bit later: Informational was my original plan; I was persuaded by Some People that the standards track was more appropriate. As I mentioned, my objective is simply to publish the specification. It might be that no one could know before this discussion started but, at least in retrospect, those Some People may have steered you in the wrong direction if your goal and theirs was to get something published without putting various design decisions into the spotlight. To say what Keith may be saying in different language, there is lots of stuff floating around the Internet of which the IETF might not approve. Publishing Informational RFCs containing descriptions of them so they can be understood is still a good thing. If someone wants to follow those RFCs with considered harmful or at least disgusting commentary and try to get it published, that is a separate issue. But asking for Proposed Standard is a rather different matter because it requires an IETF consensus assertion that the criteria of RFC 2026 have been satisfied. If you don't think that level of scrutiny is appropriate for this situation, ask that the document be pulled from Last Call, review it to make it as descriptive and declarative as possible rather than even implicitly normative (I'd have to reread, but I think it is at least close on that criterion), and then resubmit it as an individual or independent submission for Informational publication. I have no real idea where you get that impression. The goal of this document is to document the use of RRTypes that have already been assigned, to provide a more structured option for encoding data that is already published in the DNS using non-interoperable and clumsy encoding schemes. Nothing more. Ok. That, to me, is a perfect recipe for an Informational document. It may, separately, be a call for a much more aggressive denunciation and deprecation of overloaded and trickily-encoded TXT RRs than RFC 5507 provides, maybe as a BCP rather than IAB-Informational but that is also a separate issue and problem. best, 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
joe, i have read the draft. if published, i would prefer it as a proposed standard as it does specify protocol data objects. where you goin' with that gun in your hand? i am not at all sanguine about the issues raised in the in sec cons. i accept that NTRE038D may have asked that these be in the dns, but seems to me that it is ill advised and some other means to meet their actual needs might be found. e.g. what's the matter with logs? nits you are welcome to ignore. 1 - intro - do we have a standard way to refer to the dns specs as tuned in 42 subsequent rfcs since 1035? 3.2 and 4.2 the presentation format specs might be simpler if the examples in 5 were moved there 6 - the example use case is as much or more a motivation as an example randy
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
Not related to the draft as such (whose publication, incidentally, I support): On Tue, May 21, 2013 at 10:23:03PM +0700, Randy Bush wrote: 1 - intro - do we have a standard way to refer to the dns specs as tuned in 42 subsequent rfcs since 1035? Alas, no. Some time ago, DNSEXT was re-vivified in an effort to write a protocol profile that would have been a nice roll-up document to do this. But there was no energy to get the work done and the drafts languished for months without any changes. It still seems a worthwhile project, but there is no evidence that we have a population interested enough to do the work. Best, A -- Andrew Sullivan a...@anvilwalrusden.com
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/21/13 8:06 AM, John C Klensin wrote: All I'm asking for is that, if you want this as a Proposed Standard you carefully and convincingly describe your design rationale. I want that both because it seems generally appropriate in this case and because, if someone comes along and wants to register the EUI64-with-embedding or EUI-with-48-64-switch RRTYPEs and there is pushback because EUI48 and EUI64 are already registered, It seems like we're still re-arguing the assignment of the rr-types. It doesn't seem like future assignments are likely to have anymore pushback than present. With respect to the question of proposed standard. What changes if the requested status is informational?
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 05/21/2013 11:46 AM, joel jaeggli wrote: With respect to the question of proposed standard. What changes if the requested status is informational? I think just get rid of the normative language - SHOULDs, MUSTs, etc. Given that the RR types have already been assigned, documenting them seems entirely appropriate. Keith
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 2013-05-21, at 11:50, Keith Moore mo...@network-heretics.com wrote: On 05/21/2013 11:46 AM, joel jaeggli wrote: With respect to the question of proposed standard. What changes if the requested status is informational? I think just get rid of the normative language - SHOULDs, MUSTs, etc. From the perspective of giving guidance to people implementing these RRTypes, it seems to me that the normative language is useful, perhaps even necessary, to ensure interoperability. I admit I have not done my homework here; is the suggestion that the 2119 normative language cannot (MUST NOT? :-) appear in an informational document? Joe
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 05/21/2013 11:52 AM, Joe Abley wrote: On 2013-05-21, at 11:50, Keith Moore mo...@network-heretics.com wrote: On 05/21/2013 11:46 AM, joel jaeggli wrote: With respect to the question of proposed standard. What changes if the requested status is informational? I think just get rid of the normative language - SHOULDs, MUSTs, etc. From the perspective of giving guidance to people implementing these RRTypes, it seems to me that the normative language is useful, perhaps even necessary, to ensure interoperability. I admit I have not done my homework here; is the suggestion that the 2119 normative language cannot (MUST NOT? :-) appear in an informational document? 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Keith
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 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote: On 05/21/2013 11:52 AM, Joe Abley wrote: On 2013-05-21, at 11:50, Keith Moore mo...@network-heretics.com wrote: On 05/21/2013 11:46 AM, joel jaeggli wrote: With respect to the question of proposed standard. What changes if the requested status is informational? I think just get rid of the normative language - SHOULDs, MUSTs, etc. From the perspective of giving guidance to people implementing these RRTypes, it seems to me that the normative language is useful, perhaps even necessary, to ensure interoperability. I admit I have not done my homework here; is the suggestion that the 2119 normative language cannot (MUST NOT? :-) appear in an informational document? 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Then I think we've just identified a reason why this document should be on the standards track. Joe
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 05/21/2013 11:57 AM, Joe Abley wrote: On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Then I think we've just identified a reason why this document should be on the standards track. Actually I think that what we need is a BCP that says that DNS is not intended, not designed, and SHOULD NOT be used for dissemination of any information that is not deemed acceptable for widespread public distribution. Neither the DNS protocol nor DNS implementations are designed to meet the security requirements of such applications, and DNS is too widely deployed to change that. Keith
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
Keith == Keith Moore mo...@network-heretics.com writes: Keith 2119 language is intended to describe requirements of Keith standards-track documents. Informational documents cannot Keith impose requirements. i think using 2119 language in informational documents is often appropriate and there are certainly plenty of examples of informational documents that use 2119 language.
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 21, 2013, at 8:56 AM, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents. Can you support that statement with a reference to an RFC or an IESG statement that supports it? Informational documents cannot impose requirements. Same request. I don't find either statement supported by RFC 2119 or 2026, or any updates to the latter, but I may have missed it. --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 2013-05-21, at 12:02, Keith Moore mo...@network-heretics.com wrote: Actually I think that what we need is a BCP that says that DNS is not intended, not designed, and SHOULD NOT be used for dissemination of any information that is not deemed acceptable for widespread public distribution. Neither the DNS protocol nor DNS implementations are designed to meet the security requirements of such applications, and DNS is too widely deployed to change that. I'd be quite happy to work on such a document if there were others keen to contribute, review, etc, but I don't see it as anything specific to the specifications under discussion here. What am I missing? How is EUI48 more dangerous to the world than (say) TXT or NSAP? Joe
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
The scope of RFC 2119 is clearly standards-track documents. Documents that aren't standards should not be worded as if they were; this is likely to cause confusion about the status of the document. Sent from my iPhone On May 21, 2013, at 12:08 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On May 21, 2013, at 8:56 AM, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents. Can you support that statement with a reference to an RFC or an IESG statement that supports it? Informational documents cannot impose requirements. Same request. I don't find either statement supported by RFC 2119 or 2026, or any updates to the latter, but I may have missed it. --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 May 21, 2013, at 9:23 AM, Keith Moore mo...@network-heretics.com wrote: The scope of RFC 2119 is clearly standards-track documents. I'll take that as a no. The scope is mentioned exactly once, in the abstract but not in the body of the document. Documents that aren't standards should not be worded as if they were; this is likely to cause confusion about the status of the document. I'm pretty sure that you as AD approved Informational RFCs that used 2119 language, and that this was discussed during your tenure on the IESG. The fact that there none of the updates to RFC 2026 even mention this suggests that there was not IETF consensus to the opinion. --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 Tuesday, May 21, 2013 08:46 -0700 joel jaeggli joe...@bogus.com wrote: On 5/21/13 8:06 AM, John C Klensin wrote: All I'm asking for is that, if you want this as a Proposed Standard you carefully and convincingly describe your design rationale. I want that both because it seems generally appropriate in this case and because, if someone comes along and wants to register the EUI64-with-embedding or EUI-with-48-64-switch RRTYPEs and there is pushback because EUI48 and EUI64 are already registered, It seems like we're still re-arguing the assignment of the rr-types. I, at least, am not. It doesn't seem like future assignments are likely to have anymore pushback than present. Unless you are going to join the group that says it is perfectly ok to have multiple IETF standards-track documents that specify conflicting ways to do almost the same thing, it seems to me that pushback against other ways to handle EUI data is inherent in the standards track designation. The last time the IETF had the argument about conflicting standards, I think there was rough consensus that it was generally a bad idea even if some of us thought that exceptions might occasionally be desirable. With respect to the question of proposed standard. What changes if the requested status is informational? I don't agree with Keith that the removal of the keywords specified in 2119 is either necessary or sufficient (nor with the generalization that such language should never appear in Informational documents). Like Sam, I think that such language may sometimes be entirely appropriate to an informational/descriptive document although I also believe that it should be used with care. Since I don't have such an easy solution, answering your question would require a paragraph-by-paragraph review of the document, not the more overview-level reading I gave it before participating in this thread. Having made that proposal, I feel obligated to do that reading --essentially an editing pass-- but only if (i) you and Joe are inclined to process the document as Informational if the edit is satisfactory and (ii) it is understood that those edits will almost certainly not resolve the security and privacy concerns that have been raised, notably by Keith and Brian if the simple change to Informational does not do so. Note that (i) is not a request for a promise or decision, only a good-faith willingness to move in that direction. If I am going to do this, I'd prefer to make a pass and then sort out residual editorial details off list with Joe and anyone else who is significantly interested rather than trying to do editing on this list. If that seems reasonable and appropriate, I can commit to getting this done within the next week, maybe sooner, but not today. best, john
Proposed Standards and Expert Review (was: 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))
(Changing Subject lines -- this is about a set of general principles that might affect this document, not about the document) --On Tuesday, May 21, 2013 22:23 +0700 Randy Bush ra...@psg.com wrote: joe, i have read the draft. if published, i would prefer it as a proposed standard as it does specify protocol data objects. I would generally have that preference too. But it seems to me that the combination of -- RRTYPEs (and a bunch of other protocol data objects associated with different protocols) are allocated on expert review -- The fact that those protocol data objects have already been allocated is used to preempt IETF consideration of issues that normally go into Standards Track documents, including the criteria for Proposed Standards in 2026. is fundamentally bad news for reasons that have little to do with this document or RRTYPEs specifically. If the combination is allowed, it provides an attack vector on the standards process itself because someone can get a parameter approved on the basis of ability to fill out a template and then insist that the IETF approve and standardize it simply because it is registered and in use.That would turn allocation of parameters by expert review (and some related issues connected to deployed therefore it is ok -- watch for another note) into a rather large back door for standardization that could bypass the 2026 and other less formal criteria, the IETF's historically-strong position on change control, and so on. These are not new issues and we have historically dealt with them in a number of ways that don't require moving away from liberal allocation policies and toward the IETF is in charge of the Internet and has to approve everything. For example, we have decided that media types don't have to be standardized although certain types of names do. People then get to choose between easy and quick registration and standardization, but don't get to use the first to leverage the second. One could argue that the pre-IETF (and very early) division between system and user port numbers reflects the same sort of distinction between a high standard for justification and documentation and much lower ones. It is possible (although I'm not convinced) that this discussion should suggest some tuning of the allocation model for RRTYPEs. Probably that model is ok and we just need to figure out clearer ways to say if you want standards track, don't get an allocation first and try to use that as justification because you will get a real Last Call anyway and everyone will end up a little irritated. Or something else may be appropriate. But it seems to me that, as soon as one wants to say all protocol parameters or other data values should be standardized then allocation models based on expert review are inappropriate. For the RRTYPE case, that issue should, IMO, have been pushed with the relevant WG when the decision to allow expert review was made (and, again, IMO, that cure would be worse than the disease because it would indirectly drive more folks toward overloading of TXT and other existing types). best, john where you goin' with that gun in your hand? i am not at all sanguine about the issues raised in the in sec cons. i accept that NTRE038D may have asked that these be in the dns, but seems to me that it is ill advised and some other means to meet their actual needs might be found. e.g. what's the matter with logs?
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/21/13 9:02 AM, Keith Moore wrote: On 05/21/2013 11:57 AM, Joe Abley wrote: On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Then I think we've just identified a reason why this document should be on the standards track. Actually I think that what we need is a BCP that says that DNS is not intended, not designed, and SHOULD NOT be used for dissemination of any information that is not deemed acceptable for widespread public distribution. The basically rules out every internal split horizon use of DNS in existence. scope matters for this application just as it does for any zone you shouldn't be exposing to the outside world. Neither the DNS protocol nor DNS implementations are designed to meet the security requirements of such applications, and DNS is too widely deployed to change that. Keith
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 05/21/2013 01:35 PM, joel jaeggli wrote: On 5/21/13 9:02 AM, Keith Moore wrote: On 05/21/2013 11:57 AM, Joe Abley wrote: On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Then I think we've just identified a reason why this document should be on the standards track. Actually I think that what we need is a BCP that says that DNS is not intended, not designed, and SHOULD NOT be used for dissemination of any information that is not deemed acceptable for widespread public distribution. The basically rules out every internal split horizon use of DNS in existence. Indeed. Things have gotten way too far out of hand. Again, DNS was not engineered for this purpose, and the hacks that people have employed like split-horizon DNS do not and cannot fix the underlying problems. Keith
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 05/21/2013 12:30 PM, Paul Hoffman wrote: Documents that aren't standards should not be worded as if they were; this is likely to cause confusion about the status of the document. I'm pretty sure that you as AD approved Informational RFCs that used 2119 language, and that this was discussed during your tenure on the IESG. My recollection is that other ADs were the ones who insisted that 2119 language not be used for Informational documents. I was more concerned about other things, but I could see their point. If the document is going to be published as Informational, rewording the document to remove 2119 language is my recommendation. But it's not something I feel like making a huge fuss over. If the document is still being considered as Proposed Standard, 2119 language would be appropriate. But I believe that this RRtype is fundamentally inappropriate for the standards track. Keith
Re: Proposed Standards and Expert Review (was: 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 21, 2013, at 1:32 PM, John C Klensin john-i...@jck.com wrote: (Changing Subject lines -- this is about a set of general principles that might affect this document, not about the document) --On Tuesday, May 21, 2013 22:23 +0700 Randy Bush ra...@psg.com wrote: joe, i have read the draft. if published, i would prefer it as a proposed standard as it does specify protocol data objects. I would generally have that preference too. But it seems to me that the combination of -- RRTYPEs (and a bunch of other protocol data objects associated with different protocols) are allocated on expert review -- The fact that those protocol data objects have already been allocated is used to preempt IETF consideration of issues that normally go into Standards Track documents, including the criteria for Proposed Standards in 2026. is fundamentally bad news for reasons that have little to do with this document or RRTYPEs specifically. If the combination is allowed, it provides an attack vector on the standards process itself because someone can get a parameter approved on the basis of ability to fill out a template and then insist that the IETF approve and standardize it simply because it is registered and in use.That would turn allocation of parameters by expert review (and some related issues connected to deployed therefore it is ok -- watch for another note) into a rather large back door for standardization that could bypass the 2026 and other less formal criteria, the IETF's historically-strong position on change control, and so on. John, There are basically 3 different kinds of DNS RRtypes, - types that affect the behavior of the DNS protocol and are cached by resolvers, - types that have DATA and are cached by resolvers - meta Types that may affect processing but are not cached. DNSEXT in its wisdom has deemed the second group to be harmless as far as DNS is concerned and getting code to store data in DNS is a good thing, thus it is easy to get it. Getting code for the other classes requires IETF standards action. Documents that describe the DATA types use are encouraged to be published as Informational or some other stable reference. These are not new issues and we have historically dealt with them in a number of ways that don't require moving away from liberal allocation policies and toward the IETF is in charge of the Internet and has to approve everything. For example, we have decided that media types don't have to be standardized although certain types of names do. People then get to choose between easy and quick registration and standardization, but don't get to use the first to leverage the second. One could argue that the pre-IETF (and very early) division between system and user port numbers reflects the same sort of distinction between a high standard for justification and documentation and much lower ones. As I explained DNS RRtype allocation has this separation. It is possible (although I'm not convinced) that this discussion should suggest some tuning of the allocation model for RRTYPEs. Probably that model is ok and we just need to figure out clearer ways to say if you want standards track, don't get an allocation first and try to use that as justification because you will get a real Last Call anyway and everyone will end up a little irritated. Or something else may be appropriate. But it seems to me that, as soon as one wants to say all protocol parameters or other data values should be standardized then allocation models based on expert review are inappropriate. For the RRTYPE case, that issue should, IMO, have been pushed with the relevant WG when the decision to allow expert review was made (and, again, IMO, that cure would be worse than the disease because it would indirectly drive more folks toward overloading of TXT and other existing types). If the expert thinks an application crosses from DATA space to Control space he is expected to reject the application and ask for clarification. So far nothing has shown up that crosses this boundary, so there is no problem. I will go as far as saying why should there be higher bar for getting a DNS RRTYPE than MIME media type ? Olafur
Re: Proposed Standards and Expert Review (was: 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 15:42 -0400 Olafur Gudmundsson o...@ogud.com wrote: ... John, There are basically 3 different kinds of DNS RRtypes, - types that affect the behavior of the DNS protocol and are cached by resolvers, - types that have DATA and are cached by resolvers - meta Types that may affect processing but are not cached. DNSEXT in its wisdom has deemed the second group to be harmless as far as DNS is concerned and getting code to store data in DNS is a good thing, thus it is easy to get it. Getting code for the other classes requires IETF standards action. Seems perfectly reasonable Documents that describe the DATA types use are encouraged to be published as Informational or some other stable reference. Reasonable too. My problem here, which I hope was clear from the note from which you quoted, is that a request/document in the second category was proposed for Standards Track and then that comments that would be entirely appropriate for a Last Call on a Standards Track document were essentially rejected on the grounds that they would require changes to already-registered RRTYPEs. These are not new issues and we have historically dealt with them in a number of ways that don't require moving away from liberal allocation policies and toward the IETF is in charge of the Internet and has to approve everything. For example, we have decided that media types don't have to be standardized although certain types of names do. People then get to choose between easy and quick registration and standardization, but don't get to use the first to leverage the second. One could argue that the pre-IETF (and very early) division between system and user port numbers reflects the same sort of distinction between a high standard for justification and documentation and much lower ones. As I explained DNS RRtype allocation has this separation. But the request for publication in the Standards Track violates it. It is possible (although I'm not convinced) that this discussion should suggest some tuning of the allocation model for RRTYPEs. Probably that model is ok and we just need to figure out clearer ways to say if you want standards track, don't get an allocation first and try to use that as justification because you will get a real Last Call anyway and everyone will end up a little irritated. Or something else may be appropriate. But it seems to me that, as soon as one wants to say all protocol parameters or other data values should be standardized then allocation models based on expert review are inappropriate. For the RRTYPE case, that issue should, IMO, have been pushed with the relevant WG when the decision to allow expert review was made (and, again, IMO, that cure would be worse than the disease because it would indirectly drive more folks toward overloading of TXT and other existing types). If the expert thinks an application crosses from DATA space to Control space he is expected to reject the application and ask for clarification. We are agreed that isn't an issue here. So far nothing has shown up that crosses this boundary, so there is no problem. I will go as far as saying why should there be higher bar for getting a DNS RRTYPE than MIME media type ? With the understanding that I don't think it has anything to do with this situation, one could justify a different (and maybe higher) bar in two ways. First, the media type names are structured so that, a few historical exceptions aside, one can tell what category they are in by looking at the names. To get that effect with RRTYPEs, one would have to take the categories you spell out about and create (as a silly example) type names starting in 1 for the first category, 2 for the second, and so on, or otherwise lexically distinguish the second category from the other two. Second, the potential code space for media types may be a tad larger than the potential RRTYPE code space. But, again, I think the question is irrelevant here -- I've not advocating changing the allocation rules, only keeping the relationship between already-allocated RRTYPEs and the Standards Track into the categories you have described above. --On Tuesday, May 21, 2013 15:24 -0400 Joe Abley jab...@hopcount.ca wrote: Code-points in the RRType registry are assigned by expert review (not simply by filling out a template as someone suggested earlier). I was the one who said filling out a template and that reflects a bad attitude toward many expert reviews. That attitude and what underlies it has nothing to do with this situation. If the suggestion is that the standards track is not available for any work that involves a code point that was assigned early, then I wonder what process is imagined for any future DNS work which aims at the standards track. Presumably the same mechanism that has now been used for other registrations that are normally expert review (or less) but
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: 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.
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: 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: 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: 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.
