[DNSOP] Re: Mohamed Boucadair's Discuss on draft-ietf-dnsop-rfc8624-bis-09: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Wes, 

Thanks for the follow-up. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Wes Hardaker <[e-mail]>
> Envoyé : mardi 20 mai 2025 22:42
> À : Mohamed Boucadair via Datatracker <[e-mail]>
> Cc : The IESG <[e-mail]>; BOUCADAIR Mohamed INNOV/NET
> <[e-mail]>; draft-ietf-dnsop-rfc8624-
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-dnsop-
> rfc8624-bis-09: (with DISCUSS and COMMENT)
> 
> 
> Mohamed Boucadair via Datatracker <[e-mail]> writes:
> 
> Thanks for the review Med...
> 
> Comments inline:
> 
> > ## Redundant with 8624?
> >
> > I spent some time to understand whether this is a bis or an
> update vs. 8624.
> > The diff at
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fa
> uth
> > or-tools.ietf.org%2Fdiff%3Fdoc_1%3Drfc8624%26doc_2%3Ddraft-ietf-
> dnsop-
> > rfc8624-
> bis&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce074b4c776
> >
> 8045ed6ba808dd97deca03%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> C63
> >
> 8833705327403983%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl
> YiO
> >
> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
> %7C
> >
> %7C%7C&sdata=k9IlEf9%2FHJU29Vni0i42NFM8VippikRQUffKKY9%2FMSw%3D&res
> erv
> > ed=0 shows several sections that are common (1.2, 5, 6) with some
> > minor tweaks.
> > There is also other text that is in 8624 but was moved around
> (e.g.,
> > 2nd and 3rd para of 1.1 or the 2nd para in 1.3).
> >
> > If this is an update, then we should explain why redundant text
> is
> > included/needed. Adding a clarification early in the document to
> > explain the intent would be sufficient, IMO. Ideally, I'd remove
> > redundant text (e.g., be replaced with references to the relevant
> sections in 8624).
> 
> So we [Warren and I] think you're right about the confusion and
> this is document actually obsoleting 8624 not updating it.  So
> we'll change the reference from "update" to "obsolete" accordingly.
> It is a complete replacement and 8624 shouldn't be used after this.
> 

[Med] This is cleaner. Thanks.

I think that some checks through the doc are needed to make sure internal consistent. For example,

(1) 

Do we need to touch these parts from the abstract to better align with the new approach: 

CURRENT:

   This
   document updates RFC8624 by moving the canonical source of algorithm
   implementation requirements and usage guidance for DNSSEC from
   RFC8624 to an IANA registry.

   The document does not change the status (MUST, MAY, RECOMMENDED,
   etc.) of the algorithms listed in RFC8624; that is the work of future
   documents.

(2) Check "A.12.  Changes since RFC8624"

Also, please add a sentence to the abstract to indicate explicitly that this doc obsoletes 8624.


> > ## Deprecated values
> >
> > ###
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> ww.
> > iana.org%2Fassignments%2Fdns-sec-alg-numbers%2Fdns-sec-alg-
> numbers.xml
> > %23dns-sec-alg-numbers-
> 1&data=05%7C02%7Cmohamed.boucadair%40orange.com
> >
> %7Ce074b4c7768045ed6ba808dd97deca03%7C90c7a20af34b40bfbc48b9253b6f5
> d20
> >
> %7C0%7C0%7C638833705327422816%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
> Gki
> >
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
> yfQ
> >
> %3D%3D%7C0%7C%7C%7C&sdata=X5XV7Q%2BzomfrGP8nyFMHxsReayftSfy%2B0Fkt%
> 2BW
> > 6O9gI%3D&reserved=0
> > has the following:
> >
> > 12      GOST R 34.10-2001 (DEPRECATED)  ECC-GOST        Y       *
> > [RFC5933][proposed standard][Change the status of GOST Signature
> > Algorithms in DNSSEC in the IETF stream to Historic]
> 
> 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.

[Med] Thanks for the background. The issue here is that 8624bis will be published with a table that does not reflect what do have now in IANA.

> 
> > CURRENT:
> >  |12|ECC-GOST       |MUST NOT   |MAY        |MUST NOT   |MAY
> |
> [...]
> > CURRENT:
> >    |1 |RSAMD5         |MUST NOT   |MUST NOT   |MUST NOT   |MUST
> NOT   |
> 
> You're right that the ECC-GOST algorithm was deprecated in the IANA
> table, but it was NOT reflected in 8624, which was the
> authoritative source for implementation guidance.  This breakage is
> exactly what we're trying to fix.  Future RFCs that deprecate
> algorithms can now directly modify the table, as republishing 8624
> was deemed to be a heavy lift fraught with discussions about every
> list algorithm every time.
> Problems solved!

[Med] :-)

> 
> > ## Modification policy
> >
> > The registration policy for the two registries is "RFC Required",
> > while the deprecated values were modified with a status-change in
> the
> > past. Should be update the policy to be consistent with the
> practice?
> 
> This was intentional and was discussed in the WG and is what we
> came to consensus on.  We (the WG) wanted to require RFC updates
> for any change to the requirements.
> 

[Med] I'm still missing something here. The registration policy for this registry is "RFC Required" since 2010 if my checks are correct. Although we have that policy, the registry was changed last year without an RFC. A simple fix here is to update the registration policy to also cover IESG Approval.

> > ## Instructions to fill new columns for some entries in the
> registry
> >
> > There are no instructions about which values to use of the
> following
> > entries in the registry
> 
> [...re: private values 252-254...]
> 
> This is a fair point, and we will change the document to put MAYs
> in thees columns for the two private algorithms.  Note that neither
> were in the original 8624 (and thus didn't have values to copy in).
> 
> The "reserved for indirect keys" row isn't a zone signing algorithm
> and thus not relevant to the new columns and shouldn't have a row.
> 

[Med] Thanks.

> > -----------------------------------------------------------------
> -----
> > COMMENT:
> > -----------------------------------------------------------------
> -----
> >
> > # Abstract
> >
> > CURRENT:
> >    The document does not change the status (MUST, MAY,
> RECOMMENDED, etc)
> >    of any of the algorithms listed in RFC8624; that is the work
> of
> >    future documents.
> >
> > * I would delete the last part of this sentence. No need to
> commit on
> > something that may or may not happen :-) * s/etc/etc.
> 
> I think it adds clarification to the purpose of the document and no
> one else mentioned it, so I'll leave it unless you have a very
> strong opinion about it and want further discussion.
> 

[Med] Your call :-)

> > # Section 1.3
> >
> > CURRENT:
> >    [RFC2119] considers the term SHOULD equivalent to RECOMMENDED,
> and
> >    SHOULD NOT equivalent to NOT RECOMMENDED.  The authors of this
> >    document have chosen to use the terms RECOMMENDED and NOT
> >    RECOMMENDED, as this more clearly expresses the
> recommendations to
> >    implementers.
> >
> > De we really need to say this? This is covered by 2119.
> 
> Yes, because we actually added that text directly because of reader
> confusion in the past.

[Med] ACK

> 
> > Also, the document when published will reflect the IETF
> consensus, not
> > authors preference.
> 
> Good point.  Changed to "This document has chosen..."

[Med] Thanks.

> 
> > # Section 2:
> >
> > ## Table 1 is redundant with Sections 7.1/7.2. I would delete and
> add
> > a point to these sections. Keep the content in one single place.
> 
> You're right that it is redundant, but is helpful to the reader in
> our opinion.

[Med] ACK

> 
> > ## Normative language for IANA considerations
> >
> > Section 2 contains many statements that usually fall under an
> IANA
> > considerations section. Example of such text is (but there are
> other
> > occurrences):
> 
> Yes, fair point...  most of the document is essentially an IANA
> updates document.
> Some of the text targets implementers/operators but the IANA
> considerations really is targeting just what IANA has to do.
> 

[Med] Maybe I missed it but I don't see this reflected in the new version. FWWI, refer also to https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ (Inappropriate Uses of Key Words)

> > CURRENT:
> >    "Implement for DNSSSEC Validation" columns SHALL follow the
> >    "Specification Required" policy as defined in [RFC8126] in
> order to
> >    promote continued evolution of DNSSEC algorithms and DNSSEC
> agility.
> >    New entries added through the "Specification Required" process
> will
> >    have the value of "MAY" for all columns.
> >
> > When such text is in an IANA cons section, the use of the
> normative
> > language
> > (SHALL) is avoided.
> 
> This is text targeting the reader (aka implementers and operators)
> though.

[Med] Hmm. I re-read and don't see how this is targeting users/implementers.

> 
> > # Section 3: Consider adding IANA notes
> >
> > Given that the registry will be authoritative and that this text
> is
> > important to interpret the table, I wonder whether we need to
> > transform some of the text into IANA sections. For example,
> >
> > CURRENT:
> >    When there are multiple RECOMMENDED algorithms in the "use"
> column,
> >    operators should choose the best algorithm according to local
> policy.
> 
> But that's not a recommendation to IANA.  That's (in the sentence
> itself) talking to operators.

[Med] ACK.

> 
> > # Section 4: [*] meaning
> >
> > CURRENT:
> >    |0     |NULL (CDS |MUST NOT   |MUST NOT   |MUST NOT  | MUST
> NOT    |
> >    |      |only)     |[*]        |[*]        |[*]       | [*]
> |
> >
> > Unless I missed, I don't see where we explain the meaning of [*].
> 
> Good catch!  Those were copied from 8624, but the footnote was
> dropped.
> We discussed this and are just going to remove the [*]'s rather
> than adding the footnote.
> 

[Med] :-)

> > # Section 6
> >
> > The wording in rfc8624  seems more accurate ("a new" instead of
> "the
> > key", for example).
> 
> Changed to something that should work:
> 
>    DS algorithm rollover in a live zone is also a complex process.
>    Upgrading algorithm at the same time as rolling to the new KSK
> key will
>    lead to DNSSEC validation failures, and users MUST upgrade the
> DS
>    algorithm first before rolling to a new Key Signing Key.
> 
> > As indicated above, my preference is to simply point the relevant
> > section in 8624.
> 
> As indicated above, this is a complete replacement (and now
> obsoletes 8624).

[Med] ACK

> 
> > ## Nits
> >
> > ## idnits is not happy with citations in the abstract
> >
> > CURRENT:
> >   revised IANA DNSSEC considerations from [RFC9157].
> 
> Changed the reference to straight text.
[Med] ACK

> 
> > ## Section 2: Many "register"
> >
> > OLD: registries registered with IANA
> >
> > NEW: registries maintained by IANA
> 
> Done!
[Med] Thanks.

> 
> Thanks for the comments.
> --
> 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.