[netconf] Re: [IANA #1353870] expert review for draft-ietf-netconf-http-client-server (xml-registry)

Tim Bray <tbray@textuality.com> Fri, 16 August 2024 15:08 UTC

Return-Path: <tbray@textuality.com>
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 F0C7AC14F6B4 for <netconf@ietfa.amsl.com>; Fri, 16 Aug 2024 08:08:31 -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, 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 (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 mZqX2nUivXxa for <netconf@ietfa.amsl.com>; Fri, 16 Aug 2024 08:08:27 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 D1D63C14F6E4 for <netconf@ietf.org>; Fri, 16 Aug 2024 08:08:27 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-7c6b4222fe3so1325215a12.3 for <netconf@ietf.org>; Fri, 16 Aug 2024 08:08:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality.com; s=google; t=1723820907; x=1724425707; 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=cyKU4UR2d2MEMDbLTuqAMQW4QYGYKcc5JrRSqNXsWco=; b=aDaXOz+EN1v3DtU7eQbR8NyjspCxU2ur9e6uVy5lSUvR515ic9idNly4yQa6Cs7uFq VHpZSbskD5B72pxlESu/APohy8BBVepibhZV+AlLmTiS+YkbONDLIqA94e/7PsZFrOUf BeqICQo9+/MzKB6PffdyolQiRLvfkBj9pz/pc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723820907; x=1724425707; 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=cyKU4UR2d2MEMDbLTuqAMQW4QYGYKcc5JrRSqNXsWco=; b=cKge/MOxoi2EuL4z7+hKMJux0iaTYDJzpM/GDHW4gkJDNaPNheUzdE6QpPeZgFsDxS eeLiWTY95Xfwan1doUdR2w2EeVbxztIMNRhAIK8vZLQ/aTeVbifdKhwLVSczT3zwz89I QZpLmjht1Maa19sPES6Uxa5Sxzt5ec8ipY7h/Kobsk8j7fLObYBCC7neWXbjf6qUj6VL lGVQ/5xR7a5t+tzB9eK+omkQ30r/VRx6HqeRIx9htNi532OF19Gj04ioViLsthGAheY1 2qpRrLgRSnZN2wc+JK+Fr3NSy8QhwD1nX9TNbPsdtIKr75J0HfFJaQSRPAb2QvRvPXGq kz8w==
X-Forwarded-Encrypted: i=1; AJvYcCWPsc0gdhtw74nqiL8LtWO8+Gtl8Q/qNjovGmw6AWqUaib5IjZp9dFGj8AvjjpyMOPRV5EfArVmifo4gmU3yvz9
X-Gm-Message-State: AOJu0Yx4om/xAFv1qjZ7UCBHesZwFEayGlljR/na/abRe+wD4pOoCZD1 VqMAYp6mCFmi32xHikM3WdfYfLYNmjhfHu7n5Aa7fd17Fw6g4OLLjoVwM6PQtaDGEm7XRLj4/lf Mz8+Mf7wTRSCMOHXACeOVfebr8pXHCk9ZlREokQQOmfqga2oP
X-Google-Smtp-Source: AGHT+IEbLVbK/B6FQD62n7PSW5/soK2QjgYll3UQwlKhG60iHwdB+B0SMZfEar7qZ/Bn2KZ6jQEhZksvi1NDv/A4gsQ=
X-Received: by 2002:a17:90b:4d8f:b0:2d3:da82:28e0 with SMTP id 98e67ed59e1d1-2d3dfc37993mr3260001a91.9.1723820906936; Fri, 16 Aug 2024 08:08:26 -0700 (PDT)
Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Fri, 16 Aug 2024 10:08:26 -0500
Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Fri, 16 Aug 2024 08:08:22 -0700
MIME-Version: 1.0 (Mimestream 1.3.7)
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>
In-Reply-To: <010001915b87be40-a443476a-dd30-472f-a2fb-a7213dc94c7f-000000@email.amazonses.com>
From: Tim Bray <tbray@textuality.com>
Date: Fri, 16 Aug 2024 10:08:26 -0500
Message-ID: <CAHBU6iu7u35uTFo72QQmFH8RbfVmSGs=ukQ-Q-p2wXDey36NgQ@mail.gmail.com>
To: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="000000000000d09a7c061fce5454"
Message-ID-Hash: REZ2BYGCX4QXUPNVSCCKTN4E5LRAUEYX
X-Message-ID-Hash: REZ2BYGCX4QXUPNVSCCKTN4E5LRAUEYX
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: 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/HWgHNL74SzxRW3srRzPL1lOW0_Y>
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>

On Aug 16, 2024 at 7:11:48 AM, Kent Watsen <kent+ietf@watsen.net> wrote:

>
> 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.

<!-- 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.  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:


   1. Say “Assume that the default namespace has been mapped to XXX in some
   containing element”, or
   2. Put the namespace declaration right on the contained <uri> element
   then you don’t need any extra apparatus.


Or maybe something else.