Clarifications on CDS/CDNSKEY and CSYNC Consistency
draft-ietf-dnsop-cds-consistency-11

[Ballot comment]
Retaining my previous points here, since I think some text or an informative reference would be helpful, but the fact that they're understood and being considered in a related draft is enough to clear the DISCUSS. Thank you!

====

In Section 3.2, we see the following text:

> CSYNC-based updates may cause validation or even insecure resolution to break (e.g., by changing the delegation to a set of nameservers that do not serve required DNSKEY records or do not know the zone at all). Parental Agents SHOULD check that CSYNC-based updates, if applied, do not break the delegation.

Is there a definition of how the Parental Agent "check[s] that ... updates ... do not break the delegation"? I would have expected a more concrete instruction here, such as repeating the same queries on the proposed delegation targets and ensuring that they, too, return records consistent with what was found on the existing nameservers. Perhaps this already exists somewhere and a reference is sufficient?

From discussion, it appears that Section 2.2.1 of draft-ietf-dnsop-ds-automation addresses this in more detail. I think what we ultimately want is something like "SHOULD synthesize the new NS, DS, and other records which would be applied if the update were accepted, then verify the existence and valid signature of the DNSKEY record on each nameserver referenced by an NS record in the new set."

[Ballot discuss]
Thanks for the work on this draft. I have one DISCUSS point that I think will help improve the draft and is (hopefully) easily addressed.

In Section 3.2, we see the following text:

> CSYNC-based updates may cause validation or even insecure resolution to break (e.g., by changing the delegation to a set of nameservers that do not serve required DNSKEY records or do not know the zone at all). Parental Agents SHOULD check that CSYNC-based updates, if applied, do not break the delegation.

Is there a definition of how the Parental Agent "check[s] that ... updates ... do not break the delegation"? I would have expected a more concrete instruction here, such as repeating the same queries on the proposed delegation targets and ensuring that they, too, return records consistent with what was found on the existing nameservers. Perhaps this already exists somewhere and a reference is sufficient?

[Ballot comment]
TL;DR: this ballot as no comment, only thank you messages

# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-cds-consistency-09
CC @evyncke

Thank you for the work put into this document.

Special thanks to Ondřej Surý for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to David Blacka, the DNS directorate reviewer, and I have seen the author's reply:
https://datatracker.ietf.org/doc/review-ietf-dnsop-cds-consistency-09-dnsdir-lc-blacka-2025-10-23/

I hope that this review helps to improve the document,

Regards,

-éric

[Ballot discuss]
# Andy Newton, ART AD, comments for draft-ietf-dnsop-cds-consistency-09
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnsop-cds-consistency-09.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/,
a DISCUSS ballot is just a request to have a discussion on the following topics.

### BCP 14 Language

See the [IESG statement on BCP14 language](https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/).

Would these RECOMMENDS be better with explanations? Or if there is no further advice to give,
would making these non-normative be a good solution?

204        ..  A configurable retry schedule with
205        exponential back-off is RECOMMENDED (e.g., after 5, 10, 20, 40, ...
206        minutes). ...

218        ...  A
219        schedule with exponential back-off is RECOMMENDED.

In this case, what happens if queries are not continued? Is this a lowercase "may" or
should an explanation be provided about what happens if an implementation does not follow the advice.

225        in which case nothing needs to happen.  Queries MAY be continued
226        across all nameservers for reporting purposes.

In the paragraph below, "(reachable) nameservers" in a MUST sentence appears to be softening the
requirement to the level of RECOMMENDED. If there is a firm requirement that nameservers be reachable,
then that should be stated clearly. "(reachable)" is again used on lines 244, 268, and 283.

234        To retrieve a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust
235        maintenance, the Parental Agent, knowing both the Child zone name and
236        its NS hostnames, MUST ascertain that queries are made against all
237        (reachable) nameservers listed in the Child's delegation from the
238        Parent, and ensure that each key referenced in any of the received
239        answers is also referenced in all other received responses, or that
240        responses consistently indicate a request for removal of the entire
241        DS RRset ([RFC8078], Section 6).

I see that the paragraph at line 201 discusses reachability, but IMO it is still not clear
that an implementation MUST accomodate for it as consideration of reachability is a SHOULD:

201        When a response cannot be obtained from a given nameserver, the
202        Parental Agent SHOULD attempt to obtain it at a later time, before
203        concluding that the nameserver is permanently unreachable and
204        removing it from consideration.  ...

If reachability is implementation dependent, should that not be stated?

[Ballot comment]
## Comments

## Nits

### Network Vantage Point

Maybe this is minor, but "network vantage point" is more specificly descriptive.

206        ...  To sidestep localized routing issues, the Parental Agent
207        MAY also attempt contacting the nameserver from another vantage
208        point.

[Ballot comment]
I did not raise my comments to the level of DISCUSS, but it would be good to have a discussion
on these items. I do believe it is always better to insist on consistencies, hence not raising
these to discuss level.




      Readers are expected to be familiar with DNSSEC, including [RFC4033], [RFC4034], [RFC4035], [RFC7344], and [RFC7477],

Note the canonical reference for DNSSEC these days is RFC9364. As that draft states:

  One purpose is to introduce all of the RFCs in one place so that the reader can understand
  the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose
  is to state that using DNSSEC for origin authentication of DNS data is the best current practice.
  A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.

So that seems to exactly match the use here.


  During initial DS provisioning (DNSSEC bootstrapping), conventional DNSSEC validation for
  CDS/CDNSKEY responses is not (yet) available; in this case, authenticated bootstrapping ([RFC9615])
  should be used.

Or a regular EPP method can be used instead of trying to bootstrap through DNS.



  who may then inadvertently break the chain of trust by prematurely removing a DNSKEY still referenced
  by a (stale) CDS/CDNSKEY RRset.

I am confused here. How can one "prematurely" remove a DNSKEY that is referenced by a (stale)
CDS/CDNSKEY ?? I think you mean "accidentally" remove a newly introduced DNSKEY that is not
referenced by a (stale) CDS/CDNSKEY?


  In particular, the rogue nameserver can publish CDS/CDNSKEY records. If those are processed
  by the parent without ensuring consistency with other authoritative nameservers, the
  delegation will, with some patience, get secured with the attacker's DNSSEC keys.

Note as per RFC7344 this cannot happen. CDS/CDNSKEY records MUST validate before being processed,
or covered via an alternative method:

  The following acceptance rules are placed on the CDS and CDNSKEY
      resource records as follows:

  o  Location: MUST be at the Child zone apex.

  o  Signer: MUST be signed with a key that is represented in both the
      current DNSKEY and DS RRsets, unless the Parent uses the CDS or
      CDNSKEY RRset for initial enrollment; in that case, the Parent
      validates the CDS/CDNSKEY through some other means (see
      Section 6.1 and the Security Considerations).

RFC9516 updates this but also requires another signal in that case:
https://datatracker.ietf.org/doc/html/rfc9615#signaling

[Ballot comment]
Thanks for this document.

I appreciated the examples appendix. It might be helpful to note at the head of the appendix that this is indeed informative.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-cds-consistency-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-10-29):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-cds-consistency@ietf.org, mohamed.boucadair@orange.com, ondrej@sury.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Clarifications on CDS/CDNSKEY and CSYNC Consistency) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Clarifications on CDS/CDNSKEY
and CSYNC Consistency'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-10-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Maintenance of DNS delegations requires occasional changes of the DS
  and NS record sets on the parent side of the delegation.  For the
  case of DS records, "Automating DNSSEC Delegation Trust Maintenance"
  (RFC 7344) provides automation by allowing the child to publish CDS
  and/or CDNSKEY records holding the prospective DS parameters which
  the parent can ingest.  Similarly, "Child-to-Parent Synchronization
  in DNS" (RFC 7477) specifies CSYNC records to indicate a desired
  update of the delegation's NS (and glue) records.  Parent-side
  entities (e.g., Registries and Registrars) can query these records
  from the child and, after validation, use them to update the parent-
  side Resource Record Sets (RRsets) of the delegation.

  This document specifies that when performing such queries, parent-
  side entities has to ensure that updates triggered via CDS/CDNSKEY
  and CSYNC records are consistent across the child's authoritative
  nameservers, before taking any action based on these records.

  This document updates RFC 7344 and RFC 7477.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-cds-consistency/



No IPR declarations have been submitted directly on this I-D.

# # Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

6 people supported the draft in the WGLC with majority being silent. This is not a different from any other draft in the dnsop.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Not really. All the comments from the WG and from the DNS Directorate Early Review were properly addressed.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Reported in the document itself:

    This draft has been implemented by
    * TANGO Registry Services
    * CORE Registry

Also Oli Schafer reported on the WG mailing list: "We (Switch, ch./li.) implemented CDS consistency checking based on this draft in our CDS record scanner."

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This is an operational draft, it does not need any formal expert review criteria.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I believe so.  The document is of high quality.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Not Applicable.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard

Justification:
The draft updates behavior described in RFC 7477: Child-to-Parent Synchronization
in DNS, that is Proposed Standard, it is also generally stable, has resolved known
design choices, is believed to be well-understood, has received significant community
review, and appears to enjoy enough community interest to be considered valuable.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The authors have been reminded of the BCP 79 rules. There have been no IPR disclosure related to the document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I checked the current document and there are no remaining I-D nits I am aware of.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No, all references seem to be in order.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document has no IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# # Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

6 people supported the draft in the WGLC with majority being silent. This is not a different from any other draft in the dnsop.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Not really. All the comments from the WG and from the DNS Directorate Early Review were properly addressed.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Reported in the document itself:

    This draft has been implemented by
    * TANGO Registry Services
    * CORE Registry

Also Oli Schafer reported on the WG mailing list: "We (Switch, ch./li.) implemented CDS consistency checking based on this draft in our CDS record scanner."

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This is an operational draft, it does not need any formal expert review criteria.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I believe so.  The document is of high quality.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Not Applicable.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard

Justification:
The draft updates behavior described in RFC 7477: Child-to-Parent Synchronization
in DNS, that is Proposed Standard, it is also generally stable, has resolved known
design choices, is believed to be well-understood, has received significant community
review, and appears to enjoy enough community interest to be considered valuable.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The authors have been reminded of the BCP 79 rules. There have been no IPR disclosure related to the document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I checked the current document and there are no remaining I-D nits I am aware of.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No, all references seem to be in order.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

RFC7344


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document has no IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# # Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

6 people supported the draft in the WGLC with majority being silent. This is not a different from any other draft in the dnsop.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Not really. All the comments from the WG and from the DNS Directorate Early Review were properly addressed.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Reported in the document itself:

    This draft has been implemented by
    * TANGO Registry Services
    * CORE Registry

Also Oli Schafer reported on the WG mailing list: "We (Switch, ch./li.) implemented CDS consistency checking based on this draft in our CDS record scanner."

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This is an operational draft, it does not need any formal expert review criteria.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I believe so.  The document is of high quality.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Not Applicable.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The authors have been reminded of the BCP 79 rules. There have been no IPR disclosure related to the document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I checked the current document and there are no remaining I-D nits I am aware of.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No, all references seem to be in order.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document has no IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# # Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

6 people supported the draft in the WGLC with majority being silent. This is not a different from any other draft in the dnsop.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Not really. All the comments from the WG and from the DNS Directorate Early Review were properly addressed.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Reported in the document itself:

    This draft has been implemented by
    * TANGO Registry Services
    * CORE Registry

Also Oli Schafer reported on the WG mailing list: "We (Switch, ch./li.) implemented CDS consistency checking based on this draft in our CDS record scanner."

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This is an operational draft, it does not need any formal expert review criteria.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I believe so.  The document is of high quality.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Not Applicable.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The authors have been reminded of the BCP 79 rules. There have been no IPR disclosure related to the document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I checked the current document and there are no remaining I-D nits I am aware of.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No, all references seem to be in order.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document has no IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/