Steve Crocker <[email protected]> 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 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
