Re: [netmod] Use XML namespaces in YANG document examples

Carsten Bormann <cabo@tzi.org> Sat, 12 February 2022 13:12 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29823A0770 for <netmod@ietfa.amsl.com>; Sat, 12 Feb 2022 05:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASp9FIsT5T0O for <netmod@ietfa.amsl.com>; Sat, 12 Feb 2022 05:12:36 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149823A076E for <netmod@ietf.org>; Sat, 12 Feb 2022 05:12:35 -0800 (PST)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JwrW33K45zDCbj; Sat, 12 Feb 2022 14:12:31 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <AM7PR07MB6248CCC0A25127719C516582A0319@AM7PR07MB6248.eurprd07.prod.outlook.com>
Date: Sat, 12 Feb 2022 14:12:31 +0100
Cc: "netmod@ietf.org" <netmod@ietf.org>
X-Mao-Original-Outgoing-Id: 666364350.989736-50083f34b83235e70b97c75f8da20193
Content-Transfer-Encoding: quoted-printable
Message-Id: <777EA637-849C-4B09-8BA1-2429312ACC5F@tzi.org>
References: <CAHBU6is235QT3d7q+0xhJHdtVna_9-qjGzHG_P4gnMd6nKtdTw@mail.gmail.com> <20220204.081841.166197909676487568.id@4668.se> <866e763b-88ce-ca3f-300a-7f702467fe7c@mg-soft.si> <20220204.161536.1816358672148417997.id@4668.se> <5BDB40B2-F191-41BC-92DF-BD0A94B6E992@gmx.com> <20220207200304.qhkvwrxwl5i56qqk@anna> <AM7PR07MB6248E7E96CBA846EC59C2DC4A02F9@AM7PR07MB6248.eurprd07.prod.outlook.com> <B30D2207-BE27-4E68-A9D1-3F17B0154345@tzi.org> <AM7PR07MB62480FC33CDC9A1FA31CFE26A02F9@AM7PR07MB6248.eurprd07.prod.outlook.com> <F9A842A4-DCD4-4860-BA4A-6AB341583ED4@tzi.org> <AM7PR07MB6248796A4130EA81F152886AA0309@AM7PR07MB6248.eurprd07.prod.outlook.com> <AM7PR07MB6248CCC0A25127719C516582A0319@AM7PR07MB6248.eurprd07.prod.outlook.com>
To: Robert Wilton <rwilton@cisco.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/HBrWeUWJIqn1yoxUrUAKLQp9ZzY>
Subject: Re: [netmod] Use XML namespaces in YANG document examples
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Feb 2022 13:12:41 -0000

Let me try to restate in more general terms the technical side of what Tom said:

On 2022-02-12, at 13:54, tom petch <ietfc@btconnect.com> wrote:
> 
> MUST be the same as the namespace prefix (i.e., 'nsfmi' in
>   the example) for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-
>   monitoring. 

This is confusing language.  I don’t know what “the namespace prefix for X” is.
(Of course, I know what xmlns attributes are; are these meant here?  Or the prefix declaration in the YANG that imports the module with this name?  Or the prefix declaration in the YANG of the module with this name?)

More importantly, this is a specific instance of an antipattern that needs to be stamped out:
Rephrasing requirements of a base normative reference (here: RFC 7950) in a derived specification.
This incurs a strong danger (which is NOT theoretical):

— the rephrasing may be inaccurate and thus create a fork of the actually intended general requirement of the base standard.
— the rephrasing may be misunderstood as a requirement specific to the derived standard, so implementers feel compelled to do something special for the derived standard, again creating a fork on the implementation side.

I would like to ask that we never ever do that, except possibly with a strong indication that the restatement is just a reminder rephrasing the normative requirements of the base document.  Such a restatement needs to be clearly labeled as an informational note and needs to reference the specific normative statement in the base document that it is an instance of.

More specifically, an RFC 2119 keyword is misplaced here — this is not a new normative requirement, just a factual statement about what that base standard already requires.

Grüße, Carsten