Dear colleagues, On Wed, Mar 17, 2010 at 04:10:58PM -0700, Paul Hoffman wrote: > > It is *fine* to have an RFC specify which algorithms must be > implemented / supported / whatever for compliance to the RFC; we do > that now just fine. When the community agrees on changes to what is > needed to comply with an RFC, you update the RFC; we now do that > just fine as well. > > Putting new words in an IANA registry will make things more > confusing, not less. I understand this objection, and I have some sympathy with it. At the same time, there is a serious problem with at least one registry that the draft aims to fix. I think that problem is worth taking on. The DNSSEC algorithm registry has no slot in it to indicate the support level appropriate to each algorithm. As we saw in recent debates, there is considerable feeling among IETF participants that some algorithms need to be supported by everybody, and some are likely only to be required in particular situations. Today, if you want to find out whether an algorithm is mandatory to implement, or optional to implement, you have to go and read through every RFC for every algorithm, as well as some other RFCs that don't actually specify an algorithm but instead specify the protocol. This is a trivial task for someone familiar with the ways of the IETF. For someone unfamiliar with those ways, it is a convoluted mess that is hard to navigate. Not every programmer is as diligent as we might like, and so if we put this sort of barrier in the way of proper implementation, what we'll get is lousy interoperability. So I think it is very important that registries have _some_ way of indicating which algorithms are needed by everyone, and which ones not. Moreover, it would be awfully nice if we captured somewhere, "This algorithm is still required, but it's on its way out," and, "That algorithm isn't required yet, but real soon now it will be." That way, when a developer of code is trying to decide what to do, there is a useful guide not only of what the state of affairs is today, but what it likely will be in six months, one year, &c. (I'm aware of the amusement likely to be caused by the idea that DNSEXT could actually plan what work will really be done in the next 6-12 months.) If we accept that broad outline, then we quickly drive towards something like the distinctions currently made in the draft under consideration. Now, there's no reason that this has to entail "conformance with a registry". The registry could surely have some way of noting what RFC set the level, thereby returning us to the state Paul is asking for (conformance with RFCs, not registries). Does anyone else think that the distinctions we're talking about are indeed worth indicating somehow in a registry? If so, I think the current draft is a good basis for that work, even if we determine that the current text is not quite what we want. Best regards, Andrew -- Andrew Sullivan ajs@xxxxxxxxxxxx Shinkuro, Inc. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf