NETCONF Client and Server Models
draft-ietf-netconf-netconf-client-server-36
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-03-20
|
36 | Liz Flynn | Shepherding AD changed to Mahesh Jethanandani |
2024-03-16
|
36 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-36.txt |
2024-03-16
|
36 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2024-03-16
|
36 | Kent Watsen | Uploaded new revision |
2024-03-01
|
35 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-35.txt |
2024-03-01
|
35 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2024-03-01
|
35 | Kent Watsen | Uploaded new revision |
2024-02-22
|
34 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-34.txt |
2024-02-22
|
34 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2024-02-22
|
34 | Kent Watsen | Uploaded new revision |
2024-02-08
|
33 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-33.txt |
2024-02-08
|
33 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2024-02-08
|
33 | Kent Watsen | Uploaded new revision |
2024-02-04
|
32 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-32.txt |
2024-02-04
|
32 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2024-02-04
|
32 | Kent Watsen | Uploaded new revision |
2024-01-26
|
31 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-31.txt |
2024-01-26
|
31 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2024-01-26
|
31 | Kent Watsen | Uploaded new revision |
2023-12-28
|
30 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-30.txt |
2023-12-28
|
30 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2023-12-28
|
30 | Kent Watsen | Uploaded new revision |
2023-06-30
|
29 | (System) | Changed action holders to Robert Wilton (IESG state changed) |
2023-06-30
|
29 | Robert Wilton | IESG state changed to AD Evaluation from Publication Requested |
2023-04-17
|
29 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-29.txt |
2023-04-17
|
29 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2023-04-17
|
29 | Kent Watsen | Uploaded new revision |
2022-12-12
|
28 | Mahesh Jethanandani | # 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 … # 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? Shepherd: The document has only one author actively involved in the progression of the document. But this document has been progressed for more than 6 years and has been reviewed multiple times during their life time with 2 rounds of WGLC. That said, the shepherd thinks that this document has reached a broad agreement as this WG would be expected to reach. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Shepherd: There was no controversy about particular points, and the shepherd doesn't notice any decisions where the consensus was particularly rough. This document has received enough review in both WG meeting and on the NETCONF WG mailing list, the authors and shepherd believe that all the comments and questions from that review have be incorporated into the document. 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.) Shepherd: No one threatened an appeal or otherwise indicated extreme discontent. 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)? Shepherd: The shepherd knows from the mailing list that Ramkumar from Nokia declared they have implemented the "ietf-netconf-server" module for configuration of call home parameters (and here is a direct link to that: https://mailarchive.ietf.org/arch/msg/netconf/LhJ21qZXKOMa3KgeTcvO8sRfGso/). No other existing implementations have been publicly reported. But client-server suites of documents have always been urged to move forward and the shepherd notices that this document is referenced by RFC 8194(https://datatracker.ietf.org/doc/rfc8194/) that could use YANG modules defined in this document to configure NETCONF server channels, both of which are very likely to lead to implementation. ## 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. Shepherd: The shepherd doesn’t think the contents of this document closely interact with technologies in other IEF working groups or external organizations, and therefore the shepherd doesn’t believe this document needs review from other IETF working groups or external organizations. The shepherd doesn't see any public review from other IETF working groups or external organizations occurred before. 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. Shepherd: This document defines two YANG modules. It went through a YANG doctors last call review by Andy Bierman, and here is a direct link to that review: https://datatracker.ietf.org/doc/review-ietf-netconf-netconf-client-server-04-yangdoctors-lc-bierman-2017-07-28/ And here is the related discussion about the Yang doctor last call review on the NETCONF WG mailing list: https://mailarchive.ietf.org/arch/msg/netconf/LAOGs6u1AktzAHMmgTMMTMimZyc/ 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]? Shepherd: Yes, the document contains two YANG modules. Both have passed through `pyang` and `yanglint` validation. No errors or warnings have been flagged out. DataTracker’s YANG validator also reports 0 errors and 0 warnings. The shepherd has used the following command to check both YANG modules: $pyang --ietf ietf-netconf-client@2022-10-19.yang $yanglint ietf-netconf-client@2022-10-19.yang $pyang --ietf ietf-netconf-server@2022-10-19.yang $yanglint ietf-netconf-server@2022-10-19.yang The shepherd also tested the formatting using the command: $pyang -f yang --keep-comments --yang-line-length 69 ietf-netconf-client@2022-10-19.yang >test1.yang && diff ietf-netconf-client@2022-10-19.yang test1.yang The following results are returned which the shepherd thinks is innocuous: 211c205 < must client-identity { --- > must 'client-identity' { 307c301 < must client-identity { --- > must 'client-identity' { 445c438 < default 120; // two minutes --- > default "120"; // two minutes 547c540 < if-feature central-netconf-client-supported; --- > if-feature "central-netconf-client-supported"; $pyang -f yang --keep-comments --yang-line-length 69 ietf-netconf-server@2022-10-19.yang >test2.yang && diff ietf-netconf-server@2022-10-19.yang test2.yang The following results are returned which the shepherd thinks is innocuous: 661c653 < if-feature central-netconf-server-supported; --- > if-feature "central-netconf-server-supported"; Both of the YANG modules defined in this document comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342]. 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. Shepherd: The Shepherd has read the document, tested it against "idnits", and validated the syntactical correctness of both modules defined in the document using "pyang" and "yanglint", with neither returning any errors or warnings. The shepherd also checked the XML code in the document using "yanglint" without returning any errors or warnings. ## 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? Shepherd: Yes. Based on the shepherd's review of the document, it is the shepherd's 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? Shepherd: The shepherd took a look at https://trac.ietf.org/trac/iesg/wiki/ExpertTopics but didn't find any issues that related to this document. There is nothing that would merit specific attention from 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? Shepherd: The intended RFC status is proposed standard. This is an appropriate type of RFC for YANG models that will be implemented and must interoperate. And Datatracker state attributes correctly reflect this intent (here is the direct link: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/). 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][8]? 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. Shepherd: No IPR disclosure has been filed that applies to this document. The chair has requested an IPR call on the list as part of WGLC process. The author confirmed that he is unaware of any IPR related to this document. Thus there is no IPR needs to be disclosed. Here is the directed link to the IPR call request: https://mailarchive.ietf.org/arch/msg/netconf/mM9XVWiZ6srefgdaZYvMaQ4RB2U/ 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. Shepherd: There is only one author listed on the front page who has always been actively involved in progressing this work without any other editor and contributor. 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.) Shepherd: I-D nits has been tested against v-27 (here is the direct link: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netconf-netconf-client-server-27.txt), and it reports 0 error (**), 0 flaws (~~), 9 warnings (==), 0 comment (--), which the shepherd thinks are innocuous. Manual check of content guidelines reveals no issues. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. Shepherd: The shepherd has checked all the normative and informative references and thinks that all the references are correctly classified. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? Shepherd: All normative references are freely available to anyone. 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. Shepherd: There is no normative downward references. 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? Shepherd: This document has normative references to other client-server and security suites of documents(I-D.ietf-netconf-keystore, I-D.ietf-netconf-ssh-client-server, I-D.ietf-netconf-tcp-client-server, I-D.ietf-netconf-tls-client-server). It has been planned to submit the set of drafts to the IESG for publication as a cluster. 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. Shepherd: No, the publication of this document will not change the status of any existing RFCs. 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]). Shepherd: The shepherd has reviewed the IANA consideration section and checked its consistency with the body of the document. The shepherd confirmed that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries and any referenced IANA registries have been clearly identified. There is no newly created IANA registry in this document. 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. Shepherd: There is no new IANA registries, thus this document doesn’t require Designated Expert Review for future allocations. [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/ |
2022-12-12
|
28 | Mahesh Jethanandani | Responsible AD changed to Robert Wilton |
2022-12-12
|
28 | Mahesh Jethanandani | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2022-12-12
|
28 | Mahesh Jethanandani | IESG state changed to Publication Requested from I-D Exists |
2022-12-12
|
28 | Mahesh Jethanandani | Document is now in IESG state Publication Requested |
2022-12-12
|
28 | Mahesh Jethanandani | Notification list changed to maqiufang1@huawei.com, mjethanandani@gmail.com from maqiufang1@huawei.com |
2022-12-12
|
28 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-28.txt |
2022-12-12
|
28 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2022-12-12
|
28 | Kent Watsen | Uploaded new revision |
2022-10-20
|
27 | Qiufang Ma | # 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 … # 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? Shepherd: The document has only one author actively involved in the progression of the document. But this document has been progressed for more than 6 years and has been reviewed multiple times during their life time with 2 rounds of WGLC. That said, the shepherd thinks that this document has reached a broad agreement as this WG would be expected to reach. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Shepherd: There was no controversy about particular points, and the shepherd doesn't notice any decisions where the consensus was particularly rough. This document has received enough review in both WG meeting and on the NETCONF WG mailing list, the authors and shepherd believe that all the comments and questions from that review have be incorporated into the document. 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.) Shepherd: No one threatened an appeal or otherwise indicated extreme discontent. 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)? Shepherd: The shepherd knows from the mailing list that Ramkumar from Nokia declared they have implemented the "ietf-netconf-server" module for configuration of call home parameters (and here is a direct link to that: https://mailarchive.ietf.org/arch/msg/netconf/LhJ21qZXKOMa3KgeTcvO8sRfGso/). No other existing implementations have been publicly reported. But client-server suites of documents have always been urged to move forward and the shepherd notices that this document is referenced by RFC 8194(https://datatracker.ietf.org/doc/rfc8194/) that could use YANG modules defined in this document to configure NETCONF server channels, both of which are very likely to lead to implementation. ## 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. Shepherd: The shepherd doesn’t think the contents of this document closely interact with technologies in other IEF working groups or external organizations, and therefore the shepherd doesn’t believe this document needs review from other IETF working groups or external organizations. The shepherd doesn't see any public review from other IETF working groups or external organizations occurred before. 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. Shepherd: This document defines two YANG modules. It went through a YANG doctors last call review by Andy Bierman, and here is a direct link to that review: https://datatracker.ietf.org/doc/review-ietf-netconf-netconf-client-server-04-yangdoctors-lc-bierman-2017-07-28/ And here is the related discussion about the Yang doctor last call review on the NETCONF WG mailing list: https://mailarchive.ietf.org/arch/msg/netconf/LAOGs6u1AktzAHMmgTMMTMimZyc/ 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]? Shepherd: Yes, the document contains two YANG modules. Both have passed through `pyang` and `yanglint` validation. No errors or warnings have been flagged out. DataTracker’s YANG validator also reports 0 errors and 0 warnings. The shepherd has used the following command to check both YANG modules: $pyang --ietf ietf-netconf-client@2022-10-19.yang $yanglint ietf-netconf-client@2022-10-19.yang $pyang --ietf ietf-netconf-server@2022-10-19.yang $yanglint ietf-netconf-server@2022-10-19.yang The shepherd also tested the formatting using the command: $pyang -f yang --keep-comments --yang-line-length 69 ietf-netconf-client@2022-10-19.yang >test1.yang && diff ietf-netconf-client@2022-10-19.yang test1.yang The following results are returned which the shepherd thinks is innocuous: 211c205 < must client-identity { --- > must 'client-identity' { 307c301 < must client-identity { --- > must 'client-identity' { 445c438 < default 120; // two minutes --- > default "120"; // two minutes 547c540 < if-feature central-netconf-client-supported; --- > if-feature "central-netconf-client-supported"; $pyang -f yang --keep-comments --yang-line-length 69 ietf-netconf-server@2022-10-19.yang >test2.yang && diff ietf-netconf-server@2022-10-19.yang test2.yang The following results are returned which the shepherd thinks is innocuous: 661c653 < if-feature central-netconf-server-supported; --- > if-feature "central-netconf-server-supported"; Both of the YANG modules defined in this document comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342]. 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. Shepherd: The Shepherd has read the document, tested it against "idnits", and validated the syntactical correctness of both modules defined in the document using "pyang" and "yanglint", with neither returning any errors or warnings. The shepherd also checked the XML code in the document using "yanglint" without returning any errors or warnings. ## 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? Shepherd: Yes. Based on the shepherd's review of the document, it is the shepherd's 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? Shepherd: The shepherd took a look at https://trac.ietf.org/trac/iesg/wiki/ExpertTopics but didn't find any issues that related to this document. There is nothing that would merit specific attention from 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? Shepherd: The intended RFC status is proposed standard. This is an appropriate type of RFC for YANG models that will be implemented and must interoperate. And Datatracker state attributes correctly reflect this intent (here is the direct link: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/). 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][8]? 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. Shepherd: No IPR disclosure has been filed that applies to this document. The chair has requested an IPR call on the list as part of WGLC process. The author confirmed that he is unaware of any IPR related to this document. Thus there is no IPR needs to be disclosed. Here is the directed link to the IPR call request: https://mailarchive.ietf.org/arch/msg/netconf/mM9XVWiZ6srefgdaZYvMaQ4RB2U/ 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. Shepherd: There is only one author listed on the front page who has always been actively involved in progressing this work without any other editor and contributor. 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.) Shepherd: I-D nits has been tested against v-27 (here is the direct link: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netconf-netconf-client-server-27.txt), and it reports 0 error (**), 0 flaws (~~), 9 warnings (==), 0 comment (--), which the shepherd thinks are innocuous. Manual check of content guidelines reveals no issues. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. Shepherd: The shepherd has checked all the normative and informative references and thinks that all the references are correctly classified. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? Shepherd: All normative references are freely available to anyone. 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. Shepherd: There is no normative downward references. 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? Shepherd: This document has normative references to other client-server and security suites of documents(I-D.ietf-netconf-keystore, I-D.ietf-netconf-ssh-client-server, I-D.ietf-netconf-tcp-client-server, I-D.ietf-netconf-tls-client-server). It has been planned to submit the set of drafts to the IESG for publication as a cluster. 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. Shepherd: No, the publication of this document will not change the status of any existing RFCs. 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]). Shepherd: The shepherd has reviewed the IANA consideration section and checked its consistency with the body of the document. The shepherd confirmed that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries and any referenced IANA registries have been clearly identified. There is no newly created IANA registry in this document. 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. Shepherd: There is no new IANA registries, thus this document doesn’t require Designated Expert Review for future allocations. [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/ |
2022-10-20
|
27 | Qiufang Ma | # 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 … # 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? Shepherd: The document has only one author actively involved in the progression of the document. But this document has been progressed for more than 6 years and has been reviewed multiple times during their life time with 2 rounds of WGLC. That said, the shepherd thinks that this document has reached a broad agreement as this WG would be expected to reach. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Shepherd: There was no controversy about particular points, and the shepherd doesn't notice any decisions where the consensus was particularly rough. This document has received enough review in both WG meeting and on the NETCONF WG mailing list, the authors and shepherd believe that all the comments and questions from that review have be incorporated into the document. 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.) Shepherd: No one threatened an appeal or otherwise indicated extreme discontent. 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)? Shepherd: The shepherd knows from the mailing list that Ramkumar from Nokia declared they have implemented the "ietf-netconf-server" module for configuration of call home parameters (and here is a direct link to that: https://mailarchive.ietf.org/arch/msg/netconf/LhJ21qZXKOMa3KgeTcvO8sRfGso/). No other existing implementations have been publicly reported. But client-server suites of documents have always been urged to move forward and the shepherd notices that this document is referenced by RFC 8194(https://datatracker.ietf.org/doc/rfc8194/) that could use YANG modules defined in this document to configure NETCONF server channels, both of which are very likely to lead to implementation. ## 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. Shepherd: The shepherd doesn’t think the contents of this document closely interact with technologies in other IEF working groups or external organizations, and therefore the shepherd doesn’t believe this document needs review from other IETF working groups or external organizations. The shepherd doesn't see any public review from other IETF working groups or external organizations occurred before. 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. Shepherd: This document defines two YANG modules. It went through a YANG doctors last call review by Andy Bierman, and here is a direct link to that review: https://datatracker.ietf.org/doc/review-ietf-netconf-netconf-client-server-04-yangdoctors-lc-bierman-2017-07-28/ And here is the related discussion about the Yang doctor last call review on the NETCONF WG mailing list: https://mailarchive.ietf.org/arch/msg/netconf/LAOGs6u1AktzAHMmgTMMTMimZyc/ 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]? Shepherd: Yes, the document contains two YANG modules. Both have passed through `pyang` and `yanglint` validation. The shepherd has used the following command to check both YANG modules: $pyang --ietf ietf-netconf-client@2022-10-19.yang $yanglint ietf-netconf-client@2022-10-19.yang $pyang --ietf ietf-netconf-server@2022-10-19.yang $yanglint ietf-netconf-server@2022-10-19.yang The shepherd also tested the formatting using the command: $pyang -f yang --keep-comments --yang-line-length 69 ietf-netconf-client@2022-10-19.yang >test1.yang && diff ietf-netconf-client@2022-10-19.yang test1.yang The following results are returned which the shepherd thinks is innocuous: 211c205 < must client-identity { --- > must 'client-identity' { 307c301 < must client-identity { --- > must 'client-identity' { 445c438 < default 120; // two minutes --- > default "120"; // two minutes 547c540 < if-feature central-netconf-client-supported; --- > if-feature "central-netconf-client-supported"; $pyang -f yang --keep-comments --yang-line-length 69 ietf-netconf-server@2022-10-19.yang >test2.yang && diff ietf-netconf-server@2022-10-19.yang test2.yang The following results are returned which the shepherd thinks is innocuous: 661c653 < if-feature central-netconf-server-supported; --- > if-feature "central-netconf-server-supported"; Both of the YANG modules defined in this document comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342]. 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. Shepherd: The Shepherd has read the document, tested it against "idnits", and validated the syntactical correctness of both modules defined in the document using "pyang" and "yanglint", with neither returning any errors or warnings. The shepherd also checked the XML code in the document using "yanglint" without returning any errors or warnings. ## 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? Shepherd: Yes. Based on the shepherd's review of the document, it is the shepherd's 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? Shepherd: The shepherd took a look at https://trac.ietf.org/trac/iesg/wiki/ExpertTopics but didn't find any issues that related to this document. There is nothing that would merit specific attention from 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? Shepherd: The intended RFC status is proposed standard. This is an appropriate type of RFC for YANG models that will be implemented and must interoperate. And Datatracker state attributes correctly reflect this intent (here is the direct link: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/). 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][8]? 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. Shepherd: No IPR disclosure has been filed that applies to this document. The chair has requested an IPR call on the list as part of WGLC process. The author confirmed that he is unaware of any IPR related to this document. Thus there is no IPR needs to be disclosed. Here is the directed link to the IPR call request: https://mailarchive.ietf.org/arch/msg/netconf/mM9XVWiZ6srefgdaZYvMaQ4RB2U/ 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. Shepherd: There is only one author listed on the front page who has always been actively involved in progressing this work without any other editor and contributor. 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.) Shepherd: I-D nits has been tested against v-27 (here is the direct link: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netconf-netconf-client-server-27.txt), and it reports 0 error (**), 0 flaws (~~), 9 warnings (==), 0 comment (--), which the shepherd thinks are innocuous. Manual check of content guidelines reveals no issues. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. Shepherd: The shepherd has checked all the normative and informative references and thinks that all the references are correctly classified. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? Shepherd: All normative references are freely available to anyone. 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. Shepherd: There is no normative downward references. 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? Shepherd: This document has normative references to other client-server and security suites of documents(I-D.ietf-netconf-keystore, I-D.ietf-netconf-ssh-client-server, I-D.ietf-netconf-tcp-client-server, I-D.ietf-netconf-tls-client-server). It has been planned to submit the set of drafts to the IESG for publication as a cluster. 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. Shepherd: No, the publication of this document will not change the status of any existing RFCs. 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]). Shepherd: The shepherd has reviewed the IANA consideration section and checked its consistency with the body of the document. The shepherd confirmed that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries and any referenced IANA registries have been clearly identified. There is no newly created IANA registry in this document. 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. Shepherd: There is no new IANA registries, thus this document doesn’t require Designated Expert Review for future allocations. [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/ |
2022-10-19
|
27 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-27.txt |
2022-10-19
|
27 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2022-10-19
|
27 | Kent Watsen | Uploaded new revision |
2022-09-14
|
26 | Qiufang Ma | # 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 … # 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? Shepherd: The document has only one author with other WG members actively reviewing and commenting. This document has been progressed for more than 6 years and has been reviewed multiple times during their life time with 2 rounds of WGLC. That said, the shepherd thinks that this document has reached a broad agreement as this WG would be expected to reach. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Shepherd: There was no controversy about particular points, and the shepherd doesn't notice any decisions where the consensus was particularly rough. This document has received enough review in both WG meeting and on the NETCONF WG mailing list, the authors and shepherd believe that all the comments and questions from that review have be incorporated into the document. 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.) Shepherd: No one threatened an appeal or otherwise indicated extreme discontent. 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)? Shepherd: The shepherd knows from the mailing list that Ramkumar from Nokia declared they have implemented the "ietf-netconf-server" module for configuration of call home parameters (and here is a direct link to that: https://mailarchive.ietf.org/arch/msg/netconf/LhJ21qZXKOMa3KgeTcvO8sRfGso/). No other existing implementations have been publicly reported. But client-server suites of documents have always been urged to move forward and the shepherd notices that this document is referenced by RFC 8194(https://datatracker.ietf.org/doc/rfc8194/) that could use YANG modules defined in this document to configure NETCONF server channels, both of which are very likely to lead to implementation. ## 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. Shepherd: The shepherd doesn’t think the contents of this document closely interact with technologies in other IEF working groups or external organizations, and therefore the shepherd doesn’t believe this document needs review from other IETF working groups or external organizations. The shepherd doesn't see any public review from other IETF working groups or external organizations occurred before. 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. Shepherd: This document defines two YANG modules. It went through a YANG doctors last call review by Andy Bierman, and here is a direct link to that review: https://datatracker.ietf.org/doc/review-ietf-netconf-netconf-client-server-04-yangdoctors-lc-bierman-2017-07-28/ And here is the related discussion about the Yang doctor last call review on the NETCONF WG mailing list: https://mailarchive.ietf.org/arch/msg/netconf/LAOGs6u1AktzAHMmgTMMTMimZyc/ 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]? Shepherd: Yes, the document contains two YANG modules. Both have passed through `pyang` and `yanglint` validation, except one error reports that the revision date for "ietf-ssh-client/common/server" module is not found. The shepherd has already posted it to the WG and waits the author to submit another version. The shepherd has used the following command to check both YANG modules: $pyang --ietf ietf-netconf-client@2022-05-24.yang $yanglint ietf-netconf-client@2022-05-24.yang $pyang --ietf ietf-netconf-server@2022-05-24.yang $yanglint ietf-netconf-server@2022-05-24.yang The shepherd also tested the formatting using the command: $pyang -f yang --keep-comments --yang-line-length 69 ietf-netconf-client@2022-05-24.yang >test1.yang && diff ietf-netconf-client@2022-05-24.yang test1.yang The following results are returned which the shepherd thinks is innocuous: 211c205 < must client-identity { --- > must 'client-identity' { 307c301 < must client-identity { --- > must 'client-identity' { 445c438 < default 120; // two minutes --- > default "120"; // two minutes 547c540 < if-feature central-netconf-client-supported; --- > if-feature "central-netconf-client-supported"; $pyang -f yang --keep-comments --yang-line-length 69 ietf-netconf-server@2022-05-24.yang >test2.yang && diff ietf-netconf-server@2022-05-24.yang test2.yang The following results are returned which the shepherd thinks is innocuous: 661c653 < if-feature central-netconf-server-supported; --- > if-feature "central-netconf-server-supported"; Both of the YANG modules defined in this document comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342]. 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. Shepherd: The Shepherd has read the document, tested it against "idnits", and validated the syntactical correctness of both modules defined in the document using "pyang" and "yanglint", with neither returning any errors or warnings. The shepherd also checked the XML code in the document using "yanglint" without returning any errors or warnings. ## 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? Shepherd: Yes. Based on the shepherd's review of the document, it is the shepherd's 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? Shepherd: The shepherd took a look at https://trac.ietf.org/trac/iesg/wiki/ExpertTopics but didn't find any issues that related to this document. There is nothing that would merit specific attention from 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? Shepherd: The intended RFC status is proposed standard. This is an appropriate type of RFC for YANG models that will be implemented and must interoperate. And Datatracker state attributes correctly reflect this intent (here is the direct link: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/). 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][8]? 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. Shepherd: No IPR disclosure has been filed that applies to this document. The chair has requested an IPR call on the list as part of WGLC process. The author confirmed that he is unaware of any IPR related to this document. Thus there is no IPR needs to be disclosed. Here is the directed link to the IPR call request: https://mailarchive.ietf.org/arch/msg/netconf/mM9XVWiZ6srefgdaZYvMaQ4RB2U/ 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. Shepherd: There is only one author listed on the front page who has always been actively involved in progressing this work without any other editor and contributor. 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.) Shepherd: I-D nits has been tested against v-26 (here is the direct link: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netconf-netconf-client-server-26.txt), and it reports 0 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--), which are innocuous. Manual check of content guidelines reveals no issues. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. Shepherd: The shepherd has checked all the normative and informative references and thinks that all the references are correctly classified. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? Shepherd: All normative references are freely available to anyone. 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. Shepherd: There is no normative downward references. 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? Shepherd: This document has normative references to other client-server and security suites of documents(I-D.ietf-netconf-keystore, I-D.ietf-netconf-ssh-client-server, I-D.ietf-netconf-tcp-client-server, I-D.ietf-netconf-tls-client-server). It has been planned to submit the set of drafts to the IESG for publication as a cluster. 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. Shepherd: No, the publication of this document will not change the status of any existing RFCs. 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]). Shepherd: The shepherd has reviewed the IANA consideration section and checked its consistency with the body of the document. The shepherd confirmed that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries and any referenced IANA registries have been clearly identified. There is no newly created IANA registry in this document. 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. Shepherd: There is no new IANA registries, thus this document doesn’t require Designated Expert Review for future allocations. [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/ |
2022-09-14
|
26 | Qiufang Ma | # 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 … # 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? Shepherd: The document has only one author actively involved in the progression of the document. But this document has been progressed for more than 6 years and has been reviewed multiple times during their life time with 2 rounds of WGLC. That said, the shepherd thinks that this document has reached a broad agreement as this WG would be expected to reach. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Shepherd: There was no controversy about particular points, and the shepherd doesn't notice any decisions where the consensus was particularly rough. This document has received enough review in both WG meeting and on the NETCONF WG mailing list, the authors and shepherd believe that all the comments and questions from that review have be incorporated into the document. 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.) Shepherd: No one threatened an appeal or otherwise indicated extreme discontent. 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)? Shepherd: The shepherd knows from the mailing list that Ramkumar from Nokia declared they have implemented the "ietf-netconf-server" module for configuration of call home parameters (and here is a direct link to that: https://mailarchive.ietf.org/arch/msg/netconf/LhJ21qZXKOMa3KgeTcvO8sRfGso/). No other existing implementations have been publicly reported. But client-server suites of documents have always been urged to move forward and the shepherd notices that this document is referenced by RFC 8194(https://datatracker.ietf.org/doc/rfc8194/) that could use YANG modules defined in this document to configure NETCONF server channels, both of which are very likely to lead to implementation. ## 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. Shepherd: The shepherd doesn’t think the contents of this document closely interact with technologies in other IEF working groups or external organizations, and therefore the shepherd doesn’t believe this document needs review from other IETF working groups or external organizations. The shepherd doesn't see any public review from other IETF working groups or external organizations occurred before. 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. Shepherd: This document defines two YANG modules. It went through a YANG doctors last call review by Andy Bierman, and here is a direct link to that review: https://datatracker.ietf.org/doc/review-ietf-netconf-netconf-client-server-04-yangdoctors-lc-bierman-2017-07-28/ And here is the related discussion about the Yang doctor last call review on the NETCONF WG mailing list: https://mailarchive.ietf.org/arch/msg/netconf/LAOGs6u1AktzAHMmgTMMTMimZyc/ 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]? Shepherd: Yes, the document contains two YANG modules. Both have passed through `pyang` and `yanglint` validation, except one error reports that the revision date for "ietf-ssh-client/common/server" module is not found. The shepherd has already posted it to the WG and waits the author to submit another version. The shepherd has used the following command to check both YANG modules: $pyang --ietf ietf-netconf-client@2022-05-24.yang $yanglint ietf-netconf-client@2022-05-24.yang $pyang --ietf ietf-netconf-server@2022-05-24.yang $yanglint ietf-netconf-server@2022-05-24.yang The shepherd also tested the formatting using the command: $pyang -f yang --keep-comments --yang-line-length 69 ietf-netconf-client@2022-05-24.yang >test1.yang && diff ietf-netconf-client@2022-05-24.yang test1.yang The following results are returned which the shepherd thinks is innocuous: 211c205 < must client-identity { --- > must 'client-identity' { 307c301 < must client-identity { --- > must 'client-identity' { 445c438 < default 120; // two minutes --- > default "120"; // two minutes 547c540 < if-feature central-netconf-client-supported; --- > if-feature "central-netconf-client-supported"; $pyang -f yang --keep-comments --yang-line-length 69 ietf-netconf-server@2022-05-24.yang >test2.yang && diff ietf-netconf-server@2022-05-24.yang test2.yang The following results are returned which the shepherd thinks is innocuous: 661c653 < if-feature central-netconf-server-supported; --- > if-feature "central-netconf-server-supported"; Both of the YANG modules defined in this document comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342]. 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. Shepherd: The Shepherd has read the document, tested it against "idnits", and validated the syntactical correctness of both modules defined in the document using "pyang" and "yanglint", with neither returning any errors or warnings. The shepherd also checked the XML code in the document using "yanglint" without returning any errors or warnings. ## 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? Shepherd: Yes. Based on the shepherd's review of the document, it is the shepherd's 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? Shepherd: The shepherd took a look at https://trac.ietf.org/trac/iesg/wiki/ExpertTopics but didn't find any issues that related to this document. There is nothing that would merit specific attention from 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? Shepherd: The intended RFC status is proposed standard. This is an appropriate type of RFC for YANG models that will be implemented and must interoperate. And Datatracker state attributes correctly reflect this intent (here is the direct link: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/). 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][8]? 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. Shepherd: No IPR disclosure has been filed that applies to this document. The chair has requested an IPR call on the list as part of WGLC process. The author confirmed that he is unaware of any IPR related to this document. Thus there is no IPR needs to be disclosed. Here is the directed link to the IPR call request: https://mailarchive.ietf.org/arch/msg/netconf/mM9XVWiZ6srefgdaZYvMaQ4RB2U/ 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. Shepherd: There is only one author listed on the front page who has always been actively involved in progressing this work without any other editor and contributor. 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.) Shepherd: I-D nits has been tested against v-26 (here is the direct link: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netconf-netconf-client-server-26.txt), and it reports 0 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--), which are innocuous. Manual check of content guidelines reveals no issues. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. Shepherd: The shepherd has checked all the normative and informative references and thinks that all the references are correctly classified. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? Shepherd: All normative references are freely available to anyone. 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. Shepherd: There is no normative downward references. 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? Shepherd: This document has normative references to other client-server and security suites of documents(I-D.ietf-netconf-keystore, I-D.ietf-netconf-ssh-client-server, I-D.ietf-netconf-tcp-client-server, I-D.ietf-netconf-tls-client-server). It has been planned to submit the set of drafts to the IESG for publication as a cluster. 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. Shepherd: No, the publication of this document will not change the status of any existing RFCs. 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]). Shepherd: The shepherd has reviewed the IANA consideration section and checked its consistency with the body of the document. The shepherd confirmed that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries and any referenced IANA registries have been clearly identified. There is no newly created IANA registry in this document. 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. Shepherd: There is no new IANA registries, thus this document doesn’t require Designated Expert Review for future allocations. [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/ |
2022-08-30
|
26 | Mahesh Jethanandani | Notification list changed to maqiufang1@huawei.com because the document shepherd was set |
2022-08-30
|
26 | Mahesh Jethanandani | Document shepherd changed to Qiufang Ma |
2022-07-18
|
26 | Kent Watsen | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2022-05-24
|
26 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-26.txt |
2022-05-24
|
26 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2022-05-24
|
26 | Kent Watsen | Uploaded new revision |
2022-03-07
|
25 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-25.txt |
2022-03-07
|
25 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2022-03-07
|
25 | Kent Watsen | Uploaded new revision |
2021-12-17
|
24 | Kent Watsen | Changed consensus to Yes from Unknown |
2021-12-17
|
24 | Kent Watsen | Intended Status changed to Proposed Standard from None |
2021-12-14
|
24 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-24.txt |
2021-12-14
|
24 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2021-12-14
|
24 | Kent Watsen | Uploaded new revision |
2021-11-19
|
23 | (System) | Document has expired |
2021-08-25
|
23 | Mahesh Jethanandani | IETF WG state changed to In WG Last Call from WG Document |
2021-05-18
|
23 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-23.txt |
2021-05-18
|
23 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2021-05-18
|
23 | Kent Watsen | Uploaded new revision |
2021-02-10
|
22 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-22.txt |
2021-02-10
|
22 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2021-02-10
|
22 | Kent Watsen | Uploaded new revision |
2020-08-20
|
21 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-21.txt |
2020-08-20
|
21 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2020-08-20
|
21 | Kent Watsen | Uploaded new revision |
2020-07-20
|
20 | Kent Watsen | Added to session: IETF-108: netconf Tue-1100 |
2020-07-08
|
20 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-20.txt |
2020-07-08
|
20 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2020-07-08
|
20 | Kent Watsen | Uploaded new revision |
2020-05-20
|
19 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-19.txt |
2020-05-20
|
19 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2020-05-20
|
19 | Kent Watsen | Uploaded new revision |
2020-03-08
|
18 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-18.txt |
2020-03-08
|
18 | (System) | Ahlberg, et al. Expires May 10, 2019 [Page 15] Internet-Draft … Ahlberg, et al. Expires May 10, 2019 [Page 15] Internet-Draft Microwave YANG Model November 2018 or Automatic Transmit Power Control (ATPC)."; } leaf actual-transmitted-level { type power { range "-99..99"; } units "dBm"; config false; description "Actual transmitted power level (0.1 dBm resolution)."; reference "ETSI EN 301 129"; } leaf actual-received-level { type power { range "-99..-20"; } units "dBm"; config false; description "Actual received power level (0.1 dBm resolution)."; reference "ETSI EN 301 129"; } choice coding-modulation-mode { container single { description "A single modulation order only."; reference "ETSI EN 302 217-1"; leaf selected-cm { type identityref { base mw-types:coding-modulation; } mandatory true; description "Selected the single coding/modulation."; } } container adaptive { description "Adaptive coding/modulation."; reference "ETSI EN 302 217-1"; leaf selected-min-acm { type identityref { base mw-types:coding-modulation; } Ahlberg, et al. Expires May 10, 2019 [Page 16] Internet-Draft Microwave YANG Model November 2018 mandatory true; description "Selected minimum coding/modulation. Adaptive coding/modulation shall not go below this value."; } leaf selected-max-acm { type identityref { base mw-types:coding-modulation; } mandatory true; description "Selected maximum coding/modulation. Adaptive coding/modulation shall not go above this value."; } } mandatory true; description "A selection of single or adaptive coding/modulation mode."; } leaf actual-tx-cm { type identityref { base mw-types:coding-modulation; } config false; description "Actual coding/modulation in transmitting direction."; } leaf actual-snir { type decimal64 { fraction-digits 1; range "0..99"; } units "dB"; config false; description "Actual signal to noise plus interference ratio. (0.1 dB resolution)."; } leaf actual-xpi { if-feature xpic; type decimal64 { Ahlberg, et al. Expires May 10, 2019 [Page 17] Internet-Draft Microwave YANG Model November 2018 fraction-digits 1; range "0..99"; } units "dB"; config false; description "The actual carrier to cross-polar interference. Only valid if XPIC is enabled. (0.1 dB resolution)."; reference "ETSI TR 102 311"; } container ct-performance-thresholds { description "Specification of thresholds for when alarms should be sent and cleared for various performance counters."; leaf received-level-alarm-threshold { type power { range "-99..-20"; } units "dBm"; default "-99"; description "An alarm is sent when the received power level is below the specified threshold."; reference "ETSI EN 301 129"; } leaf transmitted-level-alarm-threshold { type power { range "-99..99"; } units "dBm"; default "-99"; description "An alarm is sent when the transmitted power level is below the specified threshold."; reference "ETSI EN 301 129"; } leaf ber-alarm-threshold { type enumeration { enum "1e-9" { description "Threshold at 1e-9 (10^-9)."; } enum "1e-8" { description "Threshold at 1e-8 (10^-8)."; } Ahlberg, et al. Expires May 10, 2019 [Page 18] Internet-Draft Microwave YANG Model November 2018 enum "1e-7" { description "Threshold at 1e-7 (10^-7)."; } enum "1e-6" { description "Threshold at 1e-6 (10^-6)."; } enum "1e-5" { description "Threshold at 1e-5 (10^-5)."; } enum "1e-4" { description "Threshold at 1e-4 (10^-4)."; } enum "1e-3" { description "Threshold at 1e-3 (10^-3)."; } enum "1e-2" { description "Threshold at 1e-2 (10^-2)."; } enum "1e-1" { description "Threshold at 1e-1 (10^-1)."; } } default "1e-6"; description "Specification of at which BER an alarm should be raised."; reference "ETSI EN 302 217-1"; } } leaf if-loop { type enumeration { enum disabled { description "Disables the IF Loop."; } enum client { description "Loops the signal back to the client side."; } enum radio { description "Loops the signal back to the radio side."; } } default "disabled"; description "Enable (client/radio) or disable (disabled) the IF loop, which loops the signal back to Ahlberg, et al. Expires May 10, 2019 [Page 19] Internet-Draft Microwave YANG Model November 2018 the client side or the radio side."; } leaf rf-loop { type enumeration { enum disabled { description "Disables the RF Loop."; } enum client { description "Loops the signal back to the client side."; } enum radio { description "Loops the signal back to the radio side."; } } default "disabled"; description "Enable (client/radio) or disable (disabled) the RF loop, which loops the signal back to the client side or the radio side."; } container capabilities { config false; description "Capabilities of the installed equipment and some selected configurations."; leaf min-tx-frequency { type uint32; units "kHz"; description "Minimum Tx frequency possible to use."; } leaf max-tx-frequency { type uint32; units "kHz"; description "Maximum Tx frequency possible to use."; } leaf min-rx-frequency { type uint32; units "kHz"; description Ahlberg, et al. Expires May 10, 2019 [Page 20] Internet-Draft Microwave YANG Model November 2018 "Minimum Rx frequency possible to use."; } leaf max-rx-frequency { type uint32; units "kHz"; description "Maximum Tx frequency possible to use."; } leaf minimum-power { type power; units "dBm"; description "The minimum output power supported."; reference "ETSI EN 302 217-1"; } leaf maximum-available-power { type power; units "dBm"; description "The maximum output power supported."; reference "ETSI EN 302 217-1"; } leaf available-min-acm { type identityref { base mw-types:coding-modulation; } description "Minimum coding-modulation possible to use."; } leaf available-max-acm { type identityref { base mw-types:coding-modulation; } description "Maximum coding-modulation possible to use."; } } container error-performance-statistics { config false; description "ITU-T G.826 error performance statistics relevant for a microwave/millimeter wave carrier."; Ahlberg, et al. Expires May 10, 2019 [Page 21] Internet-Draft Microwave YANG Model November 2018 leaf bbe { type yang:counter32; units "number of block errors"; description "Number of Background Block Errors (BBE). A BBE is an errored block not occurring as part of an SES. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of 'discontinuity-time' in ietf-interfaces."; reference "ITU-T G.826"; } leaf es { type yang:counter32; units "seconds"; description "Number of Errored Seconds (ES). An ES is a one-second period with one or more errored blocks or at least one defect. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of 'discontinuity-time' in ietf-interfaces."; reference "ITU-T G.826"; } leaf ses { type yang:counter32; units "seconds"; description "Number of Severely Errored Seconds (SES). SES is a one-second period which contains equal or more than 30% errored blocks or at least one defect. SES is a subset of ES. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of 'discontinuity-time' in ietf-interfaces."; reference "ITU-T G.826"; } leaf uas { type yang:counter32; units "seconds"; description "Number of Unavailable Seconds (UAS), that is, the total time that the node has been unavailable. Ahlberg, et al. Expires May 10, 2019 [Page 22] Internet-Draft Microwave YANG Model November 2018 Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of 'discontinuity-time' in ietf-interfaces."; reference "ITU-T G.826"; } } container radio-performance-statistics { config false; description "ETSI EN 301 129 radio physical interface statistics relevant for a carrier termination."; leaf min-rltm { type power { range "-99..-20"; } units "dBm"; description "Minimum received power level. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of 'discontinuity-time' in ietf-interfaces."; reference "ETSI EN 301 129"; } leaf max-rltm { type power { range "-99..-20"; } units "dBm"; description "Maximum received power level. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of 'discontinuity-time' in ietf-interfaces."; reference "ETSI EN 301 129"; } leaf min-tltm { type power { range "-99..99"; } units "dBm"; description Ahlberg, et al. Expires May 10, 2019 [Page 23] Internet-Draft Microwave YANG Model November 2018 "Minimum transmitted power level. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of 'discontinuity-time' in ietf-interfaces."; reference "ETSI EN 301 129"; } leaf max-tltm { type power { range "-99..99"; } units "dBm"; description "Maximum transmitted power level. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of 'discontinuity-time' in ietf-interfaces."; reference "ETSI EN 301 129"; } } } /* * Radio Link Protection Groups */ container radio-link-protection-groups { description "Configuration of radio link protected groups (1+1) of carrier terminations in a radio link. More than one protected group per radio-link-terminal is allowed."; uses ifprot:protection-groups { refine protection-group/members { must "derived-from-or-self(/if:interfaces/if:interface" + "[if:name = current()]" + "/if:type, 'mw-types:carrier-termination')" { description "The type of a protection member must be 'carrier-termination'."; } } refine protection-group/working-entity { must "derived-from-or-self(/if:interfaces/if:interface" Ahlberg, et al. Expires May 10, 2019 [Page 24] Internet-Draft Microwave YANG Model November 2018 + "[if:name = current()]" + "/if:type, 'mw-types:carrier-termination')" { description "The type of a working-entity must be 'carrier-termination'."; } } } } /* * XPIC & MIMO groups - Configuration data nodes */ container xpic-pairs { if-feature xpic; description "Configuration of carrier termination pairs for operation in XPIC mode."; reference "ETSI TR 102 311"; list xpic-pair { key "name"; description "List of carrier termination pairs in XPIC mode."; leaf name { type string; description "Name used for identification of the XPIC pair."; } leaf enabled { type boolean; default "false"; description "Enable(true)/disable(false) XPIC"; } leaf-list members { type if:interface-ref; must "derived-from-or-self(/if:interfaces/if:interface" + "[if:name = current()]" + "/if:type, 'mw-types:carrier-termination')" { description "The type of a member must be 'carrier-termination'."; } min-elements 2; Ahlberg, et al. Expires May 10, 2019 [Page 25] Internet-Draft Microwave YANG Model November 2018 max-elements 2; description "Association to XPIC pairs used in the radio link terminal."; } } } container mimo-groups { if-feature mimo; description "Configuration of carrier terminations for operation in MIMO mode."; reference "ETSI TR 102 311"; list mimo-group { key "name"; description "List of carrier terminations in MIMO mode."; leaf name { type string; description "Name used for identification of the MIMO group."; } leaf enabled { type boolean; default "false"; description "Enable(true)/disable(false) MIMO"; } leaf-list members { type if:interface-ref; must "derived-from-or-self(/if:interfaces/if:interface" + "[if:name = current()]" + "/if:type, 'mw-types:carrier-termination')" { description "The type of a member must be 'carrier-termination'."; } min-elements 2; description "Association to a MIMO group if used in the radio link terminal."; } } Ahlberg, et al. Expires May 10, 2019 [Page 26] Internet-Draft Microwave YANG Model November 2018 } } <CODE ENDS> 5. Interface Protection YANG Module The data nodes for management of the interface protection functionality is broken out from the Microwave Radio Link Module into a separate and generic YANG data module in order to make it available also for other interface types. This module imports modules from [RFC8343], and it references [G.808.1]. <CODE BEGINS> file "ietf-interface-protection@2018-11-06.yang" module ietf-interface-protection { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-interface-protection"; prefix ifprot; import ietf-interfaces { prefix if; reference "RFC8343"; } organization "Internet Engineering Task Force (IETF) CCAMP WG"; contact "WG List: <mailto:ccamp@ietf.org> ID-draft editors: Jonas Ahlberg (jonas.ahlberg@ericsson.com); Min Ye (amy.yemin@huawei.com); Xi Li (Xi.Li@neclab.eu); Daniela Spreafico (daniela.spreafico@nokia.com) Marko Vaupotic (Marko.Vaupotic@aviatnet.com)"; description "This is a module for the entities in a generic interface protection mechanism. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Ahlberg, et al. Expires May 10, 2019 [Page 27] Internet-Draft Microwave YANG Model November 2018 Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved."; revision 2018-11-06 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for Microwave Radio Link"; } /* * Protection architecture type identities */ identity protection-architecture-type { description "protection architecture type"; reference "ITU-T G.808.1"; } identity one-plus-one-type { base protection-architecture-type; description "1+1, One interface protects another one interface."; reference "ITU-T G.808.1"; } identity one-to-n-type { base protection-architecture-type; description "1:N, One interface protects n other interfaces."; reference "ITU-T G.808.1"; } /* * Protection states identities */ Ahlberg, et al. Expires May 10, 2019 [Page 28] Internet-Draft Microwave YANG Model November 2018 identity protection-states { description "Identities describing the status of the protection, in a group of interfaces configured in a protection mode."; } identity unprotected { base protection-states; description "Not protected"; } identity protected { base protection-states; description "Protected"; } identity unable-to-protect { base protection-states; description "Unable to protect"; } /* * Protection Groups */ grouping protection-groups { description "Configuration of protected groups (1+1) of interfaces providing protection for each other. More than one protected group per higher-layer-interface is allowed."; list protection-group { key "name"; description "List of protected groups of interfaces in a higher-layer-interface."; leaf name { type string; description "Name used for identification of the protection group"; } leaf protection-architecture-type { type identityref { base protection-architecture-type; } Ahlberg, et al. Expires May 10, 2019 [Page 29] Internet-Draft Microwave YANG Model November 2018 default "ifprot:one-plus-one-type"; description "The type of protection architecture used, e.g. one interface protecting one or several other interfaces."; reference "ITU-T G.808.1"; } leaf-list members { type if:interface-ref; min-elements 2; description "Association to a group of interfaces configured for protection and used by a higher-layer-interface."; } leaf operation-type { type enumeration { enum "non-revertive" { description "In non revertive operation, the traffic does not return to the working interface if the switch requests are terminated."; reference "ITU-T G.808.1"; } enum "revertive" { description "In revertive operation, the traffic always returns to (or remains on) the working interface if the switch requests are terminated."; reference "ITU-T G.808.1"; } } default "non-revertive"; description "The type of protection operation, i.e. revertive or non-revertive operation."; } leaf-list working-entity { when "../operation-type = 'revertive'"; type if:interface-ref; min-elements 1; description "The interfaces over which the traffic normally should be transported over when there is no need to use the protecting interface."; } Ahlberg, et al. Expires May 10, 2019 [Page 30] Internet-Draft Microwave YANG Model November 2018 leaf revertive-wait-to-restore { when "../operation-type = 'revertive'"; type uint16; units "seconds"; default "0"; description "The time to wait before switching back to the working interface if operation-type is revertive."; reference "ITU-T G.808.1"; } leaf hold-off-timer { type uint16; units "milliseconds"; default "0"; description "Time interval after the detection of a fault and its confirmation as a condition requiring the protection switching procedure."; reference "ITU-T G.808.1"; } leaf status { type identityref { base protection-states; } config false; description "Status of the protection, in a group of interfaces configured in a protection mode."; reference "ITU-T G.808.1"; } action manual-switch-working { description "A switch action initiated by an operator command. It switches normal traffic signal to the working transport entity."; reference "ITU-T G.808.1"; } action manual-switch-protection { description "A switch action initiated by an operator command. It switches normal traffic signal to the protection transport entity."; reference "ITU-T G.808.1"; } Ahlberg, et al. Expires May 10, 2019 [Page 31] Internet-Draft Microwave YANG Model November 2018 action forced-switch { description "A switch action initiated by an operator command. It switches normal traffic signal to the protection transport entity and forces it to remain on that entity even when criteria for switching back to the original entity are fulfilled."; reference "ITU-T G.808.1"; } action lockout-of-protection { description "A switch action temporarily disables access to the protection transport entity for all signals."; reference "ITU-T G.808.1"; } action freeze { description "A switch action temporarily prevents any switch action to be taken and, as such, freezes the current state. Until the freeze is cleared, additional near-end external commands are rejected and fault condition changes and received APS messages are ignored.."; reference "ITU-T G.808.1"; } action exercise { description "A switch action to test if the APS communication is operating correctly. It is lower priority than any 'real' switch request.."; reference "ITU-T G.808.1"; } action clear { description "An action clears all switch commands."; reference "ITU-T G.808.1"; } } } } <CODE ENDS> Ahlberg, et al. Expires May 10, 2019 [Page 32] Internet-Draft Microwave YANG Model November 2018 6. Microwave Types YANG Module This module defines a collection of common data types using the YANG data modeling language. These common types are designed to be imported by other modules defined in the microwave area. <CODE BEGINS> file "ietf-microwave-types@2018-11-06.yang" module ietf-microwave-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-microwave-types"; prefix mw-types; import iana-if-type { prefix ianaift; reference "RFC 7224"; } organization "Internet Engineering Task Force (IETF) CCAMP WG"; contact "WG List: <mailto:ccamp@ietf.org> ID-draft editors: Jonas Ahlberg (jonas.ahlberg@ericsson.com); Min Ye (amy.yemin@huawei.com); Xi Li (Xi.Li@neclab.eu); Daniela Spreafico (daniela.spreafico@nokia.com) Marko Vaupotic (Marko.Vaupotic@aviatnet.com)"; description "This module contains a collection of YANG data types considered generally useful for microwave interfaces. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. Ahlberg, et al. Expires May 10, 2019 [Page 33] Internet-Draft Microwave YANG Model November 2018 Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved."; revision 2018-11-06 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for Microwave Radio Link"; } /* * Interface identities */ identity radio-link-terminal { base ianaift:iana-interface-type; description "Interface identity for a radio link terminal."; } identity carrier-termination { base ianaift:iana-interface-type; description "Interface identity for a carrier termination."; } /* * Radio-link-terminal mode identities */ identity rlt-mode { description "A description of the mode in which the radio link terminal is configured. The format is X plus Y. X represent the number of bonded carrier terminations. Y represent the number of protecting carrier terminations."; } identity one-plus-zero { base rlt-mode; description "1 carrier termination only."; } identity one-plus-one { base rlt-mode; description "1 carrier termination and 1 protecting carrier termination."; Ahlberg, et al. Expires May 10, 2019 [Page 34] Internet-Draft Microwave YANG Model November 2018 } identity two-plus-zero { base rlt-mode; description "2 bonded carrier terminations."; } /* * Coding and modulation identities */ identity coding-modulation { description "The coding and modulation schemes."; } identity half-bpsk { base coding-modulation; description "Half BPSK coding and modulation scheme."; } identity half-bpsk-strong { base half-bpsk; description "Half BPSK strong coding and modulation scheme."; } identity half-bpsk-light { base half-bpsk; description "Half BPSK light coding and modulation scheme."; } identity bpsk { base coding-modulation; description "BPSK coding and modulation scheme."; } identity bpsk-strong { base bpsk; description "BPSK strong coding and modulation scheme."; } identity bpsk-light { Ahlberg, et al. Expires May 10, 2019 [Page 35] Internet-Draft Microwave YANG Model November 2018 base bpsk; description "BPSK light coding and modulation scheme."; } identity qpsk { base coding-modulation; description "QPSK coding and modulation scheme."; } identity qam-4 { base coding-modulation; description "4 QAM coding and modulation scheme."; } identity qam-4-strong { base qam-4; description "4 QAM strong coding and modulation scheme."; } identity qam-4-light { base qam-4; description "4 QAM light coding and modulation scheme."; } identity qam-16 { base coding-modulation; description "16 QAM coding and modulation scheme."; } identity qam-16-strong { base qam-16; description "16 QAM strong coding and modulation scheme."; } identity qam-16-light { base qam-16; description "16 QAM light coding and modulation scheme."; } identity qam-32 { Ahlberg, et al. Expires May 10, 2019 [Page 36] Internet-Draft Microwave YANG Model November 2018 base coding-modulation; description "32 QAM coding and modulation scheme."; } identity qam-32-strong { base qam-32; description "32 QAM strong coding and modulation scheme."; } identity qam-32-light { base qam-32; description "32 QAM light coding and modulation scheme."; } identity qam-64 { base coding-modulation; description "64 QAM coding and modulation scheme."; } identity qam-64-strong { base qam-64; description "64 QAM strong coding and modulation scheme."; } identity qam-64-light { base qam-64; description "64 QAM light coding and modulation scheme."; } identity qam-128 { base coding-modulation; description "128 QAM coding and modulation scheme."; } identity qam-128-strong { base qam-128; description "128 QAM strong coding and modulation scheme."; } identity qam-128-light { Ahlberg, et al. Expires May 10, 2019 [Page 37] Internet-Draft Microwave YANG Model November 2018 base qam-128; description "128 QAM light coding and modulation scheme."; } identity qam-256 { base coding-modulation; description "256 QAM coding and modulation scheme."; } identity qam-256-strong { base qam-256; description "256 QAM strong coding and modulation scheme."; } identity qam-256-light { base qam-256; description "256 QAM light coding and modulation scheme."; } identity qam-512 { base coding-modulation; description "512 QAM coding and modulation scheme."; } identity qam-512-strong { base qam-512; description "512 QAM strong coding and modulation scheme."; } identity qam-512-light { base qam-512; description "512 QAM light coding and modulation scheme."; } identity qam-1024 { base coding-modulation; description "1024 QAM coding and modulation scheme."; } identity qam-1024-strong { Ahlberg, et al. Expires May 10, 2019 [Page 38] Internet-Draft Microwave YANG Model November 2018 base qam-1024; description "1024 QAM strong coding and modulation scheme."; } identity qam-1024-light { base qam-1024; description "1024 QAM light coding and modulation scheme."; } identity qam-2048 { base coding-modulation; description "2048 QAM coding and modulation scheme."; } identity qam-2048-strong { base qam-2048; description "2048 QAM strong coding and modulation scheme."; } identity qam-2048-light { base qam-2048; description "2048 QAM light coding and modulation scheme."; } identity qam-4096 { base coding-modulation; description "4096 QAM coding and modulation scheme."; } identity qam-4096-strong { base qam-4096; description "4096 QAM strong coding and modulation scheme."; } identity qam-4096-light { base qam-4096; description "4096 QAM light coding and modulation scheme."; } /* Ahlberg, et al. Expires May 10, 2019 [Page 39] Internet-Draft Microwave YANG Model November 2018 * TDM-type identities */ identity tdm-type { description "A description of the type of TDM connection, also indicating the supported capacity of the connection."; } identity E1 { base tdm-type; description "E1 connection, 2.048 Mbit/s."; } identity STM-1 { base tdm-type; description "STM-1 connection, 155.52 Mbit/s."; } } <CODE ENDS&New version accepted (logged-in submitter: Kent Watsen) |
2020-03-08
|
18 | Kent Watsen | Uploaded new revision |
2019-11-20
|
17 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-17.txt |
2019-11-20
|
17 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2019-11-20
|
17 | Kent Watsen | Uploaded new revision |
2019-11-02
|
16 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-16.txt |
2019-11-02
|
16 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2019-11-02
|
16 | Kent Watsen | Uploaded new revision |
2019-10-18
|
15 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-15.txt |
2019-10-18
|
15 | (System) | New version approved |
2019-10-18
|
15 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen |
2019-10-18
|
15 | Kent Watsen | Uploaded new revision |
2019-07-02
|
14 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-14.txt |
2019-07-02
|
14 | (System) | New version approved |
2019-07-02
|
14 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen |
2019-07-02
|
14 | Kent Watsen | Uploaded new revision |
2019-06-07
|
13 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-13.txt |
2019-06-07
|
13 | (System) | New version approved |
2019-06-07
|
13 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen |
2019-06-07
|
13 | Kent Watsen | Uploaded new revision |
2019-04-29
|
12 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-12.txt |
2019-04-29
|
12 | (System) | New version approved |
2019-04-29
|
12 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen |
2019-04-29
|
12 | Kent Watsen | Uploaded new revision |
2019-04-07
|
11 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-11.txt |
2019-04-07
|
11 | (System) | New version approved |
2019-04-07
|
11 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen |
2019-04-07
|
11 | Kent Watsen | Uploaded new revision |
2019-03-09
|
10 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-10.txt |
2019-03-09
|
10 | (System) | New version approved |
2019-03-09
|
10 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen |
2019-03-09
|
10 | Kent Watsen | Uploaded new revision |
2019-03-09
|
09 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-09.txt |
2019-03-09
|
09 | (System) | New version approved |
2019-03-09
|
09 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen , netconf-chairs@ietf.org |
2019-03-09
|
09 | Kent Watsen | Uploaded new revision |
2018-10-22
|
08 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-08.txt |
2018-10-22
|
08 | (System) | New version approved |
2018-10-22
|
08 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen |
2018-10-22
|
08 | Kent Watsen | Uploaded new revision |
2018-09-20
|
07 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-07.txt |
2018-09-20
|
07 | (System) | New version approved |
2018-09-20
|
07 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen , netconf-chairs@ietf.org, Gary Wu |
2018-09-20
|
07 | Kent Watsen | Uploaded new revision |
2018-06-04
|
06 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-06.txt |
2018-06-04
|
06 | (System) | New version approved |
2018-06-04
|
06 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen , Gary Wu |
2018-06-04
|
06 | Kent Watsen | Uploaded new revision |
2018-05-03
|
05 | (System) | Document has expired |
2017-10-30
|
05 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-05.txt |
2017-10-30
|
05 | (System) | New version approved |
2017-10-30
|
05 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen , Gary Wu , netconf-chairs@ietf.org, Juergen Schoenwaelder |
2017-10-30
|
05 | Kent Watsen | Uploaded new revision |
2017-10-30
|
05 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen , Gary Wu , netconf-chairs@ietf.org, Juergen Schoenwaelder |
2017-10-30
|
05 | Kent Watsen | Uploaded new revision |
2017-07-28
|
04 | Andy Bierman | Request for Last Call review by YANGDOCTORS Completed: Ready with Nits. Reviewer: Andy Bierman. Sent review to list. |
2017-07-10
|
04 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Andy Bierman |
2017-07-10
|
04 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Andy Bierman |
2017-07-10
|
04 | Mehmet Ersue | Requested Last Call review by YANGDOCTORS |
2017-07-03
|
04 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-04.txt |
2017-07-03
|
04 | (System) | New version approved |
2017-07-03
|
04 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen , Gary Wu , Juergen Schoenwaelder |
2017-07-03
|
04 | Kent Watsen | Uploaded new revision |
2017-06-13
|
03 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-03.txt |
2017-06-13
|
03 | (System) | New version approved |
2017-06-13
|
03 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen , Gary Wu , Juergen Schoenwaelder |
2017-06-13
|
03 | Kent Watsen | Uploaded new revision |
2017-03-15
|
02 | Mahesh Jethanandani | Added to session: IETF-98: netconf Tue-1640 |
2017-03-13
|
02 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-02.txt |
2017-03-13
|
02 | (System) | New version approved |
2017-03-13
|
02 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen , netconf-chairs@ietf.org, Gary Wu , =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= |
2017-03-13
|
02 | Kent Watsen | Uploaded new revision |
2016-11-03
|
01 | Cindy Morgan | New version available: draft-ietf-netconf-netconf-client-server-01.txt |
2016-11-03
|
01 | (System) | Secretariat manually posting. Approvals already received |
2016-11-03
|
00 | Cindy Morgan | Uploaded new revision |
2016-07-16
|
00 | Mahesh Jethanandani | draft-ietf-netconf-server-config model is now split into five drafts. This is one of them. For details on the decision see interim meeting notes from May 2016. |
2016-07-16
|
00 | Mahesh Jethanandani | This document now replaces draft-ietf-netconf-server-model instead of None |
2016-07-09
|
00 | Kent Watsen | New version available: draft-ietf-netconf-netconf-client-server-00.txt |