Hi Andy, all, I trust the authors will engage soon.
Rather than repeating the exception/implication of not following a SHOULD for these items, the document factorizes that given that the same reasoning applies: CURRENT: The recommendations optimize interoperability and safety. In certain cases, local policy may take precedence, such as when a registry is subjected to national cryptographic policy requirements or performs out-of-band verification of DS changes with a human for high-stake domains. However, not following any requirements designated with the "SHOULD" key word will generally lead to undesirable effects of ambiguity and interoperability issues. When implementing these recommendations, operators have to carefully weigh whether any particular deviation is justified in their particular context. Cheers, Med > -----Message d'origine----- > De : Andy Newton via Datatracker <[email protected]> > Envoyé : mercredi 20 mai 2026 00:34 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; draft-ietf-dnsop-ds- > [email protected] > Objet : [DNSOP] Andy Newton's Discuss on draft-ietf-dnsop-ds- > automation-08: (with DISCUSS and COMMENT) > > > Andy Newton has entered the following ballot position for > draft-ietf-dnsop-ds-automation-08: Discuss > > When responding, please keep the subject line intact and reply to > all email addresses included in the To and CC lines. (Feel free to > cut this introductory paragraph, however.) > > ------------------------------------------------------------------ > DISCUSS: > ------------------------------------------------------------------ > > # Andy Newton, ART AD, comments for draft-ietf-dnsop-ds- > automation-08 > CC @anewton1998 > > ## Thanks to the Reviewer(s) > > Thanks to Jiankang Yao for the ARTART review. > > ## Thanks to the Authors > > Thanks to the authors for writing this document. I am aware this > topic has been > under discussion in both the IETF and SSAC. This document does a > good job > describing the best practice for DS automation in a multi-faceted > ecosystem > where values for this information can exist in many places under > many areas of > authority. > > ## Discuss > > ### BCP 14 Language > > Given Roman's ballot position, I think this document should be > reviewed for BCP > 14 language usage. There are many places where a SHOULD might be a > MUST, or > where a SHOULD might be a "should". > > I will go through some below. > > #### 5-15 Minutes > > 240 2. Parent-side entities (such as registries) SHOULD > reduce a DS > 241 record set's TTL to a value between 5-15 minutes > when a new set > 242 of records is published, and restore the normal TTL > value at a > 243 later occasion (but not before the previous DS > RRset's TTL has > 244 expired). > > Why isn't this a MUST? It is a SHOULD for both behaviors (the 5-15 > minute TTL) > and the restoration of the TTL. At the very least, it seems the > restoration of > the "normal" TTL value is a MUST. However, why isn't the 5-15 > minute value a > MUST? Otherwise an operator can set it to 5 years justified with > "because I > just wanted it that way". If the SHOULD is to remain, isn't there > a reasonable > upper boundary behavior such as not being greater than the normal > TTL value? > > Also, is "normal TTL value" the previous TTL value? If not, what > does that mean? > > #### Both CDNSKEY and CDS > > 246 3. DNS operators SHOULD publish both CDNSKEY and CDS > records, and > 247 follow best practice for the choice of hash digest > type > 248 [DS-IANA]. > > Section 4.2.3 does a good job of explaining why both CDNSKEY and > CDS are > needed, so it seems the justification here is a MUST. In other > words, if you > want to interoperate, the operator MUST do this otherwise there is > likely to be > a problem. > > #### 5.1 Recommendations > > 389 1. For certain DS updates (see analysis (Section 5.2)) > and for DS > 390 deactivation, relevant points of contact known to > the parent-side > 391 entity (registry or registrar) SHOULD be notified. > > 393 2. For error conditions, the child DNS operator and > the domain's > 394 technical contact (if applicable) SHOULD be > notified first. The > 395 registrant SHOULD NOT be notified unless the > problem persists for > 396 a prolonged amount of time (e.g., three days). > > 398 3. Child DNS operators SHOULD be notified of errors > using a report > 399 query [RFC9567] to the agent domain as described in > Section 4 of > 400 [RFC9859]. Notifications to humans (domain holder) > will be > 401 performed in accordance with the communication > preferences > 402 established with the parent-side entity. The same > condition > 403 SHOULD NOT be reported unnecessarily frequently to > the same > 404 recipient. > > 406 4. In the RRR model, registries performing DS > automation SHOULD > 407 inform the registrar of any DS record changes via > the EPP Change > 408 Poll Extension [RFC8590] or a similar channel. > > 410 5. The currently active DS configuration SHOULD be > made accessible > 411 to the registrant (or their designated party) > through the > 412 customer portal available for domain management. > The DS update > 413 history MAY be made available in the same way. > > These seem to be a mixture of policy recommendations and good > technical > practices. If reporting is not required for interoperation, these > should > probably all be lower case "should". > > If reporting is required for proper DS automation, then at least > some of this > is a MUST. > > #### DS update requests > > 659 2. DS update requests SHOULD be executed immediately > after > 660 verification of their authenticity, regardless of > whether they > 661 are received in-band or via an out-of-band channel. > > For proper DS automation, shouldn't this be a MUST? If not > immediately, then as > soon as possible. Or is it ok for an operator to wait 24 hours? > > #### SHOULD NOT initialize > > 675 5. In the RRR model, a registry SHOULD NOT > automatically initialize > 676 DS records when it is known that the registrar does > not provide a > 677 way for the domain holder to later disable DNSSEC. > If the > 678 registrar has declared that it performs automated > DS maintenance, > 679 the registry SHOULD publish the registrar's > [RFC9859] > 680 notification endpoint (if applicable) and refrain > from registry- > 681 side DS automation. > > Under what conditions are violating these SHOULD NOT/SHOULD > acceptable? > If there are conditions for doing so, the document should attempt > to describe > those conditions. Otherwise, aren't these MUST NOT and MUST? > > > ------------------------------------------------------------------ > ---- > COMMENT: > ------------------------------------------------------------------ > ---- > > ## Comments > > ### EPP Advertising > > 309 ... When using the Extensible > 310 Provisioning Protocol (EPP) [RFC5730], the domain > <info> command > 311 described in Section 2.1.1.2 of [RFC9803] is available > for > 312 advertising the server's TTL policy. > > The use of the word "advertising" makes me read this as > information being > provided to the public. However, EPP does not operate that way. I > think should > be reworded to say EPP can be used to make known to the registrar > the > acceptable values used by the registry. > > ### RDAP TTLs > > 410 5. The currently active DS configuration SHOULD be > made accessible > 411 to the registrant (or their designated party) > through the > 412 customer portal available for domain management. > The DS update > 413 history MAY be made available in the same way. > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-ttl- > extension%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C38f86 > 10f116847a50f5c08deb5f6d617%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C639148268934434443%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=cBG7uaXuM7mtwy%2BNKF%2F3zxSXHfGx8hOo > Ufcvlh5v%2F5I%3D&reserved=0 is also > a good way to make the currently active TTL values available to > the registrant > or their designated party. > > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] ____________________________________________________________________________________________________________ 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]
