(wearing no hats and perhaps less common sense) One thing I've not seen mentioned in this discussion on IETF standards track documents is Implementations and Interoperability. I am sure everyone will say "of course we won't take something to SHOULD or RECOMMENDED without implementations and interop testing" but I feel we should speak to that.
tim On Thu, Jan 16, 2025 at 2:46 PM Philip Homburg <pch-dnso...@u-1.phicoh.com> wrote: > 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 >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
