>>>>> "Joe" == Joe Abley <jabley@xxxxxxxxxxx> 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+IETF@xxxxxxxxxxxx>, Sandelman Software Works
Attachment:
pgpvp9OpKASgG.pgp
Description: PGP signature