Establishing Local DNS Authority in Validated Split-Horizon Environments
draft-ietf-add-split-horizon-authority-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-04-26
|
08 | Mohamed Boucadair | # Document Shepherd Write-Up for Group Documents (26/04/2024) ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a … # Document Shepherd Write-Up for Group Documents (26/04/2024) ## 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? [Med] The document succeeded to reach a broad agreement. The initial design was challenged but less concerns were raised during the second WGLC. See more below. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? [Med] The document went two WGLCs with the design radically changed between versions till -03 (1st WGLC) and the design in the document since -04. -03 used NS query to retrieve the set of nameservers that are authorized to serve a domain. A local resolver can get treatment if it can prove ownership of one of these NS names. This design is not flexible as it requires the set of authorized nameservers to be exactly the same as the set of advertised name servers for resolution. The use of NS was controversial and lengthy discussions happened on the list and during meeting. -04 went with a new design that leverages many existing pieces, mainly: * Rely upon a TXT record for validation a la draft-ietf-dnsop-domain-verification-techniques * Reuse the ZONEMD hash * Use local DNSSEC * Convey the list of claimed domains in a DHCP/PvD. * The claimed local domains within a zone are confidential, but the names * Identify explicitly the parent zone in the claim * Use "salt" for confidentiality See the Shepherd’s summary of the issues after the WGLC at: https://mailarchive.ietf.org/arch/msg/add/2dk7h5OkcllfpajHWTVyHfXvCV0/. These comments were adequately addressed by the authors (algo agility, etc.). Some concerns about the deployability of the -03 solution were raised against the early design (till -03). However, no such issues were raised during the last WGLC. Also, the OPSDIR review didn't identify such concern. Note that the Shepherd raised specifically the deployability comment with the reviewer (https://mailarchive.ietf.org/arch/msg/add/GCjCuNaC2ENFOEaDSxpEaAbn1tw/). There was a suggestion to share the claims using DNS itself instead of DHCP/PvD but that suggestion was not explored further. 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.) [Med] 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)? [Med] No. Please see https://mailarchive.ietf.org/arch/msg/add/mpC0eTnJuQCU30uqFkpdSiR5Ud4/ ## 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. [Med] Yes, DHC, DNSOP, and 6man. At least DHCWG was reached out by Shepherd for review: https://mailarchive.ietf.org/arch/msg/dhcwg/egOS8LSSCT9QBCyJgfo82exr3W0/. 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. [Med] N/A 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]? [Med] N/A 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. [Med] N/A ## 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? [Med] The Shepherd reviewed several versions of the spec and the authors kindly addressed the comments. The document is well-written and is ready to be handed to the AD. 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? [Med] Early reviews were already performed for this spec (secdir, opsdir, dnsdir, intdir). In addition, the Shepherd requested DHC WG review (https://mailarchive.ietf.org/arch/msg/dhcwg/egOS8LSSCT9QBCyJgfo82exr3W0/). The authors adequately addressed the DHC WG review. 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? [Med] This document requests publication as a Proposed Standard RFC. That fact is indicated on the header page. The intended status is justified given that the document specifies new objects (PvD, etc.) with a set of normative behavior to ensure interoperability. 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. [Med] Yes. The shepherd run the IPR poll and all authors replied to that poll: * Benjamin Schwartz: https://mailarchive.ietf.org/arch/msg/add/SJDQT6bei8tHJF_HIpFvkM9F1Pw/ * Kevin Smith: https://mailarchive.ietf.org/arch/msg/add/lGRvQoGbwBfwh7JJ4wcbrX3kCZ0/ * Dan Wing: https://mailarchive.ietf.org/arch/msg/add/7kxJ91WwiwKxi7wPv18HBsLVkfA/ * Tiru Reddy: https://mailarchive.ietf.org/arch/msg/add/1gAK8VoIokwCgRx6A58xGAP4qtw/ 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. [Med] Yes, as evidenced by the reply to the IPR poll for example. 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.) [Med] No. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. [Med] No. Note that previous versions of the document till -08 used to cite "IANA-SUDN" as normative, while it is better to reference RFC6761. This is now fixed in -09. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? [Med] No. 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. [Med] No. 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? [Med] No. 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. [Med] 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]). [Med] This document requests IANA to update existing registries: * Protocol Name Space Values * Additional Information PvD Keys * Underscored and Globally Scoped DNS Node Names Pointers to locate these registries and required information are provided. The requested assignments are consistently used in the document. Early versions of the document does not register the structure of the splitDnsClaims, while this is appropriate for future extensions of the object. This is now fixed in the latest version (-09); see also [18]. 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. [Med] The document requests IANA to create a new registry that requires Designated Expert Review. The authors updated the draft to include clear DE guidance per [18]. The authors are good candidates to service as DEs for this registry. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/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/ [18]: https://github.com/ietf-wg-add/draft-ietf-add-split-horizon-authority/issues/48 |
2024-04-26
|
08 | Mohamed Boucadair | # Document Shepherd Write-Up for Group Documents (26/04/2024) ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a … # Document Shepherd Write-Up for Group Documents (26/04/2024) ## 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? [Med] The document succeeded to reach a broad agreement. The initial design was challenged but less concerns were raised during the second WGLC. See more below. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? [Med] The document went two WGLCs with the design radically changed between versions till -03 (1st WGLC) and the design in the document since -04. -03 uses NS query to retrieve the set of nameservers that are authorized to serve a domain. A local resolver can get treatment if it can prove ownership of one of these NS names. This design is not flexible as it requires the set of authorized nameservers to be exactly the same as the set of advertised name servers for resolution. The use of NS was controversial and lengthy discussions happened on the list and during meeting. -04 went with a new design that leverages many existing pieces, mainly: * Rely upon a TXT record for validation a la draft-ietf-dnsop-domain-verification-techniques * Reuse the ZONEMD hash * Use local DNSSEC * Convey the list of claimed domains in a DHCP/PvD. * The claimed local domains within a zone are confidential, but the names * Identify explicitly the parent zone in the claim * Use "salt" for confidentiality See the Shepherd’s summary of the issues after the WGLC at: https://mailarchive.ietf.org/arch/msg/add/2dk7h5OkcllfpajHWTVyHfXvCV0/. These comments were adequately addressed by the authors (algo agility, etc.). Some concerns about the deployability of the -03 solution were raised against the early design (till -03). However, no such issues were raised during the last WGLC. Also, the OPSDIR review didn't identify such concern. Note that the Shepherd raised specifically the deployability comment with the reviewer (https://mailarchive.ietf.org/arch/msg/add/GCjCuNaC2ENFOEaDSxpEaAbn1tw/). There was a suggestion to share the claims using DNS itself instead of DHCP/PvD but that suggestion was not explored further. 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.) [Med] 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)? [Med] No. Please see https://mailarchive.ietf.org/arch/msg/add/mpC0eTnJuQCU30uqFkpdSiR5Ud4/ ## 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. [Med] Yes, DHC, DNSOP, and 6man. At least DHCWG was reached out by Shepherd for review: https://mailarchive.ietf.org/arch/msg/dhcwg/egOS8LSSCT9QBCyJgfo82exr3W0/. 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. [Med] N/A 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]? [Med] N/A 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. [Med] N/A ## 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? [Med] The Shepherd reviewed several versions of the spec and the authors kindly addressed the comments. The document is well-written and is ready to be handed to the AD. 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? [Med] Early reviews were already performed for this spec (secdir, opsdir, dnsdir, intdir). In addition, the Shepherd requested DHC WG review (https://mailarchive.ietf.org/arch/msg/dhcwg/egOS8LSSCT9QBCyJgfo82exr3W0/). The authors adequately addressed the DHC WG review. 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? [Med] This document requests publication as a Proposed Standard RFC. That fact is indicated on the header page. The intended status is justified given that the document specifies new objects (PvD, etc.) with a set of normative behavior to ensure interoperability. 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. [Med] Yes. The shepherd run the IPR poll and all authors replied to that poll: * Benjamin Schwartz: https://mailarchive.ietf.org/arch/msg/add/SJDQT6bei8tHJF_HIpFvkM9F1Pw/ * Kevin Smith: https://mailarchive.ietf.org/arch/msg/add/lGRvQoGbwBfwh7JJ4wcbrX3kCZ0/ * Dan Wing: https://mailarchive.ietf.org/arch/msg/add/7kxJ91WwiwKxi7wPv18HBsLVkfA/ * Tiru Reddy: https://mailarchive.ietf.org/arch/msg/add/1gAK8VoIokwCgRx6A58xGAP4qtw/ 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. [Med] Yes, as evidenced by the reply to the IPR poll for example. 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.) [Med] No. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. [Med] No. Note that previous versions of the document till -08 used to cite "IANA-SUDN" as normative, while it is better to reference RFC6761. This is now fixed in -09. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? [Med] No. 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. [Med] No. 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? [Med] No. 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. [Med] 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]). [Med] This document requests IANA to update existing registries: * Protocol Name Space Values * Additional Information PvD Keys * Underscored and Globally Scoped DNS Node Names Pointers to locate these registries and required information are provided. The requested assignments are consistently used in the document. Early versions of the document does not register the structure of the splitDnsClaims, while this is appropriate for future extensions of the object. This is now fixed in the latest version (-09); see also [18]. 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. [Med] The document requests IANA to create a new registry that requires Designated Expert Review. The authors updated the draft to include clear DE guidance per [18]. The authors are good candidates to service as DEs for this registry. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/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/ [18]: https://github.com/ietf-wg-add/draft-ietf-add-split-horizon-authority/issues/48 |
2024-04-25
|
08 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2024-04-25
|
08 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-04-25
|
08 | Tirumaleswar Reddy.K | New version available: draft-ietf-add-split-horizon-authority-08.txt |
2024-04-25
|
08 | (System) | New version approved |
2024-04-25
|
08 | (System) | Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Benjamin Schwartz , Dan Wing , Kevin Smith |
2024-04-25
|
08 | Tirumaleswar Reddy.K | Uploaded new revision |
2024-04-15
|
07 | Éric Vyncke | Waiting for a revised I-D addressing the secdir review. |
2024-04-15
|
07 | (System) | Changed action holders to Kevin Smith, Dan Wing, Éric Vyncke, Tirumaleswar Reddy.K, Benjamin Schwartz (IESG state changed) |
2024-04-15
|
07 | Éric Vyncke | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2024-04-09
|
07 | Mohamed Boucadair | # Document Shepherd Write-Up for Group Documents * review the mailing list related threads (issues/resolutions, etc.): https://mailarchive.ietf.org/arch/msg/add/2dk7h5OkcllfpajHWTVyHfXvCV0/. * writeup ## Document History 1. Does … # Document Shepherd Write-Up for Group Documents * review the mailing list related threads (issues/resolutions, etc.): https://mailarchive.ietf.org/arch/msg/add/2dk7h5OkcllfpajHWTVyHfXvCV0/. * writeup ## 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? 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? 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.) [Med] 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)? [Med] No. Please see https://mailarchive.ietf.org/arch/msg/add/mpC0eTnJuQCU30uqFkpdSiR5Ud4/ ## 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. [Med] Yes, DHC, DNSOP, and 6man. At least DHCWG was reached out by Shepherd for review: https://mailarchive.ietf.org/arch/msg/dhcwg/egOS8LSSCT9QBCyJgfo82exr3W0/. 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. [Med] N/A 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]? [Med] N/A 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. [Med] N/A ## 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? [Med] The document is almost ready to be handed to the AD. There are some WGLC comments to be addressed. The Sheperd reviewed thgis https://github.com/ietf-wg-add/draft-ietf-add-split-horizon-authority/issues/created_by/boucadair 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? [Med] Early reviews were already performed for this spec (secdir, opsdir, dnsdir, intdir). In addition, the Shepherd requested DHC WG review (https://mailarchive.ietf.org/arch/msg/dhcwg/egOS8LSSCT9QBCyJgfo82exr3W0/). The authors adequately addressed the DHC WG review. 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? [Med] This document requests publication as a Proposed Standard RFC. That is indicated on the header page. The intended status is justified given that the document specifies new objects (PvD, etc.) with a set of normative behavior to ensure interoperability. 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. [Med] Yes. The shepherd run the IPR poll and all authors replied to that poll: * Benjamin Schwartz: https://mailarchive.ietf.org/arch/msg/add/SJDQT6bei8tHJF_HIpFvkM9F1Pw/ * Kevin Smith: https://mailarchive.ietf.org/arch/msg/add/lGRvQoGbwBfwh7JJ4wcbrX3kCZ0/ * Dan Wing: https://mailarchive.ietf.org/arch/msg/add/7kxJ91WwiwKxi7wPv18HBsLVkfA/ * Tiru Reddy: https://mailarchive.ietf.org/arch/msg/add/1gAK8VoIokwCgRx6A58xGAP4qtw/ 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. [Med] Yes, as evidenced by the reply to the IPR poll for example. 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.) == Unused Reference: 'RFC9162' is defined on line 947, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. [Med] "IANA-SUDN" is currently listed as normative, while I think it is better to reference RFC6761. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? [Med] No. 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. [Med] No. 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? [Med] No. 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. [Med] 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]). [Med] This document requests IANA to update existing registries: * Protocol Name Space Values * Additional Information PvD Keys * Underscored and Globally Scoped DNS Node Names Pointers to locate these registries and required information are provided. The requested assignment are consistenly used in the document. However, the document does not register the structure of the splitDnsClaims, while this is appropriate for future extensions of the object. 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. [Med] No such registry is defined in the document. However, see the answer to 20. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/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/ |
2024-03-20
|
07 | Glenn Deen | # Document Shepherd Write-Up for Group Documents Log: * IPR Poll: https://mailarchive.ietf.org/arch/msg/add/zXvV705nxWAmHa3iuKT5x5RlnU8/ * Implementations check: https://mailarchive.ietf.org/arch/msg/add/mpC0eTnJuQCU30uqFkpdSiR5Ud4/ * review the mailing list related threads (issues/resolutions, etc.): … # Document Shepherd Write-Up for Group Documents Log: * IPR Poll: https://mailarchive.ietf.org/arch/msg/add/zXvV705nxWAmHa3iuKT5x5RlnU8/ * Implementations check: https://mailarchive.ietf.org/arch/msg/add/mpC0eTnJuQCU30uqFkpdSiR5Ud4/ * review the mailing list related threads (issues/resolutions, etc.): https://mailarchive.ietf.org/arch/msg/add/2dk7h5OkcllfpajHWTVyHfXvCV0/. * review request sent to DHC WG: https://mailarchive.ietf.org/arch/msg/dhcwg/egOS8LSSCT9QBCyJgfo82exr3W0/ * review the doc: see https://github.com/ietf-wg-add/draft-ietf-add-split-horizon-authority/issues/created_by/boucadair to do: * writeup ## 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? 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? 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.) 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)? ## 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. 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. 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]? 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. ## 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? 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? 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? 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. 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. 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.) 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? 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. 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? 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. 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]). 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. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/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/ |
2024-03-20
|
07 | Glenn Deen | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2024-03-20
|
07 | Glenn Deen | IESG state changed to Publication Requested from I-D Exists |
2024-03-20
|
07 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2024-03-20
|
07 | Glenn Deen | Responsible AD changed to Éric Vyncke |
2024-03-20
|
07 | Glenn Deen | Document is now in IESG state Publication Requested |
2024-03-20
|
07 | Glenn Deen | Changed consensus to Yes from Unknown |
2024-03-20
|
07 | Glenn Deen | Intended Status changed to Proposed Standard from None |
2023-12-06
|
07 | Tirumaleswar Reddy.K | New version available: draft-ietf-add-split-horizon-authority-07.txt |
2023-12-06
|
07 | Tirumaleswar Reddy.K | New version accepted (logged-in submitter: Tirumaleswar Reddy.K) |
2023-12-06
|
07 | Tirumaleswar Reddy.K | Uploaded new revision |
2023-11-29
|
06 | Bob Halley | Request for Last Call review by INTDIR Completed: Ready with Nits. Reviewer: Bob Halley. Sent review to list. |
2023-11-24
|
06 | Watson Ladd | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Watson Ladd. Sent review to list. |
2023-11-23
|
06 | Tianran Zhou | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tianran Zhou. Sent review to list. |
2023-11-17
|
06 | Anthony Somerset | Request for Last Call review by DNSDIR Completed: Ready. Reviewer: Anthony Somerset. Sent review to list. |
2023-11-16
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Watson Ladd |
2023-11-15
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tianran Zhou |
2023-11-10
|
06 | Jim Reid | Request for Last Call review by DNSDIR is assigned to Anthony Somerset |
2023-11-09
|
06 | Carlos Jesús Bernardos | Request for Last Call review by INTDIR is assigned to Bob Halley |
2023-11-09
|
06 | David Lawrence | Requested Last Call review by DNSDIR |
2023-11-09
|
06 | David Lawrence | Requested Last Call review by OPSDIR |
2023-11-09
|
06 | David Lawrence | Requested Last Call review by INTDIR |
2023-11-09
|
06 | David Lawrence | Requested Last Call review by SECDIR |
2023-11-04
|
06 | Glenn Deen | Added to session: IETF-118: add Wed-0830 |
2023-10-13
|
06 | Tirumaleswar Reddy.K | New version available: draft-ietf-add-split-horizon-authority-06.txt |
2023-10-13
|
06 | Tirumaleswar Reddy.K | New version accepted (logged-in submitter: Tirumaleswar Reddy.K) |
2023-10-13
|
06 | Tirumaleswar Reddy.K | Uploaded new revision |
2023-09-25
|
05 | Tirumaleswar Reddy.K | New version available: draft-ietf-add-split-horizon-authority-05.txt |
2023-09-25
|
05 | (System) | New version approved |
2023-09-25
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Benjamin Schwartz , Dan Wing , Kevin Smith |
2023-09-25
|
05 | Tirumaleswar Reddy.K | Uploaded new revision |
2023-09-15
|
04 | Mohamed Boucadair | # Document Shepherd Write-Up for Group Documents Log: * IPR Poll: https://mailarchive.ietf.org/arch/msg/add/zXvV705nxWAmHa3iuKT5x5RlnU8/ * Implementations check: https://mailarchive.ietf.org/arch/msg/add/mpC0eTnJuQCU30uqFkpdSiR5Ud4/ * review the mailing list related threads (issues/resolutions, etc.): … # Document Shepherd Write-Up for Group Documents Log: * IPR Poll: https://mailarchive.ietf.org/arch/msg/add/zXvV705nxWAmHa3iuKT5x5RlnU8/ * Implementations check: https://mailarchive.ietf.org/arch/msg/add/mpC0eTnJuQCU30uqFkpdSiR5Ud4/ * review the mailing list related threads (issues/resolutions, etc.): https://mailarchive.ietf.org/arch/msg/add/2dk7h5OkcllfpajHWTVyHfXvCV0/. * review request sent to DHC WG: https://mailarchive.ietf.org/arch/msg/dhcwg/egOS8LSSCT9QBCyJgfo82exr3W0/ * review the doc: see https://github.com/ietf-wg-add/draft-ietf-add-split-horizon-authority/issues/created_by/boucadair to do: * writeup ## 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? 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? 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.) 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)? ## 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. 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. 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]? 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. ## 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? 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? 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? 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. 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. 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.) 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? 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. 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? 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. 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]). 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. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/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/ |
2023-09-09
|
04 | (System) | Document has expired |
2023-09-04
|
04 | Mohamed Boucadair | # Document Shepherd Write-Up for Group Documents Log: * IPR Poll: https://mailarchive.ietf.org/arch/msg/add/zXvV705nxWAmHa3iuKT5x5RlnU8/ * Implementations check: https://mailarchive.ietf.org/arch/msg/add/mpC0eTnJuQCU30uqFkpdSiR5Ud4/ * review the mailing list related threads (issues/resolutions, etc.): … # Document Shepherd Write-Up for Group Documents Log: * IPR Poll: https://mailarchive.ietf.org/arch/msg/add/zXvV705nxWAmHa3iuKT5x5RlnU8/ * Implementations check: https://mailarchive.ietf.org/arch/msg/add/mpC0eTnJuQCU30uqFkpdSiR5Ud4/ * review the mailing list related threads (issues/resolutions, etc.): https://mailarchive.ietf.org/arch/msg/add/2dk7h5OkcllfpajHWTVyHfXvCV0/. A revision is needed. Also, Chairs need to request formal review from DHC WG. * review the doc: see https://github.com/ietf-wg-add/draft-ietf-add-split-horizon-authority/issues/created_by/boucadair to do: * writeup ## 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? 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? 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.) 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)? ## 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. 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. 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]? 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. ## 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? 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? 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? 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. 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. 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.) 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? 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. 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? 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. 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]). 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. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/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/ |
2023-07-13
|
04 | Glenn Deen | With apologies to the ADD working group,the chairs had announced that this document was going to be put in WGLC and MED had agreed to … With apologies to the ADD working group,the chairs had announced that this document was going to be put in WGLC and MED had agreed to be the Shepherd, but the actual action in datatracker did not get kicked off. This is correcting that oversight and the document is now properly in WGLC for 3 weeks ending on August 3rd 2023. Here's the prior notice of the intent to put it in WLGC: https://mailarchive.ietf.org/arch/msg/add/n3Xzu-tdihRi4cwoaCHoJZyP9s0/ |
2023-07-13
|
04 | Glenn Deen | IETF WG state changed to In WG Last Call from WG Document |
2023-03-15
|
04 | Mohamed Boucadair | # Document Shepherd Write-Up for Group Documents Log: * IPR Poll: https://mailarchive.ietf.org/arch/msg/add/zXvV705nxWAmHa3iuKT5x5RlnU8/ * Implementations check: https://mailarchive.ietf.org/arch/msg/add/mpC0eTnJuQCU30uqFkpdSiR5Ud4/ to do: * review the mailing list related threads … # Document Shepherd Write-Up for Group Documents Log: * IPR Poll: https://mailarchive.ietf.org/arch/msg/add/zXvV705nxWAmHa3iuKT5x5RlnU8/ * Implementations check: https://mailarchive.ietf.org/arch/msg/add/mpC0eTnJuQCU30uqFkpdSiR5Ud4/ to do: * review the mailing list related threads (issues/resolutions, etc.) * review the doc * writeup ## 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? 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? 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.) 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)? ## 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. 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. 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]? 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. ## 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? 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? 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? 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. 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. 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.) 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? 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. 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? 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. 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]). 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. [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://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/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/ |
2023-03-15
|
04 | Glenn Deen | Notification list changed to mohamed.boucadair@orange.com because the document shepherd was set |
2023-03-15
|
04 | Glenn Deen | Document shepherd changed to Mohamed Boucadair |
2023-03-15
|
04 | Glenn Deen | Added to session: IETF-116: add Thu-0730 |
2023-03-08
|
04 | Benjamin Schwartz | New version available: draft-ietf-add-split-horizon-authority-04.txt |
2023-03-08
|
04 | Benjamin Schwartz | New version accepted (logged-in submitter: Benjamin Schwartz) |
2023-03-08
|
04 | Benjamin Schwartz | Uploaded new revision |
2022-11-07
|
03 | Glenn Deen | Added to session: IETF-115: add Tue-1300 |
2022-11-06
|
03 | Tirumaleswar Reddy.K | New version available: draft-ietf-add-split-horizon-authority-03.txt |
2022-11-06
|
03 | Tirumaleswar Reddy.K | New version accepted (logged-in submitter: Tirumaleswar Reddy.K) |
2022-11-06
|
03 | Tirumaleswar Reddy.K | Uploaded new revision |
2022-09-20
|
02 | Tirumaleswar Reddy.K | New version available: draft-ietf-add-split-horizon-authority-02.txt |
2022-09-20
|
02 | Tirumaleswar Reddy.K | New version accepted (logged-in submitter: Tirumaleswar Reddy.K) |
2022-09-20
|
02 | Tirumaleswar Reddy.K | Uploaded new revision |
2022-08-22
|
01 | Dan Wing | New version available: draft-ietf-add-split-horizon-authority-01.txt |
2022-08-22
|
01 | Dan Wing | New version approved |
2022-08-22
|
01 | (System) | Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Benjamin Schwartz , Dan Wing , Kevin Smith |
2022-08-22
|
01 | Dan Wing | Uploaded new revision |
2022-07-20
|
00 | Glenn Deen | Added to session: IETF-114: add Tue-1500 |
2022-06-28
|
00 | Jenny Bui | This document now replaces draft-reddy-add-enterprise-split-dns instead of None |
2022-06-25
|
00 | Tirumaleswar Reddy.K | New version available: draft-ietf-add-split-horizon-authority-00.txt |
2022-06-25
|
00 | Glenn Deen | WG -00 approved |
2022-06-24
|
00 | Tirumaleswar Reddy.K | Set submitter to "Tirumaleswar Reddy ", replaces to (none) and sent approval email to group chairs: add-chairs@ietf.org |
2022-06-24
|
00 | Tirumaleswar Reddy.K | Uploaded new revision |