YANG Groupings for HTTP Clients and HTTP Servers
draft-ietf-netconf-http-client-server-33
Yes
(Robert Wilton)
No Objection
(Andrew Alston)
(Erik Kline)
(John Scudder)
(Warren Kumari)
Note: This ballot was opened for revision 17 and is now closed.
Éric Vyncke
No Objection
Comment
(2024-02-12 for -17)
Sent
# Éric Vyncke, INT AD, comments for draft-ietf-netconf-http-client-server-17 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Mahesh Jethanandani for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## What about HTTP3 ? Is HTTP/3 (RFC 9114) so different to HTTP1/HTTP2 that it is not included in this I-D ? ## Section 2.1.2.1 Having a module only using basic authentication seems *very* restrictive in 2024... I would have expected the WG to specify a YANG module supporting other authentication scheme.
Roman Danyliw
(was Discuss)
No Objection
Comment
(2024-03-09 for -19)
Sent
Thank you for addressing my DISCUSS and COMMENT feedback.
Robert Wilton Former IESG member
Yes
Yes
(for -17)
Unknown
Andrew Alston Former IESG member
No Objection
No Objection
(for -17)
Not sent
Erik Kline Former IESG member
No Objection
No Objection
(for -17)
Not sent
John Scudder Former IESG member
No Objection
No Objection
(for -17)
Not sent
Murray Kucherawy Former IESG member
No Objection
No Objection
(2024-02-15 for -17)
Sent
Feedback from Orie Steele, incoming ART AD:
eaf server-name {
nacm:default-deny-write;
type string;
description
"The value of the 'Server' header field. If not set, then
underlying software's default value is used. Set to the
empty string to disable.";
}
I'm not a YANG expert, is "type string" shorthand for "UTF-8 string" ?
I don't see any ART review, are there any i18n issues expected with this document?
Paul Wouters Former IESG member
No Objection
No Objection
(2024-02-14 for -17)
Not sent
I support Roman's DISCUSS
Warren Kumari Former IESG member
No Objection
No Objection
(for -17)
Sent
Zaheduzzaman Sarker Former IESG member
No Objection
No Objection
(2024-02-13 for -17)
Sent
Thanks for working on this specification. This looks good to me from transport protocol point of view.
I have following comment and I believe if addressed properly, it will improve the document quality -
# Section 1 says -
It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers).
I would like to see some examples of the "simple HTTP-based protocols" - the words in parenthesis does not help the distinction. The motivation and usage of this protocol should be specified clearly.