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. 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."
The text I suggested was based on my reading of the above.
Regards,
-sm