Last Call Review of draft-ietf-netconf-restconf-client-server-04
review-ietf-netconf-restconf-client-server-04-yangdoctors-lc-bierman-2017-07-28-00
Request | Review of | draft-ietf-netconf-restconf-client-server-04 |
---|---|---|
Requested revision | 04 (document currently at 38) | |
Type | Last Call Review | |
Team | YANG Doctors (yangdoctors) | |
Deadline | 2017-07-31 | |
Requested | 2017-07-10 | |
Requested by | Mehmet Ersue | |
Authors | Kent Watsen | |
I-D last updated | 2017-07-28 | |
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 | Andy Bierman |
State | Completed | |
Request | Last Call review on draft-ietf-netconf-restconf-client-server by YANG Doctors Assigned | |
Reviewed revision | 04 (document currently at 38) | |
Result | Ready w/nits | |
Completed | 2017-07-28 |
review-ietf-netconf-restconf-client-server-04-yangdoctors-lc-bierman-2017-07-28-00
Review: draft-ietf-netconf-restconf-client-server-04 Modules: (M1) ietf-restconf-client@2017-07-03.yang (M2) ietf-restconf-server@2017-07-03.yang YANG Usage: I did not find anything wrong in either module. pyang and yangdump-pro do not report any errors or warnings. Comments: C1: (M1) RESTCONF does not have sessions so the term "RESTCONF session" needs to be defined C2: (M1) feature tls-initiate (M1) feature tls-listen (M2) feature tls-listen (M2) feature tls-call-home Are these features really needed since a RESTCONF server MUST support the TLS transport? C3: (M1) /restconf-client/initiate/restconf-server/persistent/ RESTCONF has no session setup; It only has request and response interactions. The purpose of reconnect, idle timeouts etc. are completely up to the client application. C4: (M1) /restconf-client/initiate/restconf-server/persistent/max-attempts What should the RESTCONF client do if a "Connection: close" header is received from the server (indicating the server is dropping the TCP connection) Should the reconnects proceed? C5: (M1) /restconf-client/initiate/restconf-server/periodic/ "Periodically connect to the RESTCONF server, so that the RESTCONF server may deliver messages pending for the RESTCONF client. The RESTCONF server must close the connection when it is ready to release it. This is not how RESTCONF works. The RESTCONF server requires a request message in order to send content to a client. I do not understand the use-case for periodic RESTCONF sessions. C6: (M1) /restconf-client/initiate/restconf-server/periodic/ (M2) /restconf-server/call-home/restconf-client/connection-type/periodic/ The RESTCONF notifications via SSE should be exempt from timeouts. The RESTCONF client should terminate an SSE request. The server should not timeout an SSE response connection C7: Sec 1.2 Tree Diagrams Old text should be replaced with reference to draft-ietf-netmod-yang-tree-diagrams-01 C8: (M1) IETF copyright says 2014; change to 2017 (M2) IETF copyright says 2014; change to 2017 Nits: Some descriptions mention SSH. This should be removed from this document. The descriptions for choices that have only 1 case should explain why a choice is being used. The tree diagram shows the fully expanded groupings, even many objects are in other drafts. I needed all 5 drafts open in windows for searching, plus pyang tree output, to really follow the data model structure. The examples do not show any usage of the hello-params. This would be useful because the namespace for the identityref objects (tls-version, cipher-suite) is not the same as the module that uses the grouping. Note that the 'map-type' identityref is shown correctly encoded in examples on page 19 and 20.