As an operator, I feel the implementers should have a strong say in this. They have business decisions based on what customers wish to have supported, and while they can guide customers, they need to think of the long tail. (I worked for a software company that supported Internet Explorer 6 into the 2010s, because of large contracts).
As a chair, the current draft appears to require seven RFCs for the lifecycle of an algorithm. I agree with Paul W that the WG should spend their time on other documents, but am happy to be proven wrong. I do believe the 8624bis authors and the WG are open to updating the values for the table https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml that seems like a starting point tim On Fri, Oct 4, 2024 at 10:40 PM Paul Wouters <p...@nohats.ca> wrote: > > > > > On Oct 4, 2024, at 15:28, Russ Housley <hous...@vigilsec.com> wrote: > > > > This document is related to draft-ietf-dnsop-rfc8624-bis. We ask the > DSNOP WG to adopt it. > > The document seems like a theoretical ideal of an algorithm life cycle. > There have been many kind of considerations in play that have determined > the algorithm and key sizes of algorithms. There have been good strong > discussions in many venues inside and outside IETF. I don’t think this > document would add any value to those discussions, such as those happening > recently on RFC8624bis or the sha1 deprecation documents. > > I would rather see the WG spend their time on other documents. > > Paul > _______________________________________________ > 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
