[netconf] Re: [IANA #1353870] expert review for draft-ietf-netconf-http-client-server (xml-registry)
Kent Watsen <kent+ietf@watsen.net> Fri, 16 August 2024 14:11 UTC
Return-Path: <010001915b87be40-a443476a-dd30-472f-a2fb-a7213dc94c7f-000000@amazonses.watsen.net>
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 40DE0C14F726 for <netconf@ietfa.amsl.com>; Fri, 16 Aug 2024 07:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 s7rHZqULqfwI for <netconf@ietfa.amsl.com>; Fri, 16 Aug 2024 07:11:49 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (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 8749EC14F69D for <netconf@ietf.org>; Fri, 16 Aug 2024 07:11:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1723817508; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=BS6mxjO1IAIq4gGRb2ndGGT+7PV9oILehM/DBhQ1csI=; b=q5KmdHIwCsJ0w4cjYqOnRUVf+Iy225lxEPS15VyqF621riQ2HTaR+mr9+yOJED7q V3AnJCTxEX3Qmwx9R4ze2xXgx8CRWVCCEs5E+mfgmceUdKPsfsnVp9bqm2PEsNoHa2X vLGivm3Cs+obCJjcokFCnVgRgs6Bp6/j0/BsqlM8=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <010001915b87be40-a443476a-dd30-472f-a2fb-a7213dc94c7f-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BEE4D316-AC3F-4FA3-B009-290D81FC3CE2"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Fri, 16 Aug 2024 14:11:48 +0000
In-Reply-To: <CAHBU6isShc-4DaowxJJW9nUuFZcumiCpeUfKL164+ahqTKRneQ@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
References: <RT-Ticket-1353870@icann.org> <rt-5.0.3-357491-1706300304-1704.1353870-9-0@icann.org> <rt-5.0.3-357490-1706301286-340.1353870-9-0@icann.org> <CAHBU6itaK-8HcRz6BCpSh8AskNRJhr-YD4J3Ca-n44gvDRbwFA@mail.gmail.com> <rt-5.0.3-371623-1706307919-293.1353870-9-0@icann.org> <rt-5.0.3-3010315-1723766803-1840.1353870-9-0@icann.org> <CAHBU6isShc-4DaowxJJW9nUuFZcumiCpeUfKL164+ahqTKRneQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.400.31)
Feedback-ID: ::1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2024.08.16-54.240.8.83
Message-ID-Hash: AISBIT2AFG4OHRLIGSCCX4263M6OLSPB
X-Message-ID-Hash: AISBIT2AFG4OHRLIGSCCX4263M6OLSPB
X-MailFrom: 010001915b87be40-a443476a-dd30-472f-a2fb-a7213dc94c7f-000000@amazonses.watsen.net
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: Amanda Baber via RT <drafts-expert-review-comment@iana.org>, Martin Thomson <mt@lowentropy.net>, "netconf@ietf.org" <netconf@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netconf] Re: [IANA #1353870] expert review for draft-ietf-netconf-http-client-server (xml-registry)
List-Id: NETCONF WG list <netconf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/AvBLqNf6FaLBHwCf5rnNhUitXgU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Owner: <mailto:netconf-owner@ietf.org>
List-Post: <mailto:netconf@ietf.org>
List-Subscribe: <mailto:netconf-join@ietf.org>
List-Unsubscribe: <mailto:netconf-leave@ietf.org>
Hi Tim,
Thanks for your review.
> On Aug 15, 2024, at 10:27 PM, Tim Bray <tbray@textuality.com> wrote:
>
> Having a look…
>
> Section 2.2, example usage, “The first example illustrates the case where the HTTP client is configured to connect directly to an HTTP server without TLS.” Umm, isn’t it a pretty fundamental IETF principle that everything should be done over secure connections these days? Makes me nervous. Especially since the URI in the example begins with “https:”
This is a brand new section added just a week ago to address a comment by Rob Wilton, who was tying up an old AD-review he’d done before.
The “https” was a copy/paste mistake, I fixed it in my local copy
- Mahesh, LMK if I should publish before Telechat on the 22nd.
Whether IETF should publish YANG modules enabling the configuration of unsecure protocols has been discussed before. I don’t 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.
In the case of HTTP/3, TLS is required. I think that this is the way. That IETF should publish secure-only protocols (and deprecate/obsolete unsecure protocols). Then the YANG modules would adjust to match.
> Same section.
>
> <!-- The outermost element below doesn't exist in the data model. -->
> <!-- It simulates if the "grouping" were a "container" instead. -->
>
> I totally don’t understand this, but maybe someone who’s a YANG expert would? I note that, in the example, if the outer “http-client” element didn’t exist, the default namespace wouldn’t be declared, and the “uri” element wouldn’t be in any namespace at all. So maybe the namespace declaration would be better right there on the “uri” 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 “usage” YANG module to wrap “grouping” statements into containers. What I’m doing here could be characterized as a shortcut.
I’m hoping that just fixing up the text would be enough to address your comment…?
By way of explanation, here’s what the behind-the-scenes validation script does to validate these examples:
printf "Testing ex-http-client-tcp.xml..."
name=`ls -1 ../ietf-http-client\@*.yang | sed 's/\.\.\///'`
sed 's/^}/container http-client { uses http-client-grouping; }}/' ../ietf-http-client\@*.yang > $name
command="yanglint -p ../ $name ex-http-client-tcp.xml"
run_unix_cmd $LINENO "$command" 0
printf "okay.\n"
rm $name
It just wraps the grouping into a container, which simulates if the "grouping" were a "container” instead.
> Aside from that, it all looks OK.
Thanks again!
Kent
- [netconf] [IANA #1353870] expert review for draft… David Dong via RT
- Re: [netconf] [IANA #1353870] expert review for d… Tim Bray
- [netconf] [IANA #1353870] expert review for draft… Amanda Baber via RT
- [netconf] Re: [IANA #1353870] expert review for d… Tim Bray
- [netconf] Re: [IANA #1353870] expert review for d… Kent Watsen
- [netconf] Re: [IANA #1353870] expert review for d… Tim Bray
- [netconf] Re: [IANA #1353870] expert review for d… Kent Watsen
- [netconf] [IANA #1353870] expert review for draft… Amanda Baber via RT
- [netconf] Re: [IANA #1353870] expert review for d… Tim Bray