Re-, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Wes Hardaker <[email protected]> > Envoyé : mercredi 21 mai 2025 00:40 > À : Mohamed Boucadair via Datatracker <[email protected]> > Cc : The IESG <[email protected]>; BOUCADAIR Mohamed INNOV/NET > <[email protected]>; draft-ietf-dnsop-must-not-ecc- > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-dnsop- > must-not-ecc-gost-04: (with COMMENT) > > > 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 :-) [Med] :-) BTW, any reason why we have this new normative reference in https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-must-not-ecc-gost-05: 6. Normative References ... [draft-ietf-dnsop-algorithm-update] W., K., "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", n.d., <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop- algorithm-update>. Maybe the intent was to cite rfc8624bis? > > > 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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
