This is my review of OPSDIR draft-ietf-netconf-restconf-client-server-38.

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

First, a big thank you to Kent for pulling this work through to completion, and building such a well-structured collection of documents. This has clearly been a big effort executed with great precision over a long period.

I can only think of two minor remarks to make.

#1) Free floating groupings

The document defines a collection of server and client YANG groupings, and also defines optional top level containers to hold instances of these groupings. The top level containers are optional to allow additional flexibility:

   *  The reason for why "restconf-server-app-grouping" exists separate
      from the protocol-accessible nodes definition is so as to enable
      instances of restconf-server-app-grouping to be instantiated in
      other locations, as may be needed or desired by some modules.

As always, there is a bit of tension between standards and flexibility, however, as standards are essentially constraints on the infinite flexibility of chaos. The document could perhaps do a little more to encourage implementers to leverage the standard path for this restconf-server (and the same goes for -client) YANG structure. There is an interoperability price to pay every time a custom path is “needed or desired”.

#2) Future extensibility catch-22

These documents have been designed for future extensibility in an exemplary way. In particular, the ietf-restconf-client module is prepared for the day when HTTPS might not be relevant any more. When that happens, a server may simply stop advertising the https-initiate feature.

     feature https-initiate {
       description
         "The 'https-initiate' feature indicates that the RESTCONF
          client supports initiating HTTPS connections to RESTCONF
          servers. This feature exists as HTTPS might not be a
          mandatory to implement transport in the future.";
       reference
         "RFC 8040: RESTCONF Protocol";
     }

Further down the initiate container contains connection parameters that are independent of the particular transport protocol used. Unfortunately, however, the entire container initiate is predicated on the https-initiate feature.

       container initiate {
         if-feature "https-initiate";
         presence
           "Indicates that client-initiated connections have been
            configured.  This statement is present so the mandatory
            descendant nodes do not imply that this node must be
            configured.";

This means all these parameters for client-initiated connection are only valid if HTTPS is supported after all. I think a separate feature for support for client-initiated connections, regardless of protocol, would have been better prepared for the future.

There is an analogous construct for container listen and features “http-listen or https-listen”.