Protocol Action: 'A YANG Data Model for RESTCONF Clients and Servers' to Proposed Standard (draft-ietf-netconf-restconf-client-server-44.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'A YANG Data Model for RESTCONF Clients and Servers'
  (draft-ietf-netconf-restconf-client-server-44.txt) as Proposed Standard

This document is the product of the Network Configuration Working Group.

The IESG contact persons are Mahesh Jethanandani and Mohamed Boucadair.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/




Technical Summary

   This document presents two YANG modules, one module to configure a
   RESTCONF client and the other module to configure a RESTCONF server.
   Both modules support the TLS transport protocol with both standard
   RESTCONF and RESTCONF Call Home connections.

Editorial Note (To be removed by RFC Editor)

   This draft contains placeholder values that need to be replaced with
   finalized values at the time of publication.  This note summarizes
   all of the substitutions that are needed.  No other RFC Editor
   instructions are specified elsewhere in this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements (note: not all may
   be present):

   *  AAAA --> the assigned RFC value for draft-ietf-netconf-crypto-
      types

   *  BBBB --> the assigned RFC value for draft-ietf-netconf-trust-
      anchors

   *  CCCC --> the assigned RFC value for draft-ietf-netconf-keystore

   *  DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client-
      server

   *  EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client-
      server

   *  FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client-
      server

   *  GGGG --> the assigned RFC value for draft-ietf-netconf-http-
      client-server

   *  HHHH --> the assigned RFC value for draft-ietf-netconf-netconf-
      client-server

   *  IIII --> the assigned RFC value for this draft

   Artwork in this document contains placeholder values for the date of
   publication of this draft.  Please apply the following replacement:

   *  2024-08-14 --> the publication date of this draft

   The "Relation to other RFCs" section Section 1.1 contains the text
   "one or more YANG modules" and, later, "modules".  This text is
   sourced from a file in a context where it is unknown how many modules
   a draft defines.  The text is not wrong as is, but it may be improved
   by stating more directly how many modules are defined.

   The "Relation to other RFCs" section Section 1.1 contains a self-
   reference to this draft, along with a corresponding reference in the
   Appendix.  Please replace the self-reference in this section with
   "This RFC" (or similar) and remove the self-reference in the
   "Normative/Informative References" section, whichever it is in.

   Tree-diagrams in this draft may use the '\' line-folding mode defined
   in RFC 8792.  However, nicer-to-the-eye is when the '\\' line-folding
   mode is used.  The AD suggested suggested putting a request here for
   the RFC Editor to help convert "ugly" '\' folded examples to use the
   '\\' folding mode.  "Help convert" may be interpreted as, identify
   what looks ugly and ask the authors to make the adjustment.

   The following Appendix section is to be removed prior to publication:

   *  Appendix A.  Change Log

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

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 the WG meeting and on the NETCONF
WG mailing list, the authors and Shepherd believe that all the comments and
questions from that review have been incorporated into the document.

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

The shepherd knows neither existing nor potential implementations of YANG
models defined in this document. No existing implementations have been publicly
reported.

Personnel

   The Document Shepherd for this document is Qiufang Ma. The Responsible
   Area Director is Mahesh Jethanandani.