[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 16:19 UTC

Return-Path: <010001915bfc9a7b-1f811384-4abb-4b47-9a28-6eb1521393be-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 C8E2BC14F6E4 for <netconf@ietfa.amsl.com>; Fri, 16 Aug 2024 09:19:28 -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 n5ociin7J9Th for <netconf@ietfa.amsl.com>; Fri, 16 Aug 2024 09:19:28 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (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 0BFECC14F6B8 for <netconf@ietf.org>; Fri, 16 Aug 2024 09:19:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1723825167; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:Feedback-ID; bh=XY0a7XjACJlVzH/3Lq3dLRxat6OibNBqRSSyCl+gCFg=; b=bz7P4u59SVw61HLXYIFZpq8syvIMDYulsr8f2G2pFGRDx/x5KuduNo/pYFJxIBIJ Ufb4jTzayllmRLK309duQjXHWufR8ypSx6VXHYvXsiJXZqyGO4B5rl4iG8ZpVeX7v9J 1aQ3QymGF3e+/FJ7q+kL11tYllf2X7fxk6nJ1zvA=
Content-Type: multipart/alternative; boundary="Apple-Mail=_46915D4B-3BB0-4FDD-99D9-4C0FE0C2D19C"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <CAHBU6iu7u35uTFo72QQmFH8RbfVmSGs=ukQ-Q-p2wXDey36NgQ@mail.gmail.com>
Date: Fri, 16 Aug 2024 16:19:26 +0000
Message-ID: <010001915bfc9a7b-1f811384-4abb-4b47-9a28-6eb1521393be-000000@email.amazonses.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> <010001915b87be40-a443476a-dd30-472f-a2fb-a7213dc94c7f-000000@email.amazonses.com> <CAHBU6iu7u35uTFo72QQmFH8RbfVmSGs=ukQ-Q-p2wXDey36NgQ@mail.gmail.com>
To: Tim Bray <tbray@textuality.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.88
Message-ID-Hash: 7D35IZZMQKWSBWBS3RR4JHVXXKLDWEFY
X-Message-ID-Hash: 7D35IZZMQKWSBWBS3RR4JHVXXKLDWEFY
X-MailFrom: 010001915bfc9a7b-1f811384-4abb-4b47-9a28-6eb1521393be-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: "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/dlnEcO8j0U4ko-czwHRXOob60mo>
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>

[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’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.  
> 
> This implies that YANG is frequently interchanged on insecure plain-text channels? Eek, didn’t know that. If I were on the IESG I’d be very negative about this, but I’m not. I’ve made my point, if nobody else is upset then you’re 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 “http” in the general case, it is not allowed in the specific case.



>>> <!-- 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.
> 
> First of all you’re using the words “grouping” and “container” and I don’t understand what they mean in this context. Is this standard YANG terminology? If so, then OK I guess. 

Yes, “grouping” and “container” are standard 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 “Assume that the default namespace has been mapped to XXX in some containing element”, or
> Put the namespace declaration right on the contained <uri> element then you don’t 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 “uri” line.  Yes, the namespace could appear in each, but it wouldn’t be not nice.

 
Kent