On Fri, Oct 21, 2022 at 2:54 PM, Warren Kumari <warren@xxxxxxxxxx> wrote:
On Wed, Oct 19, 2022 at 12:41 PM, Warren Kumari <warren@kumari. > wrote:net On Wed, Oct 19, 2022 at 7:22 AM, Paul Hoffman <paul.hoffman@ > wrote:icann. org On Oct 18, 2022, at 7:58 AM, Ron Even <ron.
even. > wrote:tlv@ gmail. com 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 AlgorithmTBA2 GOST R 34.11-2012The 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:a new registration will be made as follows:Value: [ TBD-at-Registration ]Description: GOST R 34.11-2012Status: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 ConsiderationsThe support of this cryptographic suite in DNSSEC-aware systems isOPTIONAL.") 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 forthe GOST R 34.11-2012 algorithm:Value: TBA2Description: GOST R 34.11-2012Status: OPTIONALReference: [ RFC-to-be ]The entry for Value 3, GOST R 34.11-94 should be updated to have itsStatus 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 itsStatus 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
WW
--Paul Hoffman
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
