Hi Shivan,On Feb 15, 2024, at 8:05 PM, Shivan Kaul Sahib <shivankaulsahib@xxxxxxxxx> wrote:
Hi Shivan,
Thank you for your review! Responses below.
Kent
On Feb 9, 2024, at 9:58 PM, Shivan Sahib via Datatracker < noreply@xxxxxxxx> wrote:
Reviewer: Shivan Sahib
Review result: Has Nits
It looks like the document previously got review from HTTP WG, and generally
looks well thought out.
Thanks.
This document doesn’t support QUIC (yet). The document’s title is “YANG Groupings for HTTP 1.1/2.0 Clients and HTTP Servers”.
Everybody wants this document to support QUIC. Doing this would entail a new document called “quic-client-server”.
Do you know if there are any quic-specific configurations, beyond the basic UDP local/remote/ address/port config? - for either the client or the server?
I guess a broader question I had (non-blocking security wise) is who is looking to deploy this document? Are those parties not interested in QUIC?
Two answers:
1) The NETCONF WG, in order to enable the configuration of RESTCONF clients and servers. Technically, RFC 8040 (RESTCONF) allows RESTCONF to run on top on QUIC but, AFAIKt, most RESTCONF implementations are HTTP 1.1.
2) Other WGs and/or SDOs. This document is meant to support configuration of any HTTP-based client/server. That said, no one other than the IESG has ever asked for QUIC support in the 5-years the document has been active.
I believe the answer is, AFAIK, those parties are not (currently) interested in QUIC.
I just added the following sentence to that section:
The "proxy-connect" node defines support for HTTP 1.1 and HTTP 2.0. Support for other protocols versions, e.g., HTTP/3, MAY be augmented in via future work.
s/protocols/protocol, but lgtm otherwise.
Fixed - thanks!
K.
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
