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 15374C1DA2E5 for ; Tue, 20 Aug 2024 10:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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, 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_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 (1024-bit key) header.d=textuality.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 1frNcCP2AMlT for ; Tue, 20 Aug 2024 10:22:53 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 18EA3C1DA1FA for ; Tue, 20 Aug 2024 10:22:47 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-7163489149eso4221568a12.1 for ; Tue, 20 Aug 2024 10:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality.com; s=google; t=1724174567; x=1724779367; 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=tK45KWEk9pg4eLtSRy2n/b4Px5C8ldZLf9mucQKp300=; b=OMIFTJb4vCnmsa/QHqTTnYXUpElKLau5GZThBy4qz5INmVQun/6/DI/LhlaSw+EDtu kwv7dRjK10DX9BMThXNHSYOJ9b8Wh8hUKa2F8Of4PtREiS+5Zvq5Y1YSz5TjSfWHwcPk OgWWXrrFnl9poIhbr5XefDTIOOR4PhDANkFQc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724174567; x=1724779367; 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=tK45KWEk9pg4eLtSRy2n/b4Px5C8ldZLf9mucQKp300=; b=xUH7sXiDtlD3HzN5CFZtvtY1axsTx3A1iWXz1oAV6qiT9Hnsmef3qg8FemzAVV3wrm V8ixavy4zdK2nD9QzhRHUXCvsIWA3zh1o9NDI1MysIaPmB3k9ZMFF6K1hbxRbC0y8FFF 1ZPASXJe2Xpd3G8prVpcr+b4SN4MTWNslKefYvbVYY/zST1nvr2pJknpxzR0LdKZ5qsO yEegOHMVciRj5lU+9h1X82iKr+gxRqf/zQoKGBNatnXYHZEC7EZ2dUc4yZANCc3hZLjC b/g0YUY9osUUSkWJSj0chmeMbLCWeyMSUY5sw6iO2OZbZYdUGAO7ZAhNNiOnt9y0/5qn ijXQ== X-Forwarded-Encrypted: i=1; AJvYcCUu6YvH4ndSb8/Zb9g3+yhoP63KWeYBEPeB4OPuyNZUkXioWUSPfhynhrvE+bHpQ5vT2SLJjZ0t@ietf.org X-Gm-Message-State: AOJu0YxEwdfcpkOywO8Ako0sApCX8WDmrpx45JsZ5i7UWqR1wHPCIBfT TWYaMw69oqmn9vnxq0l77WtoHUflI9j5jxV+d+fZXtgvSKMJAKPcT7zuwLeKtSDYYSo6hhesAdU T0oa3f2jMeKfwVbnwXp6tkSHk2kd4q71SG+9EpQ== X-Google-Smtp-Source: AGHT+IEbHvLUEY1EBTUueKmiJngnRYT55p6HQOtmujgFPnDBrs+GCGXj49hMITYrGy+nkgVcIsTPBm/NbHK8vZt5QFg= X-Received: by 2002:a17:90a:3e85:b0:2c8:f3b7:ec45 with SMTP id 98e67ed59e1d1-2d3e03f93b2mr15821542a91.36.1724174567180; Tue, 20 Aug 2024 10:22:47 -0700 (PDT) Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Aug 2024 13:22:46 -0400 Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Aug 2024 13:22:43 -0400 MIME-Version: 1.0 (Mimestream 1.3.7) References: <010001915b87be40-a443476a-dd30-472f-a2fb-a7213dc94c7f-000000@email.amazonses.com> <010001915bfc9a7b-1f811384-4abb-4b47-9a28-6eb1521393be-000000@email.amazonses.com> In-Reply-To: From: Tim Bray Date: Tue, 20 Aug 2024 13:22:46 -0400 Message-ID: To: drafts-expert-review-comment@iana.org Content-Type: multipart/alternative; boundary="0000000000009bb136062020ac63" Message-ID-Hash: RQEUEZJFZB6PMK42ZWSIRJ4GCHI232S5 X-Message-ID-Hash: RQEUEZJFZB6PMK42ZWSIRJ4GCHI232S5 X-MailFrom: tbray@textuality.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: mt@lowentropy.net, netconf@ietf.org X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bnetconf=5D_Re=3A_=5BIANA_=231353870=5D_expert_review_for_draft-?= =?utf-8?q?ietf-netconf-http-client-server_=28xml-registry=29?= List-Id: NETCONF WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000009bb136062020ac63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Aug 20, 2024 at 10:20:50=E2=80=AFAM, Amanda Baber via RT < drafts-expert-review-comment@iana.org> wrote: > Hi Tim, > > This is on Thursday's telechat agenda. Can you let us know before then > whether we should ask an AD to hold DISCUSS? > My comments are on the record. I suspect not, it=E2=80=99s just slight awk= wardness in the description, very XML-specific. But not my call to make. > thanks, > Amanda > > On Fri Aug 16 16:19:51 2024, kent+ietf@watsen.net wrote: > > [moving Amanda and Martin to BCC] > > > Hi Tim, > > > >> Whether IETF should publish YANG modules enabling the configuration > > >> of unsecure protocols has been discussed before. I don=E2=80=99t know= if a > > >> definitive resolution came out of it, but my understanding is that > > >> IETF YANG modules should support widely-deployed infrastructure. In > > >> particular, protocols that are current or deprecated, but never > > >> protocols that are obsolete. > > > > > > This implies that YANG is frequently interchanged on insecure plain- > > > text channels? Eek, didn=E2=80=99t know that. If I were on the IESG I= =E2=80=99d be > > > very negative about this, but I=E2=80=99m not. I=E2=80=99ve made my poi= nt, if nobody > > > else is upset then you=E2=80=99re probably fine. > > > This draft specifies YANG for just the HTTP protocol layer. This > > config can be mixed-n-matched with the YANG from other protocol layers > > to create the configuration for a protocol stack. > > > FWIW, the RESTCONF protocol sits on top of HTTP, but profiles it by > > mandating mutual authentication. So whilst this YANG allows =E2=80=9Chtt= p=E2=80=9D in > > the general case, it is not allowed in the specific case. > > > > > >>> > > >>> > > >>> > > >>> I totally don=E2=80=99t understand this, but maybe someone who=E2=80= =99s a YANG > > >>> expert would? I note that, in the example, if the outer =E2=80=9Chtt= p- > > >>> client=E2=80=9D element didn=E2=80=99t exist, the default namespace w= ouldn=E2=80=99t be > > >>> declared, and the =E2=80=9Curi=E2=80=9D element wouldn=E2=80=99t be i= n any namespace at > > >>> all. So maybe the namespace declaration would be better right there > > >>> on the =E2=80=9Curi=E2=80=9D element? > > >> > > >> This is a fair comment. There are four examples in the draft that > > >> follow this convention. FWIW, in other drafts I sometimes create a > > >> dummy =E2=80=9Cusage=E2=80=9D YANG module to wrap =E2=80=9Cgrouping=E2= =80=9D statements into > > >> containers. What I=E2=80=99m doing here could be characterized as a > > >> shortcut. > > > > > > First of all you=E2=80=99re using the words =E2=80=9Cgrouping=E2=80=9D = and =E2=80=9Ccontainer=E2=80=9D and I > > > don=E2=80=99t understand what they mean in this context. Is this standa= rd > > > YANG terminology? If so, then OK I guess. > > > Yes, =E2=80=9Cgrouping=E2=80=9D and =E2=80=9Ccontainer=E2=80=9D are stand= ard statements in YANG. > > > > > If not, please explain what you mean. I guess the only purpose of > > > the outer element is to carry the namespace declaration? If so, you > > > could either: > > > > > > Say =E2=80=9CAssume that the default namespace has been mapped to XXX i= n some > > > containing element=E2=80=9D, or > > > Put the namespace declaration right on the contained element > > > then you don=E2=80=99t need any extra apparatus. > > > > > > Or maybe something else. > > > Suggestion #1 is doable. Anyone on the list have ideas? Is the > > existing text bad? > > > Suggestion #2 is not so doable, because the other examples have many > > more lines than just the =E2=80=9Curi=E2=80=9D line. Yes, the namespace = could appear > > in each, but it wouldn=E2=80=99t be not nice. > > > > Kent > > > --0000000000009bb136062020ac63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Aug = 20, 2024 at 10:20:50=E2=80=AFAM, Amanda Baber via RT <drafts-expert-review-comment@iana.or= g> wrote:
=20
Hi Tim,

This is on Thursday's telechat agenda. Can you let u= s know before then whether we should ask an AD to hold DISCUSS?

My comments are on the record.=C2=A0 I suspect not, it=E2= =80=99s just slight awkwardness in the description, very XML-specific. But = not my call to make.=C2=A0


thanks,
Amanda

On Fri Aug = 16 16:19:51 2024, kent+ietf@watse= n.net wrote:
[moving Amanda and Martin to= BCC]

Hi Tim,

>> Whether IETF should publish = YANG modules enabling the configuration
>> of unsecure protocols has been discussed before.=C2=A0 I d= on=E2=80=99t know if a
>> = definitive resolution came out of it, but my understanding is that
>> IETF YANG modules should suppor= t widely-deployed infrastructure.=C2=A0 In
>> particular, protocols that are current or deprecated, b= ut never
>> protocols that= are obsolete.
>
> This implies that YANG is frequently in= terchanged on insecure plain-
&g= t; text channels? Eek, didn=E2=80=99t know that. If I were on the IESG I=E2= =80=99d be
> very negative ab= out this, but I=E2=80=99m not. I=E2=80=99ve made my point, if nobody
> else is upset then you=E2=80=99re= probably fine.

This draft specifies YANG for just the HTTP pro= tocol layer.=C2=A0 This
config c= an be mixed-n-matched with the YANG from other protocol layers
to create the configuration for a protocol s= tack.

FWIW, the RESTCONF protocol sits on top of HTTP, but prof= iles it by
mandating mutual auth= entication.=C2=A0 So whilst this YANG allows =E2=80=9Chttp=E2=80=9D in
<= /blockquote>
the general case, it is not allowed = in the specific case.



>>> <!-- The out= ermost element below doesn't exist in the data model.
<= blockquote type=3D"cite"> >>> -->
>>> <!-- =C2=A0It simulates if the "grouping= " were a "container" instead.
>>> -->
= >>>
>>> I tot= ally don=E2=80=99t understand this, but maybe someone who=E2=80=99s a YANG<= br>
>>> expert would?=C2=A0= I note that, in the example, if the outer =E2=80=9Chttp-
<= blockquote type=3D"cite"> >>> client=E2=80=9D element didn=E2=80= =99t exist, the default namespace wouldn=E2=80=99t be
>>> declared, and the =E2=80=9Curi=E2=80=9D = element wouldn=E2=80=99t be in any namespace at
>>> all. So maybe the namespace declaration would = be better right there
>>&g= t; on the =E2=80=9Curi=E2=80=9D element?
>>
>> Thi= s is a fair comment. =C2=A0=C2=A0There are four examples in the draft that<= br>
>> follow this convention.= =C2=A0=C2=A0FWIW, in other drafts I sometimes create a
>> dummy =E2=80=9Cusage=E2=80=9D YANG module = to wrap =E2=80=9Cgrouping=E2=80=9D statements into
>> containers.=C2=A0 What I=E2=80=99m doing here c= ould be characterized as a
>&= gt; shortcut.
>
> First of all you=E2=80=99re using the wo= rds =E2=80=9Cgrouping=E2=80=9D and =E2=80=9Ccontainer=E2=80=9D and I
> don=E2=80=99t understand what the= y mean in this context. Is this standard
> YANG terminology? If so, then OK I guess.
<= blockquote type=3D"cite">
Yes, = =E2=80=9Cgrouping=E2=80=9D and =E2=80=9Ccontainer=E2=80=9D are standard sta= tements in YANG.


&g= t; If not, please explain what you mean.=C2=A0 I guess the only purpose of<= br>
> the outer element is to car= ry the namespace declaration? If so, you
> could either:
&g= t;
> Say =E2=80=9CAssume that= the default namespace has been mapped to XXX in some
> containing element=E2=80=9D, or
=
> Put the namespace declaration right on the = contained <uri> element
&g= t; then you don=E2=80=99t need any extra apparatus.
>
> Or= maybe something else.

Suggestion #1 is doable.=C2=A0 Anyone on= the list have ideas?=C2=A0 Is the
existing text bad?

Suggestion #2 is not so doable, because t= he other examples have many
more= lines than just the =E2=80=9Curi=E2=80=9D line.=C2=A0 Yes, the namespace c= ould appear
in each, but it woul= dn=E2=80=99t be not nice.


Kent

--0000000000009bb136062020ac63--