Hi Ted, On 2013-05-29, at 15:50, Ted Lemon <Ted.Lemon@xxxxxxxxxxx> 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