On Jan 15, 2025, at 13:31, Wes Hardaker <wjh...@hardakers.net> wrote: > > Paul Hoffman <paul.hoff...@icann.org> writes: > >>> My goal here is to help developers, researchers, etc work on new >>> ideas without a lot of process. >> >> I don't mind process for getting beyond "MAY"; in fact, I think it's >> our responsibility to do the work in that process. > > Speaking with no hats at all (IE, entirely my own opinion): > > I'm firmly of the opinion that when we have the code space available we > should make process easy to get new algorithms in tables to ease initial > implementations, testing and early interoperability. Thus, I'd be fine > for various levels of the MAY settings in these tables. > > I'm even more firmly of the opinion, however, that for SHOULDs and MUSTs > we absolutely need general industry acceptance of an algorithm that > resources SHOULD be committed to. As such, IMHO, we must have an IETF > consensus backed RFC that documents cases where SHOULDs and MUSTs are > put into thees new columns. Anything else only amounts to confusion by > the industry as to what resources should be spent within DNS software > owners to ensure wide adoption of algorithms is possible and likely.
I agree with the sentiment, but want to be sure we're saying the thing about RFCs. Here is what I hope is a reasonable scenario: 1) Someone writes a draft-someone-newsig-dnssec-00 for how to use the NewSig algorithm (which is referenced in the draft as a external reference to a academic paper, national standard, or the like). That draft shows how to use NewSig in DNSKEYs, and includes examples. 2) They ask the designated experts for a code point in the DNSKEY space, and receive it, with the reference being draft-someone-newsig-dnssec-00. The entries are designated as "MAY". 3a) They progress draft-someone-newsig-dnssec somewhere in the IETF for standards track. It cannot be progressed CFRG or ISE because those bodies cannot create standards track RFCs. draft-someone-newsig-dnssec is published on standards track, and the table is updated to "RECOMMENDED". 3b) Time has passed and the original author of draft-someone-newsig-dnssec-00 no longer cares. Someone else starts draft-someoneelse-newsig-dnssec-00 that says little more than "draft-someone-newsig-dnssec-00 now is a recommended signature algorithm", and progresses that somewhere in the IETF for standards track. draft-someoneelse-newsig-dnssec is published on standards track, and the table is updated to "RECOMMENDED". Questions for Wes and others: a) Is step 1 and 2 sufficient for MAY? If not, what would be needed? 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? --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
