Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
At 15:21 29-05-2013, Ted Lemon wrote: I didn't say that I support the draft; just what I think could be done to somewhat mitigate its scope. My personal (non-hat) feeling about the draft is that if there is I did not read those messages as meaning that you support the draft or that there was anything negative. At 18:34 29-05-2013, Joe Abley wrote: The original motivation for requesting code-point assignments for new RRTypes which would facilitate a clean encoding of EUI-48 and EUI-64 addresses in the DNS resulted from my distaste for the evident lack of consistency in approach taken in response to the CRTC's general requirement that cable operators publish this kind of data in the DNS, for internal, authenticated access by resellers of their access networks in Canada. It's not at all certain or even likely that the CRTC-mandated systems will ever use these RRTypes. That ship has surely sailed. The reason for requesting the code-points was to make future such situations less messy, and more likely to result in DNS schemas (if that's a phrase) that were consistent and parseable. Code-points were assigned following the documented process, which relies upon expert review. To support that review, I wrote a specification for their use as an I-D (intended status: experimental). Note that by specification I mean a technical description of the encoding and protocol considerations associated with EUI48 and EUI64, and not any kind of applicability statement or guidance for how the RRTypes should be used. I've had feedback from a small number of people who are already in the habit of publishing MAC addresses in the DNS as part of (as I understand it) inventory management and internal troubleshooting. I take no position here on whether that's a good idea, but I conclude that publishing such data in the DNS happens today, regardless of the availability of the EUI48 or EUI64 RRTypes. The new RRTypes have since been implemented in the code base of BIND9, NSD, Knot DNS and PowerDNS based on that specification. After some discussion in dnsext, directly with individual contributors and with Joel as Ops Area AD, the draft was revised. Text was added, including the general use case for storage of this data in the DNS mandated by the CRTC (requested by Joel). The intended status was changed to standards track, since I was told that made sense. After last-call discussions on this list the intended status was changed to informational, and more textual changes were made. The stated reason for publishing this draft in the RFC series (I'm stating it now!) is that the RFC series is the most obvious place for anybody to look for a specification about the implementation of these RRTypes. That's it. The above is what I understood. So, in summary: 1. There is, I would suggest, a stable specification. 2. Code points are assigned. 3. There are multiple implementations. 4. There are multiple use-cases, and multiple examples of these data types being published in the DNS today (note, I am not suggesting that widespread use is likely or sensible.) 5. It would be useful (I would assert) that the specification can actually be found by people in the future who care about it. In my mind, this suggests publication of the spec in the RFC series, where it can join other specifications for the encoding of IPv4, IPv6, NSAP, E.164, X.25, ISDN, ATM, NIMROD, HIP, and ILNP addresses. I may have missed some. There was once a case of a specification which had seven implementations and the publication path hit the IETF heavy tail. In the current case publication has been requested in the IETF Stream. There are some differences between the IETF Stream and other Streams (in my opinion). On a different thread and obviously in a different context John Klensin mentioned that: For example, if we agree on a relaxed registration procedure for some protocol parameters, it is not reasonable to later turn around and ask that that those parameters be standardized, unchanged, because they are already registered (and maybe deployed). For standardization, the IETF generally needs not only change control but an opportunity to comment on and affect the actual design and specification of whatever is being standardized. RFC 6895 was reviewed by the IETF community. RFC 6195 was reviewed by the IETF community. I won't claim that I did not read them or that I did not have the time to review and comment about the proposals. How does privacy fit into all this? Well, that's what the IAB has been talking about. The following objection was posted to the mailing list: - 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.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Joe == Joe Abley jab...@hopcount.ca writes: Okay, I felt a bit embarrassed about having said this, so I went back and reviewed the justification for bringing this forth as an IETF document. The stated reason for publishing the document as an IETF document is that there is a regulatory requirement in Canada to implement something like this. Joe No, that's not right (and really, if that's how you read the Joe document at hand then clearly I need to re-write it). Let's Joe review. Joe The original motivation for requesting code-point assignments Joe for new RRTypes which would facilitate a clean encoding of Joe EUI-48 and EUI-64 addresses in the DNS resulted from my Joe distaste for the evident lack of consistency in approach taken Joe in response to the CRTC's general requirement that cable Joe operators publish this kind of data in the DNS, for internal, Joe authenticated access by resellers of their access networks in Joe Canada. okay, fair enough. Given that the CRTC mandated them, why wasn't the IETF involved earlier? The regulator really should have reached out to the IETF here. I'll be the first to swear at my government for continuing to have ISO think here. This seems like a place for the IAB to respond to this regulator, and in this case, point towards your document and ask why there isn't someone from the regulator speaking for this. Joe It's not at all certain or even likely that the CRTC-mandated Joe systems will ever use these RRTypes. That ship has surely Joe sailed. The reason for requesting the code-points was to make Joe future such situations less messy, and more likely to result in Joe DNS schemas (if that's a phrase) that were consistent and Joe parseable. Then that's even more a reason for the IAB to send the CRTC a letter. Maybe it's time for a Canadian liason (but then every country will want one...?), or maybe it is time for a regulatory liason to be created... I dunno. Joe I've had feedback from a small number of people who are already Joe in the habit of publishing MAC addresses in the DNS as part of Joe (as I understand it) inventory management and internal Joe troubleshooting. I take no position here on whether that's a Joe good idea, but I conclude that publishing such data in the DNS Joe happens today, regardless of the availability of the EUI48 or Joe EUI64 RRTypes. Did they like the scheme? Joe In my mind, this suggests publication of the spec in the RFC Joe series, where it can join other specifications for the encoding Joe of IPv4, IPv6, NSAP, E.164, X.25, ISDN, ATM, NIMROD, HIP, and Joe ILNP addresses. I may have missed some. I agree. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpTwzShflCa9.pgp Description: PGP signature
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On Wed, May 29, 2013 at 08:44:08AM +0900, Randy Bush wrote: but i think the draft in question has very serious privacy issues, and would like to focus on that, not characterization of the messengers. The discussion in the security considerations of the -04 draft appears to me to acknowledge there are potential privacy issues, and suggests how to avoid them. What more would you ask? A -- Andrew Sullivan a...@anvilwalrusden.com
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Wednesday, May 29, 2013 12:25 -0400 Andrew Sullivan a...@anvilwalrusden.com wrote: On Wed, May 29, 2013 at 08:44:08AM +0900, Randy Bush wrote: but i think the draft in question has very serious privacy issues, and would like to focus on that, not characterization of the messengers. The discussion in the security considerations of the -04 draft appears to me to acknowledge there are potential privacy issues, and suggests how to avoid them. What more would you ask? At the risk of saying that differently and partially channeling Joe, would you care to propose specific text? The sentences added in -04 are partially mine. If I had been able to figure out what else to say that would be stronger, constructive, and not stray into Applicability Statement territory, I would have, so I'm out of ideas and it is possible that Joe is too. john
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On May 29, 2013, at 12:36 PM, John C Klensin john-i...@jck.com wrote: If I had been able to figure out what else to say that would be stronger, constructive, and not stray into Applicability Statement territory, I would have, so I'm out of ideas and it is possible that Joe is too. Even if you don't have an applicability statement, I don't think it's inappropriate to talk about the context in which the documented protocol is intended to be useful, nor to talk about contexts in which it wouldn't be appropriate. The document currently is far too restrained in this regard, IMHO. I would add some text to the introduction, like this: The DNS Resource Records described in this document have significant privacy implications (see section 8). They were developed with the intention to use them in [scenario a] or [scenario b] and are likely not to be appropriate in other scenarios. In particular, they are unlikely to be appropriate for use in DNS zones hosted on globally-reachable servers that will answer any query without any access control mechanism. I realize this looks a lot like an applicability statement, but the problem with putting an applicability statement in an Informational document is that informational documents are never applicable in the sense of being the standard the IETF recommends to use in a specific case. As long as you stay away from _recommending_ the use of this specification, I think it's okay to say where its use was envisioned. Although of course if it was envisioned to be used on the public internet, that wouldn't help.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Hi Ted, On 2013-05-29, at 9:54, Ted Lemon ted.le...@nominum.com wrote: On May 29, 2013, at 12:36 PM, John C Klensin john-i...@jck.com wrote: If I had been able to figure out what else to say that would be stronger, constructive, and not stray into Applicability Statement territory, I would have, so I'm out of ideas and it is possible that Joe is too. Even if you don't have an applicability statement, I don't think it's inappropriate to talk about the context in which the documented protocol is intended to be useful, nor to talk about contexts in which it wouldn't be appropriate. The document currently is far too restrained in this regard, IMHO. I would add some text to the introduction, like this: The DNS Resource Records described in this document have significant privacy implications (see section 8). They were developed with the intention to use them in [scenario a] or [scenario b] and are likely not to be appropriate in other scenarios. In particular, they are unlikely to be appropriate for use in DNS zones hosted on globally-reachable servers that will answer any query without any access control mechanism. I don't have an objection to adding text along those lines, and I understand your reasoning. Would this address the concerns of others who find the draft alarming? Joe
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Hi Ted, At 09:53 29-05-2013, Ted Lemon wrote: too restrained in this regard, IMHO. I would add some text to the introduction, like this: The DNS Resource Records described in this document have significant privacy implications (see section 8). They were developed with the intention to use them in [scenario a] or [scenario b] and are likely not to be appropriate in other scenarios. In particular, they are unlikely to be appropriate for use in DNS zones hosted on globally-reachable servers that will answer any query without any access control mechanism. Here's what I would be told: Scenario a and Scenario b do not have privacy implications as they have been reviewed by a respected organization in Canada. I would also be told that there is an Office of the Privacy Commissioner of Canada which is diligent [1]. I will also be told that all this has been reviewed diligently by highly respected people in the Internet Engineering Task Force. I still do not plan to raise any objection on the draft. Regards, -sm 1. Out of context quote: One issue being contended with by several data protection authorities was whether or not Media Access Control (MAC) addresses (manufacturer-assigned codes that allow devices to speak to one another), either alone or in combination with other information, constitute personal information. The OPC did not have to address this question since it found, as a matter of fact, clear examples of personal information collected among the payload data, including complete e-mails, user names and passwords, and even medical conditions of specified individuals. However, as in the case of IP addresses, the question of whether or not MAC addresses constitute personal information is highly contextual and must be considered in conjunction with what other information is also available to different users in different circumstances.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On May 29, 2013, at 5:51 PM, SM s...@resistor.net wrote: Here's what I would be told: Scenario a and Scenario b do not have privacy implications as they have been reviewed by a respected organization in Canada. I would also be told that there is an Office of the Privacy Commissioner of Canada which is diligent [1]. I will also be told that all this has been reviewed diligently by highly respected people in the Internet Engineering Task Force. I didn't say that I support the draft; just what I think could be done to somewhat mitigate its scope. My personal (non-hat) feeling about the draft is that if there is something good that will result from documenting these RRtypes, then the draft is worth doing, but if there is no good outcome other than we documented it, then the document shouldn't be published. I haven't been following the discussion closely enough to know what good outcome is anticipated as a result of publishing this document. I hope the responsible AD for this document will not count me as participating in the consensus on this document; it was not my intention in making the suggestion I made to indicate that I favor publishing the document. Based on the extent to which I _have_ followed the discussion, my position on the document could best be characterized as trepidatious semi-neutrality, leaning towards opposition.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On May 29, 2013, at 6:21 PM, Ted Lemon ted.le...@nominum.com wrote: I hope the responsible AD for this document will not count me as participating in the consensus on this document; it was not my intention in making the suggestion I made to indicate that I favor publishing the document. Based on the extent to which I _have_ followed the discussion, my position on the document could best be characterized as trepidatious semi-neutrality, leaning towards opposition. Okay, I felt a bit embarrassed about having said this, so I went back and reviewed the justification for bringing this forth as an IETF document. The stated reason for publishing the document as an IETF document is that there is a regulatory requirement in Canada to implement something like this. I think that's really thin, and I as an IETF participant, hat off, I oppose the publication of this document. I think Joe did the right thing in registering the RRtype, and I think Joe should by all means publish this on his personal web site so that people who need to implement this because of the weird requirements of various regulatory bodies can be satisfied in a clean way. However, I think putting this forward as an IETF consensus document, or as an IETF document at all, does convey the wrong message.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Hi Ted, On 2013-05-29, at 15:50, Ted Lemon ted.le...@nominum.com wrote: Okay, I felt a bit embarrassed about having said this, so I went back and reviewed the justification for bringing this forth as an IETF document. The stated reason for publishing the document as an IETF document is that there is a regulatory requirement in Canada to implement something like this. No, that's not right (and really, if that's how you read the document at hand then clearly I need to re-write it). Let's review. The original motivation for requesting code-point assignments for new RRTypes which would facilitate a clean encoding of EUI-48 and EUI-64 addresses in the DNS resulted from my distaste for the evident lack of consistency in approach taken in response to the CRTC's general requirement that cable operators publish this kind of data in the DNS, for internal, authenticated access by resellers of their access networks in Canada. It's not at all certain or even likely that the CRTC-mandated systems will ever use these RRTypes. That ship has surely sailed. The reason for requesting the code-points was to make future such situations less messy, and more likely to result in DNS schemas (if that's a phrase) that were consistent and parseable. Code-points were assigned following the documented process, which relies upon expert review. To support that review, I wrote a specification for their use as an I-D (intended status: experimental). Note that by specification I mean a technical description of the encoding and protocol considerations associated with EUI48 and EUI64, and not any kind of applicability statement or guidance for how the RRTypes should be used. I've had feedback from a small number of people who are already in the habit of publishing MAC addresses in the DNS as part of (as I understand it) inventory management and internal troubleshooting. I take no position here on whether that's a good idea, but I conclude that publishing such data in the DNS happens today, regardless of the availability of the EUI48 or EUI64 RRTypes. The new RRTypes have since been implemented in the code base of BIND9, NSD, Knot DNS and PowerDNS based on that specification. After some discussion in dnsext, directly with individual contributors and with Joel as Ops Area AD, the draft was revised. Text was added, including the general use case for storage of this data in the DNS mandated by the CRTC (requested by Joel). The intended status was changed to standards track, since I was told that made sense. After last-call discussions on this list the intended status was changed to informational, and more textual changes were made. The stated reason for publishing this draft in the RFC series (I'm stating it now!) is that the RFC series is the most obvious place for anybody to look for a specification about the implementation of these RRTypes. That's it. So, in summary: 1. There is, I would suggest, a stable specification. 2. Code points are assigned. 3. There are multiple implementations. 4. There are multiple use-cases, and multiple examples of these data types being published in the DNS today (note, I am not suggesting that widespread use is likely or sensible.) 5. It would be useful (I would assert) that the specification can actually be found by people in the future who care about it. In my mind, this suggests publication of the spec in the RFC series, where it can join other specifications for the encoding of IPv4, IPv6, NSAP, E.164, X.25, ISDN, ATM, NIMROD, HIP, and ILNP addresses. I may have missed some. Joe
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Tuesday, May 28, 2013 15:42 +0900 Randy Bush ra...@psg.com 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. 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. Hmm. I'm not happy with several aspects of the content of the draft, including the privacy issue. I'm also not happy with it as an apparent example of if one has a piece of information that needs to be accessible sometimes, put it in the DNS whether the characteristics of the DNS are a good match for the information and retrieval requirements or not. For those reasons, and because of the principles expressed in RFC2804, I believe it was completely unacceptable as a Standards Track document. Perhaps these RRTYPEs should never have been created and registered. If so, the balance between community review and maximizing the number of things that are registered (and the resulting avoidance of conflicts) is wrong for RRTYPEs. That would imply a need to revisit the registration policy, but it wouldn't change the status of these two RRTYPEs. But it seems to me that none of that is at issue at this stage. What is at issue, IMO, is whether the Internet is better off having a couple of RRTYPEs around with no documentation or having them documented. Put differently, are these RRTYPEs sufficiently reprehensible that we would hope to make them non-interoperable in practice by not telling people how to make them work. I believe that would be a bad plan and would violate principles far more basic than the 2804 ones -- the IETF should not be setting itself up as the arbiter of what can be deployed on the Internet if only because we would certainly fail. If people find these RRTYPEs (or the document) reprehensible, then let me suggest that they generate an I-D in Applicability Statement form that identifies them as Not Recommended and generally obscene and to do so and show sufficient consensus quickly enough to convince the IESG to force a normative reference to it into this document so they can be published together. I also don't see slide by as info in this. Like you, I opposed making this standards track and saw serious issues with 2804 in that context. Tuning aside, only two changes have been made to the document between -03 and -04 and both are intended to make it clear that the _description_ of these RRTYPEs does not constitute a recommendation to use them and that, if one has serious security concerns that outweigh other considerations, one should not use them (or put EUI-* information into the DNS in any other way). That makes the document about as close to being information about how these RRTYPEs work without recommending their use as I can figure out how to get it (others can probably do better, but apparently haven't stepped forward with text). It also contains a pretty strong caution about their use. I think that is appropriate too. It stops short of saying not recommended because the latter would imply standards track (and Joe might not agree). 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 ... In authorizing the publication of an Informational document that describes how something works for the information of the community, the IETF is not acting as an international standards body even though it is being consistent with its goal of making the Internet better by providing documentation that facilitates interoperability. The idea of providing registrations for non-standardized objects has the same goal. If we were willing to register only those objects that met our standards-track criteria, then we would encourage both code point squatting (seen in many other cases) or kludges that overload existing code points (as we have seen with TXT RRs) and damaging interoperability in both cases. I don't see the issues in simply documenting things as different and we certainly have a long tradition of encouraging the RFC Editor to publish that type of documentation. best, john
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
What is at issue, IMO, is whether the Internet is better off having a couple of RRTYPEs around with no documentation or having them documented. there are two solutions to this randy
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Tuesday, May 28, 2013 20:58 +0900 Randy Bush ra...@psg.com wrote: What is at issue, IMO, is whether the Internet is better off having a couple of RRTYPEs around with no documentation or having them documented. there are two solutions to this Probably more than two if your comment indicates that you agree that having registered RRTYPEs documented is, on balance, better than not having them documented: (1) We can continue along the path of Informational RFC publication in the IETF Stream (2) Joe could have submitted the document to the ISE and requested Informational RFC publication in the Independent stream. (3) Joe could post the definitional document on a web site somewhere that could provide a stable reference and then ask IANA to incorporate that reference, presumably in URL form, rather than the name of an I-D in the registry. If this is a Canadian initiative, perhaps the Canadian government would like to provide that location and reference but, clearly, there are other alternatives. Did you have something else in mind? I think the advantage of the first over the other two is that it promotes a level of review in the community that, a least IMO, had improved the document and, if we need revisit how RRTYPEs are allocated, to provide a concrete basis for that discussion. Once an RFC is published, the broader community is unlikely to be able to tell the difference between the first and second although, if we think the second would be better, it suggests another option for the longer term: (4) Create an IANA Stream for the RFC Editor through which we can publish documents that describe protocol parameters that are registered through lightweight methods and assure stable references for them, with no approval beyond that required to accomplish the registration. If such a stream retained the requirement to post as an I-D (and conformance to the IETF's IPR rules), there would still be as much or more opportunity for community pre-publication review and feedback to the author and expert reviewers than the independent stream affords. I have no idea whether that would be a good idea or not and it would certainly be too long-term to affect this document, but it is possible. Of course, (5), we could retroactively change the registration procedure and retroactively deprecate these types. That might avoid the need to write the Applicability Statement I-D that I mentioned but, if my reading of trends in the IESG is correct, I have my doubts. What, actually, would you propose other than continuing to complain about the RRTYPEs themselves and what they are intended to support (which, in case it hasn't been clear, I largely agree with you about). best, john
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
What is at issue, IMO, is whether the Internet is better off having a couple of RRTYPEs around with no documentation or having them documented. there are two solutions to this Probably more than two if your comment indicates that you agree that having registered RRTYPEs documented is, on balance, better than not having them documented: (1) We can continue along the path of Informational RFC publication in the IETF Stream (2) Joe could have submitted the document to the ISE and requested Informational RFC publication in the Independent stream. (3) Joe could post the definitional document on a web site somewhere that could provide a stable reference and then ask IANA to incorporate that reference, presumably in URL form, rather than the name of an I-D in the registry. If this is a Canadian initiative, perhaps the Canadian government would like to provide that location and reference but, clearly, there are other alternatives. Did you have something else in mind? remove the rrtypes from the registry
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 5/28/13 8:18 AM, Randy Bush wrote: What is at issue, IMO, is whether the Internet is better off having a couple of RRTYPEs around with no documentation or having them documented. there are two solutions to this Probably more than two if your comment indicates that you agree that having registered RRTYPEs documented is, on balance, better than not having them documented: (1) We can continue along the path of Informational RFC publication in the IETF Stream (2) Joe could have submitted the document to the ISE and requested Informational RFC publication in the Independent stream. (3) Joe could post the definitional document on a web site somewhere that could provide a stable reference and then ask IANA to incorporate that reference, presumably in URL form, rather than the name of an I-D in the registry. If this is a Canadian initiative, perhaps the Canadian government would like to provide that location and reference but, clearly, there are other alternatives. Did you have something else in mind? remove the rrtypes from the registry Unless you're proposing that we change the operation of the registry that seems a bit out of scope.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On Wed, May 29, 2013 at 12:18:40AM +0900, Randy Bush wrote: remove the rrtypes from the registry While it's good to see that the Internet Exemplary Taste-enForcers are alive and well, I would have an extremely strong objection to that approach. The DNS Extensions Working Group published an IANA Considerations document that was explicitly designed to permit registrations, and this is an example of that procedure working. If people had objections to that permissiveness, they didn't express them when the then-to-be-RFC6895 was last called. We have shipping implementations of DNS software that are using those code points. Removing the types from the registry does absolutely nothing for interoperation, doesn't actually help any of the privacy concerns that are being raised, doesn't solve anyone's problem, and sets up the registry as a crypto-normative repository -- a state of affairs that several people objected to when we tried to do this explicitly (I still bear the scars from that lashing). I am tired of the self-appointed Internet Cops attempting to regulate the taste of people wanting to use the DNS. If people don't like the allocation policy for DNS RRTYPEs, then they are free to spin up a new DNSTASTE WG and get the policy changed. I will attend the BoF and blow raspberries. But I look forward to the bright future in which the DNS contains only TXT records, which we retrieve via port 80 or (if lucky) port 443. A -- Andrew Sullivan a...@anvilwalrusden.com
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
remove the rrtypes from the registry While it's good to see that the Internet Exemplary Taste-enForcers are alive and well, I would have an extremely strong objection to that approach. jck was trying to enumerate alternatives. he omitted one. i am not a particular advocate of any of them, including the above. but i think the draft in question has very serious privacy issues, and would like to focus on that, not characterization of the messengers. randy
