Jen, Thanks. Yes, I agree. In preparing this draft, we had a brief discussion about generalizing. It seemed to be easier to get this version into the system and, hopefully, approved. I would have hoped the general idea would have been accepted quickly and easily, but it wasn't the case. (I've been around since the beginning, so I've seen a lot of instances where things obvious to me have not been seen as obvious to everyone :)
I would have no objection if you want to make that suggestion. Steve On Tue, Nov 5, 2024 at 2:20 PM Jen Linkova <furr...@gmail.com> wrote: > On Wed, Nov 6, 2024 at 12:59 AM Steve Crocker <st...@shinkuro.com> wrote: > > Despite the reference to DNSSEC in the title, I think the life cycle > concepts apply to the use of algorithms in all settings. > > I'm wondering if you might want to make your draft more generic, and > explicitly expand it to all protocols/technologies. > > (funny enough, despite its title, draft-buraglio-deprecate7050 doesn't > really obsolete RFC7050, so 'deprecation' is not the right term). > > > On Tue, Nov 5, 2024 at 1:52 PM Jen Linkova <furr...@gmail.com> wrote: > >> > >> Hi Steve, > >> > >> On Tue, Nov 5, 2024 at 11:26 PM Steve Crocker <st...@shinkuro.com> > wrote: > >>> > >>> Documenting and Managing DNSSEC Algorithm Lifecycles > >>> draft-crocker-dnsop-dnssec-algorithm-lifecycle-01 > >> > >> > >>> > >>> I noted during the DNSOP session yesterday that two algorithms were > selected for deprecation. I believe the message below pertains to one of > them. As noted in the life cycle document, the process of downgrading the > use of an algorithm should go through three(!) phases. As described in the > I-D, a sequence of three actions is described: Phaseout, Deprecation, > Obsolescence. (Feel free to propose alternative words that are > grammatically parallel.). The text is quoted below. > >>> > >>> Questions for the DNSOP WG re moving an algorithm to "deprecate" > status: > >>> > >>> Does moving an algorithm to "deprecate" state exactly match any of the > actions listed in the lifecycle draft? If so, which one? If not, why not? > >> > >> > >> draft-buraglio-deprecate7050 has nothing to do with DNSSEC (well, one > of the problem of RFC7050 is that it's don't work with DNSSEC), so I'm not > sure the DNSSEC algorithms lifecycle terminology applies here. > >> > >> I agree that we might think about wording (e.g. call it "Discouraging" > instead of "Deprecation"). > >> > >> I believe that the Redhat incident scenario is not really applicable > here, as the draft only recommends that operators provide other methods > (non-DNS-based), and hosts using those methods when available. > >> > >>> > >>> ---------- Forwarded message --------- > >>> From: IETF Secretariat <ietf-secretariat-re...@ietf.org> > >>> Date: Mon, Nov 4, 2024 at 7:00 PM > >>> Subject: [DNSOP] The DNSOP WG has placed draft-buraglio-deprecate7050 > in state "Candidate for WG Adoption" > >>> To: <dnsop-cha...@ietf.org>, <dnsop@ietf.org>, < > draft-buraglio-deprecate7...@ietf.org> > >>> > >>> > >>> > >>> The DNSOP WG has placed draft-buraglio-deprecate7050 in state > >>> Candidate for WG Adoption (entered by Tim Wicinski) > >>> > >>> The document is available at > >>> https://datatracker.ietf.org/doc/draft-buraglio-deprecate7050/ > >>> > >>> > >>> _______________________________________________ > >>> DNSOP mailing list -- dnsop@ietf.org > >>> To unsubscribe send an email to dnsop-le...@ietf.org > >>> > >>> > >>> -- > >>> Sent by a Verified > >>> sender > >>> _______________________________________________ > >>> DNSOP mailing list -- dnsop@ietf.org > >>> To unsubscribe send an email to dnsop-le...@ietf.org > >> > >> > >> > >> -- > >> Cheers, Jen Linkova > > > > > > > > -- > > Sent by a Verified > > sender > > > > -- > Cheers, Jen Linkova > -- Sent by a Verified [image: Sent by a Verified sender] <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> sender
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
