Telechat Review of draft-ietf-netconf-http-client-server-23
review-ietf-netconf-http-client-server-23-httpdir-telechat-nottingham-2024-08-19-00
| Request | Review of | draft-ietf-netconf-http-client-server-23 |
|---|---|---|
| Requested revision | 23 (document currently at 23) | |
| Type | Telechat Review | |
| Team | HTTP Directorate (httpdir) | |
| Deadline | 2024-08-22 | |
| Requested | 2024-08-19 | |
| Requested by | Francesca Palombini | |
| Authors | Kent Watsen | |
| I-D last updated | 2024-08-19 | |
| Completed reviews |
Secdir Last Call review of -16
by Shivan Kaul Sahib
(diff)
Yangdoctors Last Call review of -06 by Ladislav Lhotka (diff) Httpdir Telechat review of -23 by Mark Nottingham |
|
| Comments |
Hi, This was previously on IESG evaluation at v-17, but after been approved it was sent back because of a discussion with Mark and Lars in Brisbane (https://mailarchive.ietf.org/arch/msg/netconf/qob5xg46ACuHytB59MkFd65rvZ0/) regarding how the client HTTP stack is being modelled in YANG. The authors have attempted to fix their doc. I don't know if you have been involved in the update. I could not find recordings of that discussion or follow ups, but Mark if you had time to check this before telechat on Thursday it would be greatly appreciated. I know it is short deadline, once more, let me know if it's doable at all. Thanks! |
|
| Assignment | Reviewer | Mark Nottingham |
| State | Completed | |
| Request | Telechat review on draft-ietf-netconf-http-client-server by HTTP Directorate Assigned | |
| Reviewed revision | 23 | |
| Result | Not ready | |
| Completed | 2024-08-19 |
review-ietf-netconf-http-client-server-23-httpdir-telechat-nottingham-2024-08-19-00
My recollection of our most recent discussions of this draft were that it _might_ make sense to allow configuration of what version(s) of HTTP a server supports, but not a client. Since -17, it appears the opposite has been done: while server configuration remains the same, client configuration now allows enumeration of supported versions. Additionally, support is indicated by using separate, version-specific indicators. This is a closed list and does not accommodate future versions of the protocol. Can this be an array of strings instead? That would also allow us to avoid the awkward phrasing in the introduction, which leads readers to believe the set of HTTP versions is closed (counter to BCP56).