[DNSOP]Re: DNSOPFurther comment re algorithm life cycles

[Wes Hardaker <[e-mail]>]

Steve Crocker <[e-mail]> writes:

> Under the heading of saying what might be obvious but needs to said
> anyway, there should always be at least one mainstream (phase 4)
> algorithm in use.  When an algorithm is moved to phaseout (phase 5),
> there should already be one or more other mainstream algorithms in
> use.

Hi Steve, and apologies for the very late reply.

I think in general we're aligned with the goals of what the content of
the recommendations should generally look like within the new columns in
the table.  IE, there should be some sort of transition path from
initial use to deprecation.  A couple points:

1. In your first note you took issue with particular values in the
proposed table.  For this, I note that in our introduction we explicitly
stated "It [this document] does not change the status of any of the
algorithms listed in [RFC8624]; this is left to future documents."  IE,
our goal is to create the new columns in the IANA table and move the
existing values from RFC8624 into the registry.  THEN individual
documents may wish to propose new values for the various recommendation
columns.  One of the primary goals, in our opinion, is to separate out
the creation of the columns from the arguments associated with each
algorithm.  Specifically, we were worried that any time you have to
update the entire table at once there will be disagreement about
particular values for particular algorithms.  Thus, it might be far
easier to have discussions based on one algorithm at a time.

2. As to your above note, I think that's a valid point -- we should
never let the table get to the state where there is not a set of
appropriate MUSTs in order to get wide, stable deployment.  Whether we
should do that by adding a restriction in this document to tell IANA to
never let this happen in an update, or whether we do that as a follow on
BCP which outlines the steps you've been putting together for a while
remains for discussion I think.  I think either should likely suffice,
but I tend to lean toward a separate BCP or something since I don't
think adding overhead to the IANA processing rules is the right idea.

Cheers!

[PS, as a (1b) we note that we published proposed updates for the SHA1
and ECC-GOST algorithms to separate those discussions into different
threads, which appears to have been somewhat helpful as there may not
yet be a solid consensus about SHA1 though new values for the ECC-GOST
recommendations seems more agreed to]

-- 
Wes Hardaker
USC/ISI