This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

The draft defines a YANG model to configure restconf client and server instances.
Defining a data model does not directly raise transport concerns.  The implications
of such configurations could have an indirect impact on network traffic; this is the
aspect briefly reviewed in the following.

Client and server use HTTPS for information exchange (this is the only permissible
scheme in the present draft) and hence apply security mechanisms and utilise congestion
controlled transport protocols.  Hence, no issues to be expected here.

There does not seem to be much of an incidental DoS or congestion risk through connection
establishment either.  The draft defines persistent connections (which bind server
resources) and periodic connections, which are established in regular intervals.  These
intervals are defined in the unit of minutes and hence should not cause excessive load
unless very large numbers of clients are involved.

Individual clients only seem to connect to one server at a time and, if connection
attempts fail, they reconnect after a period measured in units of seconds (to the
same or to a different server).  There is small risk of traffic surges if many clients
are configured to reach the same server or small set of servers if those are not 
responding, but there is an upper limit imposed on the retry count.  So, this should
work well, too.  Not sure if some guidance should be given -- this is mostly a question
of how other YANG models in this context are written, which I just don't know enough
about.

The draft also discusses keepalives for connections, probe intervals, for which the
default values look reasonable.  One might want to give again some guidance regarding
those given the rather variable experience with timeouts in (carrier-grade) NATs. For TCP,
NATs are usually quite generous but I am not sure how those behave with UDP when QUIC is
run on top given that there is no visible FIN bit to remove state.  Such connections
might be timed out more aggressively; it is worthwhile checking today's practical
experience (since HTTPS might turn out to be H3).

The draft mentions "TCP sessions" where I would have expected it to refer to TCP
connections, but maybe there is a different set of terminology in place here?