I have been assigned this draft as part of the secdir review process. I see no security issues with the draft that are really within the scope of a secdir review. I do have significant concerns I'd like to raise as last call comments. In general, I agree with most of the concerns raised about this draft. I believe that an applicability statement is the appropriate way to address what this draft is trying to do. If you're looking to make a process change how about writing a simple proposal for allowing IANA registries to reference applicability statements that describe protocols they cover. You might have a note like "For current status of the implementation requirements for these algorithms in dnssec, se RFC xyzzy." The applicability statement could say which registries it links to, and could remove the links of statements it obsoletes. I realize that's somewhat going down the path of including unnecessary information in a registry, but I think it is a reasonable compromise until/unless something broader like ISDs come along. Also, by all means try to put together an ISD-like proposal if you have the energy. I'm one of the people who thought that the last ISD proposal was not sufficiently specified and might run into fundamental problems, but thought there were some really good ideas there, so if you do go down that route I'd be happy to share some concerns while remaining constructive. Stunningly, given the concerns raised so far, I think I have some new ones. First, this draft attempts to establish operational requirements. The term operational requirements is not well defined. In the context of DNSsec, we can imagine what that might mean: zone operators need to use one of the mandatory algorithms to sign their zones in order to guarantee that others can validate it. Especially for Internet-wide protocols it is often appropriate to have best-current-practice recommendations for the operational deployment of those protocols. We have groups like gro and dnsop that develop such recommendations. For other protocols this makes no sense at all. In the past I've worked on VPN deployments for clients. Those clients chose algorithms that were right for their environments. IF within that environment they happened to choose a protocol that was not labeled as MANDATORY by an IANA registry, that's totally fine. Neither the IETF nor the IANA has a good reason to tell people what IPsec algorithms they need to use in their operational environment, nor even what algorithms must be enabled in a given configuration. If we try, we will be ignored. This draft conflates implementation requirements with operations requirements. In many cases we SHOULD NOT specify operations requirements. In other cases, there is no reason to be sure that the implementation and operations requirements will be the same. Others have pointed out the broken definition of mandatory. The definition at the top of 3.1 provides an escape and makes MANDATORY much like SHOULD. However the explanation for what it means for implementations and operations provides no such escape. There is a lack of alignment between the implementation requirement and operations requirement for obsolete: if I'm starting to phase something out, it is too early to say SHOULD NOT implement. This draft fails to adequately describe its relationship to RFC 2119. When should I use MUST? When should I use MANDATORY? Why do I need both? If you're going to introduce new terms, you need to clearly specify their applicability. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf