> From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> > > On 05/21/2013 10:04 AM, Joe Abley wrote: > > > With respect, *my* question as the author of this document is > > simply whether the specification provided is unambiguous and > > sufficient. It was my understanding that this was the question > > before the community in this last call. > > The criteria for Proposed Standard are quite a bit higher than that. > See RFC 2026 section 4.1.1. Coming into this from the outside, the issues are interesting. I originally thought RRTYPEs are scarce, since all the ones I was aware of are less than 256. But it turns out that RRTYPEs are 16 bit integers, and we've only consumed about 110 of them in ~25 years; we have about 15,000 years' supply of them. So they can be handed out rather generously. There actually is a standard for allocating RRTYPEs, which is RFC 6195 (section 3.1). RRTYPEs are to be handed out rather freely. OTOH, the standards for Proposed Standard are stricter. In regard to the question of whether to use one RRTYPE or two, it seems that the question is whether, in practice, it is common to want to query for both EUI-48 and EUI-64 for the same domain name at the same time. In regard to *how* to subtype a single RRTYPE, the resource records themselves contain a "DATA length" field (RDLENGTH, see RFC 1035 section 3.2.1), so if we used only one RRTYPE, the RDLENGTH field would differentiate EUI-48 from EUI-64. There are 768 RFCs that have INFORMATIONAL status and contain the word "MUST" -- and that is over 10% of the total number of RFCs published to date. So it looks like RFC 2119 terminology is commonly used in informational RFCs. Personally, it seems like a good idea. If you want to notify the world of a privately-developed protocol, you want to be able to say MUST and SHOULD; labeling it as INFORMATIONAL makes clear that the IETF hasn't endorsed the protocol. Dale