Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE44C14F71C; Thu, 22 Aug 2024 01:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhQzwegJNL7D; Thu, 22 Aug 2024 01:03:00 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2363C14F70D; Thu, 22 Aug 2024 01:03:00 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-202146e93f6so5007575ad.3; Thu, 22 Aug 2024 01:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724313780; x=1724918580; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iPE/jBzB5IXo1Ta+iB8GSpMleKaqXPdWWDE1Ueuz08Q=; b=RtTHf5/enDpwqMjbL4Id3Szg7D9tvMZfyV2Kf7b1PY2ZL774V4SxCKpp5XL0IDntoX MzNTeBfQreKJI0Aee/ilUrNij4jjulz+P1mbd92OKW44Yg7pgT17njvla3dV0XxBiFZk kkH9YVzwoEi3VWYLGsegnWPStsTNuXsBZWjPaMASb7ZB4jkCGp9BElQod5RXspYp2L6W Fo7nOk0iijkpZGHgARxQm6nT0WDeeq420fPv/J4UOMCg80BAj8fbs2swJUkqB7eHfcSA a26i3OOEJkWV2iOEcb+E4xSz0kQ7JA4sKMA4vEkNXVtlcbX0et7PSkwTkNvekg13WqmK j+OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724313780; x=1724918580; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iPE/jBzB5IXo1Ta+iB8GSpMleKaqXPdWWDE1Ueuz08Q=; b=kOhe6eoQFXbvfKO+PBsrKzIBTKHjW/oUqd+nmZqp1JjH7jCdSqDE5zoKQ9ZZiK7E2V G5lRi+WJT4z6LHxQC5lrH9+iV6MpU9ZftfYwypfqbVfZPfrN5GAVOolgGuKT9lv/zd+Q ZUTN8hSzdF0S4h9bJpVlRmhhl2zs54c/d1arUkcfaYTUZknEfX5ARmchCOKHDQwWSk7J WiHkUzWUXQ80bsU99Io/vhlyU2/nXWSpn3PHTj88MYuBZ1h9muGtwByCTF/5kCnnHWq5 Twb3Zrtw+UBDEb1853Mfr/IP/9bCaZScg46bjWzfUOqvDwHRxb74n+WQuqyPhdwco+/d o3Xw== X-Forwarded-Encrypted: i=1; AJvYcCVbX3W0NaFkYM5PAh2V6YuVBX1LecCGucMypAOtDBLqnuV/h82ctR0zMPF2WrLlCOLyfwSPXKePqFKBe2zCvBCI0wBYBMGz+VndISIo5OcrBo8RLWnW@ietf.org, AJvYcCW9nYprTtjeC8+giMj0Um/5UNvR2pkLV8lO5SuC85UA9MtCP4FYagtBhsiGtEulJlG6qbB6nNSiu0htWVS8sFI=@ietf.org, AJvYcCWk5x1+Qg05sciWQaXEBx4b6K2+mxz7lh4zWOFAA9wWAf95eK2k7Z1pfpkOXcE8+oRy8u0N70xgnQ==@ietf.org X-Gm-Message-State: AOJu0YzpH3pB90ozdJJxe8Y1FX3YPwPlH2H75LUWPEpWxH+pnaFeXoIs sePo1dLQI//IilZCOa+j0yoax7H+3qrk42v4yWTWm4NsIFGfs7q1UN6Y6sRdK1UYSFUvtDtHBn3 ZX56//BO5/KQCHLnOdkP+6IuHT80= X-Google-Smtp-Source: AGHT+IEs4rzUZpk7IUp+u5K35T+DdYCmxgNKs73U0em4WztKelKNQ4yZwNZ4wnEFkDbyxLaPOdtpjUSw9Z9qnUTgi2k= X-Received: by 2002:a17:90b:4c06:b0:2c9:84f9:a321 with SMTP id 98e67ed59e1d1-2d5e9b9a979mr5303967a91.23.1724313779808; Thu, 22 Aug 2024 01:02:59 -0700 (PDT) MIME-Version: 1.0 References: <172424862919.2332705.4639463315479746794@dt-datatracker-6df4c9dcf5-t2x2k> <01000191768c2061-c755f9d1-1775-4910-8b8a-ecd856328b5c-000000@email.amazonses.com> In-Reply-To: <01000191768c2061-c755f9d1-1775-4910-8b8a-ecd856328b5c-000000@email.amazonses.com> From: Zaheduzzaman Sarker Date: Thu, 22 Aug 2024 10:02:48 +0200 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary="00000000000053b31406204116b1" Message-ID-Hash: 7X5NRFDCUZMR3QABCJ7CR6RSCE75E6PA X-Message-ID-Hash: 7X5NRFDCUZMR3QABCJ7CR6RSCE75E6PA X-MailFrom: zahed.sarker.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netconf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The IESG , draft-ietf-netconf-http-client-server@ietf.org, "netconf-chairs@ietf.org" , "netconf@ietf.org" X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bnetconf=5D_Re=3A_Zaheduzzaman_Sarker=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-netconf-http-client-server-23=3A_=28with_COMMENT=29?= List-Id: NETCONF WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000053b31406204116b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 21, 2024 at 10:06=E2=80=AFPM Kent Watsen = wrote: > Hi Sarkar, > > Thank you for your review! > More comments below. > > Kent // as author > > > On Aug 21, 2024, at 9:57=E2=80=AFAM, Zaheduzzaman Sarker via Datatracker = < > noreply@ietf.org> wrote: > > Zaheduzzaman Sarker has entered the following ballot position for > draft-ietf-netconf-http-client-server-23: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positio= ns/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-http-client-server/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for working on this complex group of specifications. > > I have following comments/questions and I believe addressing those will > improve > the specification > > - May be I am failing to see the whole picture but I understand that > draft-ietf-netconf-tls-client-server defines tls-common module along > with > tls-client and tls-server modules, but I don't see the Section 3.1.2.2 > mentions tls-common module which is common to both client and server. i= s > this an overlook? if not then, I would expect some description of how > tls-common module is used here or not used here. ( I was initially > thinking > of this as discuss worthy but as I am not sure I understand how this > whole > thing is used together I am putting it as comment, and here is your > chance > to educate me :-) ) > > > I appreciate the opportunity! :) > > Let=E2=80=99s do this two ways: > > 1) Looking at =E2=80=9Cuses=E2=80=9D statements > > With the HTML format, looking at Section 3.1.2.2, > one > notices that the tree-diagram contains some lines prefixed by =E2=80=9C+-= --u=E2=80=9D. RFC > 8340, Section 2.2 > explains that > these are unexpanded =E2=80=9Cgrouping=E2=80=9D statements. That is, the= YANG module > itself contains a statement like =E2=80=9Cuses foo=E2=80=9D that appears = in the diagram as > =E2=80=9C-u foo=E2=80=9D. > > This diagram in particular *uses* four distinct grouping statements. > Immediately under the diagram there is a link to where each of grouping > statement is discussed. You asked specifically about the =E2=80=9Ctls-co= mmon=E2=80=9D > module, so let=E2=80=99s look at the "tls-server-grouping=E2=80=9D (being= the only grouping > that resolves in the tis-client-server draft). Under the diagram, there = is > a line that reads "For the referenced grouping statement(s)=E2=80=9D and,= in this > section, the third bullet point links Section 4.1.2.1 > of > [I-D.ietf-netconf-tls-client-server] > > Following that link, we=E2=80=99re now looking that the tree diagram for = the > "tls-server-grouping=E2=80=9D grouping. In this diagram, near the bottom= , you will > find a line that reads "-u tlscmn:hello-params-grouping=E2=80=9D. Pleas= e note > that the =E2=80=9Ctlscmn=E2=80=9D prefix is for the =E2=80=9Ctls-common= =E2=80=9D module you ask about. > The =E2=80=9Chello-params-grouping=E2=80=9D is the name of a =E2=80=9Cgro= uping=E2=80=9D statement in the =E2=80=9Ctls-common=E2=80=9D > module. We=E2=80=99re getting close=E2=80=A6 > > Just below this diagram, in the "For the referenced grouping statement(s)= =E2=80=9D > section, the last bullet point links Section 2.1.3.1 > in > the same document. Following that link, you will note that this section = is > under Section 2, which is entitled 'The "ietf-tls-common=E2=80=9D Module= =E2=80=99. Bingo! > > > 2. Looking at the =E2=80=9Cimport" statements > > Whilst we started off by looking at Section 3.1.2.2, which provides an > overview of the =E2=80=9Cietf-http-server=E2=80=9D module, Section 3.3 > presents > the YANG module itself. > > Note that the first paragraph in this Section 3.3 starts with "This YANG > module has references=E2=80=A6=E2=80=9D, with the second-to-last document= being > I-D.ietf-netconf-tls-client-server > . > We=E2=80=99ll come back to this in a moment=E2=80=A6 > > Looking at the module, notice that the 5th =E2=80=9Cimport=E2=80=9D state= ment is "import > ietf-tls-server=E2=80=9D. You may also at this time notice that there is= no import > statement for the =E2=80=9Cietf-tls-common=E2=80=9D module; that is, this= module doesn=E2=80=99t > import the tls-common module *directly*. > > Now, if we were the follow the I-D.ietf-netconf-tls-client-server > link > from above, and jump to Section 4.3 > , > which presents the =E2=80=9Cietf-tis-server=E2=80=9D YANG module, we see = that the 5th > =E2=80=9Cimport=E2=80=9D statement is "import ietf-tls-common=E2=80=9D. = That is, this module > imports =E2=80=9Ctls-common=E2=80=9D *directly*, whilst the =E2=80=9Cielf= -http-server=E2=80=9D module > imports =E2=80=9Ctls-common=E2=80=9D *indirectly*. > > > In sum, the "ielf-http-server=E2=80=9D module indirectly imports the > "ietf-tls-common=E2=80=9D module but, because it is an indirect import, i= t doesn=E2=80=99t > appear in the body of the text in the http-client-server draft. Makes > sense? > Now I know what was my source of confution. I started from the import and in my read I looked upto the feature section (4.1.1) and got mixed up. Now, I know I should looked into all the nested imports. Thanks for this excellent walk through and congratulations on becoming my mentor ( all my future YANG questions will be directed to you :-)) . > > > > > - Looking at Section 3.1.2.2 the quic-supported tree, I am wondering if > this > how it should be done or not. As TLS 1.3 is ovened into QUIC, QUIC take > cares of the TLS record layer, the way tls-server-parameters and > tls-server-grouping is used would it be sufficient? may be it does, but= I > dont understand it as TLS is not used with QUIC as it is used with TCP. > > > This is a fair observation. I too struggle if it=E2=80=99s best. In my = recent > interaction with Mark Nottingham, I wrote the three =E2=80=9Ccase=E2=80= =9D statements out > differently, something like this: > > tcp --> http-over-tcp // HTTP/1.1 or HTTP/2 > tls --> http-over-tls-over-tcp // HTTP/1.1 or HTTP/2 > quic --> http-over-quic-over-udp // currently just HTTP/3 > > These labels also don=E2=80=99t sit well with me, because they don=E2=80= =99t speak to > HTTP-versions (e.g., HTTP/1.1, HTTP/2, HTTP/3). I feel like there is a > level of indirection missing=E2=80=A6 > > For instance, now that we=E2=80=99re familiar with tree-diagrams (right?)= , it > seems more accurate for the three =E2=80=9Ccase=E2=80=9D statements to ac= tually be > =E2=80=9Cgrouping=E2=80=9D statements that could then be rolled into new = =E2=80=9Ccase=E2=80=9D statements > as follows: > > grouping http-server-stack-grouping: > +-- (http-version) > +--:(http11) {http11-supported}? > | +-- http11 > | +-- (transport) > | +-:(tcp) {tcp-supported}? > | | +-- tcp > | | +--u http-over-tcp-grouping > | +-:(tls) {tls-supported}? > | +-- tls > | +--u http-over-tls-over-tcp-grouping > +--:(http2) {http2-supported}? > | +-- (transport) > | +-:(tcp) {tcp-supported}? > | | +-- tcp > | | +--u http-over-tcp-grouping > | +-:(tls) {tls-supported}? > | +-- tls > | +--u http-over-tls-over-tcp-grouping > +--:(http3) {http3-supported}? > +-- (transport) > +-:(quic) {quic-supported}? > +-- quic > +--u http-over-quic-over-udp-grouping > > > This seems more accurate, but still doesn=E2=80=99t sit well with me. Fo= r > instance, when configuring an NGINX server (i.e., nginx.conf), there are > =E2=80=9Cserver=E2=80=9D stanzas that each have =E2=80=9Clisten=E2=80=9D = statements, which suggests > something more like this: > > grouping http-server-app-grouping: <=E2=80=94 note: this is an =E2=80= =9Capp=E2=80=9D grouping > (not a =E2=80=9Cstack=E2=80=9D grouping) > +-- server* [server-name] > +-- server-name string > +-- listen* [transport port] > | +-- transport enum w/ values =E2=80=9Ctcp=E2=80=9D and =E2=80= =9Cudp=E2=80=9D > | +-- port uint16 > | +-- http-version enum w/ values http11, http2, and http3 > | +-- tcp-server-parameters { if ../transport =3D =E2=80=99tcp= =E2=80=99 } > | | +=E2=80=94u tcps:tcp-server-grouping > | +-- udp-server-parameters { if ../transport =3D =E2=80=99udp= =E2=80=99 } > | +=E2=80=94u udps:udp-server-grouping > +-- tls-server-parameters > + +--u tlss:tls-server-grouping > +-- client-authentication {client-auth-supported} > +-- ... > > This is becoming interesting. It would all depend on the purpose of this grouping, right? if this is about cofiguring YANG clients and servers then you would like to provide as much details at you like even mentioning the HTTP versions and port numbers to run the servers on ... but it this is about dictating client behaviours then there could be issues with HTTP versions as there are different ways clients picks http versions AFAIK via negotiation or hardcoded. When you described the last variant of potential groupping, I could see that one can fold the QUIC support into UDP server grouping with specific port number (its 443 for the web). But I am not an YANG expert and I will let you experts decide on what would be the best way to resolve it. > > Anyway, I think you get the idea. I feel bad this is coming out in an > IESG review... > > PS: no big deal if this takes awhile to resolve, since this draft has a > normative reference to the =E2=80=9Cudp-client-server=E2=80=9D draft, whi= ch is only just > now about to enter WGLC (in the NETCONF WG). Point being is that this > draft wouldn=E2=80=99t necessarily get published any faster... > Yeah, it would have been better to catch this earlier in the document process, but looking into positive side , this is also a indication that the review process is somewhat working :-). Its great that it got flagged and we are addressing it. > > > - proxy-connect feature only refers to CONNECT method of RFC9110, but > what > about the CONNECT-UDP (RFC9298) that http clients can use to connect vi= a > proxy? Is that considered here but explicitly put out of scope? I can s= ee > HTTP/2 and HTTP/3 clients can use CONNECT-UDP method which is derived > from > CONNECT method. > > > Grrr, this is an oversight. My lame excuse is that the support for HTTP/= 3 > was added long after the proxy-support was added, and no one thought to a= dd > it... > OK, then I expect that this will be addressed in new version. > > > Your review was excellent in sussing out some long-forgotten items! > Thanks, happy to be useful. //Zahed > > Thanks, > Kent > > > > > > > > > > --00000000000053b31406204116b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 21, 2024 at 10:06=E2=80= =AFPM Kent Watsen <kent+ietf@w= atsen.net> wrote:
Hi Sarkar,

Thank you for your review!
More comments below.

Kent // as author

<= br>
On Aug 21, 2024, at 9:57=E2=80=AFAM, Zahe= duzzaman Sarker via Datatracker <noreply@ietf.org> wrote:

Zaheduzza= man Sarker has entered the following ballot position for
draft-ietf-netc= onf-http-client-server-23: No Objection

When responding, please keep= the subject line intact and reply to all
email addresses included in th= e To and CC lines. (Feel free to cut this
introductory paragraph, howeve= r.)


Please refer to https://www.= ietf.org/about/groups/iesg/statements/handling-ballot-positions/
fo= r more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/draft-ietf-ne= tconf-http-client-server/



------------------------------= ----------------------------------------
COMMENT:
-------------------= ---------------------------------------------------

Thanks for worki= ng on this complex group of specifications.

I have following comment= s/questions and I believe addressing those will improve
the specificatio= n

=C2=A0=C2=A0- May be I am failing to see the whole picture but I = understand that
=C2=A0=C2=A0draft-ietf-netconf-tls-client-server define= s tls-common module along with
=C2=A0=C2=A0tls-client and tls-server m= odules, but I don't see the Section 3.1.2.2
=C2=A0=C2=A0mentions tl= s-common module which is common to both client and server. is
=C2=A0=C2= =A0this an overlook? if not then, I would expect some description of how =C2=A0=C2=A0tls-common module is used here or not used here. ( I was init= ially thinking
=C2=A0=C2=A0of this as discuss worthy but as I am not su= re I understand how this whole
=C2=A0=C2=A0thing is used together I am = putting it as comment, and here is your chance
=C2=A0=C2=A0to educate m= e :-) )

I appreciate the op= portunity! =C2=A0:)

Let=E2=80=99s do this two ways= :

1) Looking at =E2=80=9Cuses=E2=80=9D statements<= /div>

With=C2=A0the HTM= L format, looking at=C2=A0Section 3.1.2.2,=C2=A0one notices that the tree-diagram contain= s some lines prefixed by =E2=80=9C+---u=E2=80=9D. =C2=A0=C2=A0RF= C 8340, Section 2.2=C2=A0explains that these are unexpanded =E2=80=9Cgr= ouping=E2=80=9D statements.=C2=A0 That is, the YANG module itself contains = a statement like =E2=80=9Cuses foo=E2=80=9D that appears in the diagram as = =E2=80=9C-u foo=E2=80=9D.

This diagram in particul= ar *uses* four distinct grouping statements.=C2=A0 Immediately under the di= agram there is a link to where each of grouping statement is discussed.=C2= =A0 You asked specifically about the =E2=80=9Ctls-common=E2=80=9D module, s= o let=E2=80=99s look at the "tls-server-grouping=E2=80=9D (being the o= nly grouping that resolves in the tis-client-server draft).=C2=A0 Under the= diagram, there is a line that reads "For the referenced grouping stat= ement(s)=E2=80=9D and, in this section, the third bullet point links=C2=A0<= a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-clie= nt-server-41#section-4.1.2.1" target=3D"_blank">Section 4.1.2.1=C2=A0of= [I-D.ietf-netconf-tls-client-server]
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Following that link, we=E2=80=99re now looking that the tree diagr= am for the "tls-server-grouping=E2=80=9D grouping.=C2=A0 In this diagr= am, near the bottom, you will find a line that reads "-u tlscmn:hello-= params-grouping=E2=80=9D. =C2=A0 Please note that the =E2=80=9Ctlscmn=E2=80= =9D prefix is for the =E2=80=9Ctls-common=E2=80=9D module you ask about. = =C2=A0 The =E2=80=9Chello-params-grouping=E2=80=9D is the name of a =E2=80= =9Cgrouping=E2=80=9D statement in the=C2=A0=E2=80=9Ctls-common=E2=80=9D module. We=E2=80=99re getting close=E2= =80=A6

Just below this diagram, in the "For t= he referenced grouping statement(s)=E2=80=9D section, the last bullet point= links=C2=A0Section = 2.1.3.1=C2=A0in the same document.=C2=A0 Following that link, you will = note that this section is under Section 2, which is entitled 'The "= ;ietf-tls-common=E2=80=9D Module=E2=80=99.=C2=A0 Bingo!


2.=C2=A0<= span>Looking at the =E2=80=9Cimport"=C2=A0statements=C2=A0

Whilst we started off by looking at Section 3.1= .2.2, which provides an overview of the =E2=80=9Cietf-http-server=E2=80=9D = module,=C2=A0Section 3.3= =C2=A0presents the YANG module itself.

Note that t= he first paragraph in this Section 3.3 starts with "This YANG module h= as references=E2=80=A6=E2=80=9D, with the second-to-last document being=C2= =A0I-D.ietf-netconf-tls-client-server.= =C2=A0 We=E2=80=99ll come back to this in a moment=E2=80=A6

<= /div>
Looking at the module, notice that the 5th =E2=80=9Cimport=E2=80= =9D statement is "import ietf-tls-server=E2=80=9D.=C2=A0 You may also = at this time notice that there is no import statement for the =E2=80=9Cietf= -tls-common=E2=80=9D module; that is, this module doesn=E2=80=99t import th= e tls-common module *directly*.

Now, if we were th= e follow the=C2=A0I-D.ietf-netconf-tls-client-server=C2=A0link from above= , and jump to=C2=A0Section 4.3= , which presents the =E2=80=9Cietf-tis-server=E2=80=9D YANG module, we = see that the 5th =E2=80=9Cimport=E2=80=9D statement is "import ietf-tl= s-common=E2=80=9D. =C2=A0 That is, this module imports =E2=80=9Ctls-common= =E2=80=9D *directly*, whilst the =E2=80=9Cielf-http-server=E2=80=9D module = imports =E2=80=9Ctls-common=E2=80=9D *indirectly*.


In sum, the "ielf-http-server= =E2=80=9D module indirectly imports the "ietf-tls-common=E2=80=9D modu= le but, because it is an indirect import, it doesn=E2=80=99t appear in the = body of the text in the http-client-server draft. =C2=A0 Makes sense?

Now I know what w= as my source of confution. I started from the import and in my read I looke= d upto the feature section (4.1.1) and got mixed up. Now, I know I should l= ooked into all the nested imports.
=C2=A0
Thanks for th= is excellent walk through and congratulations on becoming my mentor ( all m= y future YANG questions will be directed to you :-)) .
=C2=A0=




=C2=A0=C2=A0- Looking at Section 3.1.2.2 the quic-supported tree, I = am wondering if this
=C2=A0=C2=A0how it should be done or not. As TLS 1= .3 is ovened into QUIC, QUIC take
=C2=A0=C2=A0cares of the TLS record l= ayer, the way tls-server-parameters and
=C2=A0=C2=A0tls-server-grouping= is used would it be sufficient? may be it does, but I
=C2=A0=C2=A0dont= understand it as TLS is not used with QUIC as it is used with TCP.

This is a fair observation.=C2=A0 = I too struggle if it=E2=80=99s best.=C2=A0 In my recent interaction with Ma= rk Nottingham, I wrote the three =E2=80=9Ccase=E2=80=9D statements out diff= erently, something like this:

tcp = =C2=A0 --> =C2=A0http-over-tcp =C2=A0 =C2=A0 =C2=A0 =C2=A0 = // HTTP/1.1 or HTTP/2
tls =C2=A0 --> =C2=A0http-over-tls-over-tcp=C2=A0 // HTTP/1.1 or HTTP/2
quic =C2=A0--> =C2=A0http-= over-quic-over-udp // currently= just HTTP/3

These labels also = don=E2=80=99t sit well with me, because they don=E2=80=99t speak to HTTP-ve= rsions (e.g., HTTP/1.1, HTTP/2, HTTP/3). =C2=A0 I feel like there is a leve= l of indirection missing=E2=80=A6

For instance, no= w that we=E2=80=99re familiar with tree-diagrams (right?), it seems more ac= curate for the three =E2=80=9Ccase=E2=80=9D statements to actually be =E2= =80=9Cgrouping=E2=80=9D statements that could then be rolled into new =E2= =80=9Ccase=E2=80=9D statements as follows:

=C2=A0 grouping http-server-sta= ck-grouping:
=C2=A0 =C2=A0 +-- (http-version)
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(h= ttp11) {http11-supported}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--=C2=A0http11
<= div>=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 +-- (transport)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+-:(tcp)=C2=A0{tcp-supported}?<= /span>
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--= tcp
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 +--u=C2=A0http-over-tcp-grouping
=C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+-:(tls)=C2=A0<= span style=3D"color:rgb(0,0,0);font-family:Menlo;font-size:11px">{tls-suppo= rted}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +-- tls
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--u=C2=A0http-over-tls-over-tcp-grouping<= /span>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(http2) {http2-supported}?
=C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 +-- (transport)
=C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+-:(tcp)=C2=A0{tcp-supported}?
=C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+-- tcp
= =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 +--= u=C2=A0http-over-tcp-grouping
=C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+-:(tls)=C2=A0{tls-supported}?<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-- t= ls
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0+--u=C2=A0http-over-tls-over-tcp-grouping
=C2=A0 =C2=A0 = =C2=A0 =C2=A0+--:(http3) {http3-supported}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +-- (transport)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +-:(quic)=C2=A0{quic-supported}?
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-- quic
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--u= =C2=A0http-over-quic-over-udp-grouping

=

This seems more accurate,= but still doesn=E2=80=99t sit well with me.=C2=A0 For instance, when confi= guring an NGINX server (i.e., nginx.conf), there are =E2=80=9Cserver=E2=80= =9D stanzas that each have =E2=80=9Clisten=E2=80=9D statements, which sugge= sts something more like this:

=C2=A0 grouping http-server-app-g= rouping: =C2=A0<=E2=80=94=C2=A0note: this is an =E2=80=9Capp=E2=80=9D gr= ouping (not a =E2=80=9Cstack=E2=80=9D grouping)
=C2=A0 =C2=A0 +-- server* [serve= r-name]
=C2= =A0 =C2=A0 =C2=A0 +-- server-name =C2=A0string
=C2=A0 =C2=A0 =C2=A0 +-- listen* [trans= port port]
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 +-- transport =C2=A0enum w/ values =E2= =80=9Ctcp=E2=80=9D and =E2=80=9Cudp=E2=80=9D
=C2=A0 =C2=A0 =C2=A0 | =C2=A0= +-- port =C2=A0 =C2=A0 =C2=A0 uint16
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 +-- ht= tp-version =C2=A0enum w/ values http11, http2, and http3
=C2=A0 =C2=A0 =C2= =A0 | =C2=A0 +--=C2=A0= tcp-server-parameters =C2=A0{ if ../transpor= t =3D =E2=80=99tcp=E2=80=99 }
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 | =C2=A0 =C2=A0+=E2=80=94u tcps:tc= p-server-grouping
=
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 +-- udp-server-parame= ters =C2=A0{ if ../transport =3D =E2=80=99udp=E2=80=99 }
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0+=E2=80=94u udps:udp-server-grouping
=
=C2=A0 =C2=A0 =C2=A0 +--=C2=A0t= ls-server-parameters
=C2=A0 =C2=A0 =C2=A0 + =C2=A0 +--u tlss= :tls-server-grouping
=C2=A0 =C2=A0 =C2=A0 +-- client-a= uthentication {client-auth-supported}=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-- ...


This is becoming interesting. It would all depend = on the purpose of this grouping, right? if this is about cofiguring YANG cl= ients and servers then you would like to provide as much details at you lik= e even mentioning the HTTP versions and port numbers to run the servers on = ... but it this is about dictating client behaviours then there could be is= sues with HTTP versions as there are different ways clients picks http vers= ions AFAIK via negotiation or hardcoded.=C2=A0

Whe= n you described the last variant of potential groupping, I could see that o= ne can fold the QUIC support into UDP server grouping with specific port nu= mber (its 443 for the web). But I am not an YANG expert and I will let you = experts decide on what would be the best way to resolve it.=C2=A0=C2=A0
=
=C2=A0

A= nyway, I think you get the idea.=C2=A0 I feel bad this is coming out in an = IESG review...

PS: no big deal if this takes awhil= e to resolve, since this draft has a normative reference to the =E2=80=9Cud= p-client-server=E2=80=9D draft, which is only just now about to enter WGLC = (in the NETCONF WG). =C2=A0 Point being is that this draft wouldn=E2=80=99t= necessarily get published any faster...

Yeah, it would have been better to catch = this earlier in the document process, but looking into positive side , this= is also a indication that the review process is somewhat working :-). Its = great that it got flagged and we are addressing it.=C2=A0
=C2=A0<= /div>
=

=C2=A0=C2=A0- proxy-conn= ect feature only refers to CONNECT method of RFC9110, but what
=C2=A0= =C2=A0about the CONNECT-UDP (RFC9298) that http clients can use to connect = via
=C2=A0=C2=A0proxy? Is that considered here but explicitly put out o= f scope? I can see
=C2=A0=C2=A0HTTP/2 and HTTP/3 clients can use CONNEC= T-UDP method which is derived from
=C2=A0=C2=A0CONNECT method.

Grrr, this is an oversight.=C2=A0 My lam= e excuse is that the support for HTTP/3 was added long after the proxy-supp= ort was added, and no one thought to add it...

OK, then I expect that this will be addressed in new = version.=C2=A0=C2=A0


Your review was excellent in = sussing out some long-forgotten items!
<= br>
Thanks, happy to be useful.

//Zahed<= /div>
=C2=A0

Thanks,
Kent

=




=


--00000000000053b31406204116b1--