Re: [Last-Call] Genart last call review of draft-ietf-dnsop-rfc5933-bis-10

[Макаренко Борис <[e-mail]>]

Hello, Roni!

The old algorithms GOST R 34.11-94, GOST R 34.10-2001 and GOST R 
34.11-2001 are considered obsolete. They are now replaced with GOST R 
34.10-2012 (digital signature) and GOST R 34.11-2012 (hash function). 
Basically, the use of GOST algorithms in DNSSEC remains the same as 
described in RFC 5933, but it is necessary to replace them with the new 
ones. Old algorithms should not be used anymore. That's why we need to 
obsolete RFC 5933.

The section "IANA Considerations" proposes to assign numbers for GOST R 
34.10-2012 and GOST R 34.11-2012 in the IANA registries "DNS Security 
Algorithm Numbers" 
(https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml) 
and "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" 
(https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml).

Updates for RFC 8624 are described in the corresponding Section.

--
Boris


13.10.2022 14:41, Roni Even via Datatracker writes:
> Reviewer: Roni Even Review result: Almost Ready  > > I am the assigned Gen-ART reviewer for this draft. The General 
Area > Review Team (Gen-ART) reviews all IETF documents being processed 
by > the IESG for the IETF Chair. Please treat these comments just like 
 > any other last call comments. > > For more information, please see 
the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > 
Document: draft-ietf-dnsop-rfc5933-bis-?? Reviewer: Roni Even Review > 
Date: 2022-10-13 IETF LC End Date: 2022-10-19 IESG Telechat date: Not > 
scheduled for a telechat > > Summary: the document is almost ready for 
publication as some type of > an RFC > > Major issues: The document is 
meant to be an informational RFC > obsoleting RFC5933 a standard track 
RFC. why is this change. > > Minor issues: > > the directive in the IANA 
consideration "The entry for Value 3, > GOST R 34.11-94 should be 
updated to have its Status changed to '-'" > is not clear. there is no 
status field in the table as I see in > RFC8624 section 3.3 > > 
Nits/editorial comments: > > > >