--On Tuesday, May 28, 2013 15:42 +0900 Randy Bush <randy@xxxxxxx> wrote: >... >> While the RFC should not be materially misleading, I don't >> think there is a requirement for Informational RFCs to >> guarantee any particular level or security or privacy. > > that the draft now tries to slide by as info does not change > that it specified protocol elements and how they are to be > used. and the draft makes very clear that this is > juristiction specific and a serious privacy problem. Hmm. I'm not happy with several aspects of the content of the draft, including the privacy issue. I'm also not happy with it as an apparent example of "if one has a piece of information that needs to be accessible sometimes, put it in the DNS whether the characteristics of the DNS are a good match for the information and retrieval requirements or not". For those reasons, and because of the principles expressed in RFC2804, I believe it was completely unacceptable as a Standards Track document. Perhaps these RRTYPEs should never have been created and registered. If so, the balance between community review and maximizing the number of things that are registered (and the resulting avoidance of conflicts) is wrong for RRTYPEs. That would imply a need to revisit the registration policy, but it wouldn't change the status of these two RRTYPEs. But it seems to me that none of that is at issue at this stage. What is at issue, IMO, is whether the Internet is better off having a couple of RRTYPEs around with no documentation or having them documented. Put differently, are these RRTYPEs sufficiently reprehensible that we would hope to make them non-interoperable in practice by not telling people how to make them work. I believe that would be a bad plan and would violate principles far more basic than the 2804 ones -- the IETF should not be setting itself up as the arbiter of what can be deployed on the Internet if only because we would certainly fail. If people find these RRTYPEs (or the document) reprehensible, then let me suggest that they generate an I-D in Applicability Statement form that identifies them as "Not Recommended" and generally obscene and to do so and show sufficient consensus quickly enough to convince the IESG to force a normative reference to it into this document so they can be published together. I also don't see "slide by as info" in this. Like you, I opposed making this standards track and saw serious issues with 2804 in that context. Tuning aside, only two changes have been made to the document between -03 and -04 and both are intended to make it clear that the _description_ of these RRTYPEs does not constitute a recommendation to use them and that, if one has serious security concerns that outweigh other considerations, one should not use them (or put EUI-* information into the DNS in any other way). That makes the document about as close to being information about how these RRTYPEs work without recommending their use as I can figure out how to get it (others can probably do better, but apparently haven't stepped forward with text). It also contains a pretty strong caution about their use. I think that is appropriate too. It stops short of saying "not recommended" because the latter would imply standards track (and Joe might not agree). >> RFC 2804 is about > > i am very well aware what 2804 contains > >> RFC 2804 doesn't seem to me to be particularly applicable. > > i disagree. i believe the first two bullets in section one > are very applicable to joe's draft. > - The IETF, an international standards body, believes > itself to be the wrong forum for designing protocol or >... In authorizing the publication of an Informational document that describes how something works for the information of the community, the IETF is not acting as an "international standards body" even though it is being consistent with its goal of making the Internet better by providing documentation that facilitates interoperability. The idea of providing registrations for non-standardized objects has the same goal. If we were willing to register only those objects that met our standards-track criteria, then we would encourage both code point squatting (seen in many other cases) or kludges that overload existing code points (as we have seen with TXT RRs) and damaging interoperability in both cases. I don't see the issues in simply documenting things as different and we certainly have a long tradition of encouraging the RFC Editor to publish that type of documentation. best, john