--On Tuesday, May 21, 2013 10:04 -0400 Joe Abley <jabley@xxxxxxxxxxx> 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