In your letter dated Thu, 16 Jan 2025 11:40:22 -0500 (EST) you wrote: >> 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. > >I don't think that is often needed. For example, RFC 8080 only really >contains 4 lines of information that is available elsewhere.
It doesn't matter how long or short description is. It needs to connect the cryptographic algorithm to the encoding in DNS record types. If all is need is saying "just copy the bits to the right field" then that is fine. And add some test vectors. >I think only a document that is Standards Track is needed to change the >SHOULD or RECOMMENDED values as a group - eg talking about all the >available algorithms as a group and recommend. It should try to avoid >making those decisions on a case to case basis because these are often >happening too soon (eg when the draft is written without deployment >experience) and otherwise don't happen in the context of other >algorithms. I'm just saying, if an algorithm gets elevate to SHOULD or RECOMMENDED then the IETF part of the spec needs to be standards track. If doesn't matter if it is all in one RFC or in multiple RFCs. But not, somebody wrote a draft which expired and then somebody did something informational. And now we make it a SHOULD. If it is worth everybody's time to implement it then spend a bit of time on a standards track RFC. >Not if we cluster the recommendations of multple drafts/algorithms into >1 document that is bis'ed every couple of years. No problem. Then put the protocol parts in separate RFCs. Though I don't see why a bis RFC cannot have some extra text about algorithms that get elevated to SHOULD for the first time. >AFAIK, no. Only "early code points" assignments or RFCs can set those >fields. That's unfortunate. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
