Reviewer: Jan Lindblad
Review result: Ready
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”.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
