Paul,

The motivation for documenting the life cycle is to make both implementers
and operators aware there are seven phases and there's a rationale for
defining this many phases.  Documents that give a snapshot of which
algorithms are currently recommended, not recommended, etc. don't provide
that perspective.

Regarding the decisions as to when a particular algorithm should be moved
from one phase to the next, I agree this is not a simple process.  The
crypto experts will provide guidance on when a new algorithm has passed
their analysis and testing and when an existing algorithm should be phased
out.  Those judgments cover two of the six transitions, A and D.  The other
transitions depend on deployment and use.  I didn't propose the specific
means for measuring those, but I did include a requirement for a designated
set of experts to make those judgments.  I would expect they will develop
procedures, tools and criteria to do this work.  And to your point in your
follow-up note that people pay more attention to RFCs than current values
in IANA registries, the decisions made by the designated experts at each
transition will indeed be documented in RFCs.  And likely publicized in
other venues.

Implementers, i.e. the folks in control of software crypto packages, will
make their own decisions, of course, but the intent here is to give them
clear guidance, with accompanying data, to make their decisions much
easier.  Similarly, operators, i.e. the folks in control of which
algorithms in the crypto packages are enabled or disabled in their
services, will also find the guidance helpful.

Thanks,

Steve


On Fri, Jan 30, 2026 at 11:17 AM Paul Hoffman <[email protected]>
wrote:

> Greetings. I didn't speak up earlier because my view of this document is
> somewhat negative. Even if we can get consensus on the names of the phases,
> it seems less likely that we will get consensus on when an algorithm
> changes between the latter phases. Without that, the document becomes
> meaningless. This WG has had a very hard time with such considerations in
> the past.
>
> If I'm wrong and there is consensus on this, the draft is possibly useful
> for readers who want to refer to an external authority to know when to stop
> supporting certain algorithms for DNSSEC. I personally don't want to
> support that model, but others here might.
>
> --Paul Hoffman
>
>

-- 
Sent by a Verified

sender
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to