Re: Last Call: <draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> (Resourc

> > > > > "Joe" == Joe Abley <jabley(_at_)hopcount(_dot_)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+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software Works

pgp6k3aTmdyRr.pgp
Description: PGP signature