Mohamed Boucadair via Datatracker <[email protected]> writes: > # Update > > CURRENT: > Updates: 5933 (if approved)
Removed the updates. Though others may want me to remove the removal. We'll see :-) > The update to 5933 is not needed here given that the registry already tags 12 > as deprecated. > > # Why a separate document? > > It is tempting to ask why this is not handled as part of > draft-ietf-dnsop-rfc8624, though. I think you likely already saw my other responses on this subject. But I'll quote myself again here: So this is where the confusion really comes in and one of the reasons we wanted to change how this is done. In the past there were two sources of information that specified where you should look for current status of a given algorithm: 1. the IANA tables (which you note deprecates GOST R 34.10-2001). 2. RFC8624 (which talks about implementation requirements and has GOST R 34.10-2001 still listed as MAY) Thus, the WG decided to: 1. Update 8624 so it no longer contained the implementation guidance and moved the requirements into the IANA table itself, to address this very source of confusion. To ensure that 8624bis would get through without diving into a debate about particular algorithms, the WG concluded that 8624bis should not change any values at all from 8624 and should just be about switching how things were done. 2. Issue future documents about changing the values could then be created to actually make value changes once the IANA registry update was complete. The first two documents doing so are the must-not-gost and must-not-sha1 documents. These were intentionally written as separate documents for two reasons: A) because we didn't know if the WG would actually want to change those values (IE, it was an independent discussion) and B) to test the process of the new 862bis procedures. Technically, the documents could be combined but the history is much cleaner as 3 separate documents. In our humble opinion, of course, and is what the consensus was as well. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
