--On Tuesday, May 21, 2013 10:04 -0400 Joe Abley
<jabley(_at_)hopcount(_dot_)ca> wrote:
...
There has been very little review of the actual specification
in this thread to date.
RRType assignments are made based on expert review, not IETF
consensus, document published, or any other criteria. In this
case, the RRTypes have been assigned and are known to have
three independent implementations. I'm not sure how the
Internet benefits from not publishing a specification in a
sensible place (and the RFC series is surely the most sensible
place). *I* think it's a good idea for this specification to
be published as an RFC.
Joe, as the person with the dubious distinction of having
started this thread when the Last Call was announced, I'm not
questioning the desirability of good documentation of any
RRTYPE, nor do I doubt the fact that these were properly
assigned and are deployed. I also agree with you that questions
about the expert review process belong elsewhere (and I don't
know that I'd want to change it in any formal way).
Had you written this document as a "this is how it is -- this is
to tell the community about what is deployed" informational one
that described the RRTYPEs and asked that it be published as
Informational, I wouldn't have been likely to raise any
objections. Had the Security Considerations section or privacy
discussion described the risks, possibly explained how they
might be mitigated, but basically said "if those are a big
enough problem for you, don't use this facility", that wouldn't
have been a problem for me: I can't speak for Keith, but you
might have not heard from him either.
But the document has been Last Called as an Proposed Standard,
not that type of informational document. That, at least to me,
makes both discussions of your design decisions and the relevant
security and privacy mechanisms entirely appropriate because
Proposed Standard requires IETF consensus approval of the whole
package, quite independently of your ability to register a new
RRTYPE (or two or three). All I'm asking for is that, if you
want this as a Proposed Standard you carefully and convincingly
describe your design rationale. I want that both because it
seems generally appropriate in this case and because, if someone
comes along and wants to register the EUI64-with-embedding or
EUI-with-48-64-switch RRTYPEs and there is pushback because
EUI48 and EUI64 are already registered, I think it is important
that pushback be based on documented and well-reasoned design
choices, not an appeal to the supposed authority of the IETF.
You wrote a bit later:
Informational was my original plan; I was persuaded by Some
People that the standards track was more appropriate. As I
mentioned, my objective is simply to publish the specification.
It might be that no one could know before this discussion
started but, at least in retrospect, those Some People may have
steered you in the wrong direction if your goal and theirs was
to get something published without putting various design
decisions into the spotlight. To say what Keith may be saying
in different language, there is lots of stuff floating around
the Internet of which the IETF might not approve. Publishing
Informational RFCs containing descriptions of them so they can
be understood is still a good thing. If someone wants to follow
those RFCs with "considered harmful or at least disgusting"
commentary and try to get it published, that is a separate
issue. But asking for Proposed Standard is a rather different
matter because it requires an IETF consensus assertion that the
criteria of RFC 2026 have been satisfied.
If you don't think that level of scrutiny is appropriate for
this situation, ask that the document be pulled from Last Call,
review it to make it as descriptive and declarative as possible
rather than even implicitly normative (I'd have to reread, but I
think it is at least close on that criterion), and then resubmit
it as an individual or independent submission for Informational
publication.
I have no real idea where you get that impression. The goal of
this document is to document the use of RRTypes that have
already been assigned, to provide a more structured option for
encoding data that is already published in the DNS using
non-interoperable and clumsy encoding schemes. Nothing more.
Ok. That, to me, is a perfect recipe for an Informational
document. It may, separately, be a call for a much more
aggressive denunciation and deprecation of overloaded and
trickily-encoded TXT RRs than RFC 5507 provides, maybe as a BCP
rather than IAB-Informational but that is also a separate issue
and problem.
best,
john