Skip to main content

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