On Fri, Oct 21, 2022 at 2:54 PM, Warren Kumari <war...@kumari.net> wrote:
> On Wed, Oct 19, 2022 at 12:41 PM, Warren Kumari <war...@kumari.net> wrote: > >> On Wed, Oct 19, 2022 at 7:22 AM, Paul Hoffman <paul.hoff...@icann.org> >> wrote: >> >>> On Oct 18, 2022, at 7:58 AM, Ron Even <ron.even....@gmail.com> wrote: >>> >>> 1. whis is this an informational RFC and not a standard track RFC. >>> >>> That's a reasonable question with a simple answer: because the WG >>> changed its mind on what the status of this protocol should be. RFC 5933 >>> describes a national standard that is thinly deployed. At the time, it was >>> necessary to have the protocol on standards track; now it no longer is >>> required. >>> >>> 2. What is requested from IANA. ths text you wrote and I copied is not a >>> directive to IANA that is clear >>> >>> You are correct that the IANA Considerations section is quite unclear, >>> and needs to be clarified before the IESG considers it. >>> >> >> >> That is a good point. >> >> The document says: >> --- >> This document updates the RFC IANA registry "Delegation Signer >> (DS) Resource Record (RR) Type Digest Algorithms" by adding an entry for >> the GOST R 34.11-2012 algorithm: >> >> Value Algorithm >> TBA2 GOST R 34.11-2012 >> >> The entry for Value 3, GOST R 34.11-94 should be updated to have its >> Status changed to '-'. >> ---- >> >> The IANA registry being referenced "DNSSEC Delegation Signer (DS) >> Resource Record (RR) Type Digest Algorithms" is here: https://www.iana. >> org/assignments/ds-rr-types/ds-rr-types.xhtml >> >> Setting this to '-' does seem incorrect, and from the text I think that >> it should be either "MUST NOT" or, better yet (for clarity) "DEPRECATED" . >> >> In addition, the IANA has a question: >> ------ >> "Third, in the DNSSEC Delegation Signer (DS) Resource Record (RR) Type >> Digest Algorithms registry located at: >> >> https://www.iana.org/assignments/ds-rr-types/ >> >> a new registration will be made as follows: >> >> Value: [ TBD-at-Registration ] >> Description: GOST R 34.11-2012 >> Status: >> Reference: [ RFC-to-be ] >> >> IANA Question --> What should the entry for "Status" be for this new >> registration?" >> -------- >> >> >> >> >> I believe that it is clear (e.g: "6. Implementation Considerations >> The support of this cryptographic suite in DNSSEC-aware systems is >> OPTIONAL.") that it can only be OPTIONAL, but we need to clearly state >> that. >> >> So, I think a new version should be submitted saying: >> ---- >> This document updates the RFC IANA registry "Delegation Signer (DS) >> Resource Record (RR) Type Digest Algorithms" by adding an entry for >> the GOST R 34.11-2012 algorithm: >> >> Value: TBA2 >> Description: GOST R 34.11-2012 >> Status: OPTIONAL >> Reference: [ RFC-to-be ] >> >> The entry for Value 3, GOST R 34.11-94 should be updated to have its >> Status changed to 'DEPRECATED'. >> > > A new version was submitted (-11), but still says: > " The entry for Value 3, GOST R 34.11-94 should be updated to have its > Status changed to '-'." > > The registry is here: https://www.iana.org/assignments/ds-rr-types/ > ds-rr-types.xhtml > > '-' to me implies that the codepoint hasn't been used, but I don't > actually know if that's true. I think "DEPRECATED" is better, but perhaps > I'm wrong (anyone seeing '-' will presumably do read the referenced RFC, > so…_) > > I will ask the IANA which they think is best / clearest… > Closing the loop: I reached out to the IANA, and this was their reply: "Hi Warren, It makes sense to us to list "DEPRECATED" in the status column. When we're asked to deprecate a codepoint, the label "deprecated" is usually added to the registration in some way. "-" is a bit of a cipher, and doesn't indicate that there's been a change. thanks, Amanda " If the authors post a new version before the draft cut-off (Monday) with this addressed I should be able to move it along. Thank you all, W > W > > > >> W >> >> >>> --Paul Hoffman >>> >>
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
