Last Call Review of draft-ietf-netconf-restconf-client-server-38
review-ietf-netconf-restconf-client-server-38-tsvart-lc-ott-2024-09-13-00
Request | Review of | draft-ietf-netconf-restconf-client-server |
---|---|---|
Requested revision | No specific revision (document currently at 38) | |
Type | Last Call Review | |
Team | Transport Area Review Team (tsvart) | |
Deadline | 2024-09-13 | |
Requested | 2024-08-30 | |
Authors | Kent Watsen | |
I-D last updated | 2024-09-13 | |
Completed reviews |
Yangdoctors Last Call review of -04
by Andy Bierman
(diff)
Yangdoctors Last Call review of -38 by Andy Bierman Opsdir Last Call review of -38 by Jan Lindblad Tsvart Last Call review of -38 by Joerg Ott Genart Last Call review of -38 by Linda Dunbar |
|
Assignment | Reviewer | Joerg Ott |
State | Completed | |
Request | Last Call review on draft-ietf-netconf-restconf-client-server by Transport Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/tsv-art/89lc1O9V1VMno-_PqumwIGEn7cI | |
Reviewed revision | 38 | |
Result | Ready w/nits | |
Completed | 2024-09-13 |
review-ietf-netconf-restconf-client-server-38-tsvart-lc-ott-2024-09-13-00
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?