> b) Is step 3b (a short RFC that points to a specific version of an > expired draft) acceptable? If not, what would be needed, given that > the original author didn't want to progress their document?
When it comes to using a cryptographic algorithm in DNSSEC there are two parts in the specification. The first is a general description of the cryptographic algorithm that applies to all contexts not just DNSSEC. The second is how the algorithm should be used in DNSSEC. Something about parameters and encoding of inputs and results. We can assume that cryptographic algorithms will be developed outside the IETF and that by the time we make such an algorithm a SHOULD or RECOMMENDED a stable reference will be avaliable. So the thing the IETF needs to add is the second part. So I think the requirement is obvious. If a cryptographic algorithm is to be listed as SHOULD or RECOMMENDED then a standard track specification of the second part is required. That means that if the code point was allocated based on a draft then a new draft that is intended for standards track needs to be created that copies the relevant material of the original draft. That provides a stable reference and gives room for review. It is very important to check that the new draft contains test vectors. Of course the new draft can immediately list the algorithm as SHOULD or RECOMMENDED. What I do not know, can a draft request IANA to update the reference for a previously allocated code point? _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
