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

Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de> Mon, 07 February 2022 20:03 UTC

Return-Path: <J.Schoenwaelder@jacobs-university.de>
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 293913A07D6; Mon, 7 Feb 2022 12:03:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com
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 Y0JyIeeNRQtC; Mon, 7 Feb 2022 12:03:08 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2041.outbound.protection.outlook.com [40.107.21.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C793A082F; Mon, 7 Feb 2022 12:03:08 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MCzP4aNQhvDUuXwojtPk/16jwyB28Zcl4TkTkxRelcZvdW7D6yr9JDOqT9/1aRCWu2cbiYTNuAfFBqJqB08szQXXQ5XcYET56PVZjtP2PTXIvOmzfCoApHQ3SJr91ncXYmAU+aJtX8du5TytLB/UYso+FUvmFLt46pV4ARL+6STFs6FjjjRyP3g2mqKLUJ6gvj3FR0KUGS11Do92XC7uxcXeiiGcvi7sb7Q5NoK4j2Cw13L+C3UP2ILlrnLqdirHFUBWz6lA0YokVGGG4F3+XwBAmkgQjhjCQyBMBJmxM70aaycxCg/y7sb2a8qGsdALt92Bevg5iIOn6ScWwwrlwg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AoNej6fM5tD+6Ydn05gIzTAMMXg3IsVPL3OnXj399yQ=; b=IAHpQ/lOuCtwloShXDrD+uIvC7eWp1n4i6fqBL2dQ93vpgExYQowTb6kK88mMFXb7afMvrYuxc+hFCIei5PEY+MO7YWu84LtNsz14Lp24llD83L86KXqPE1KhribV+wRDg1zQJtW/LdLiUGou8owaPkCZQ+cl2ZFrgzLl9oh8yyAKZdClSNt7vsVgJ/ZSkKFpG+VABBGBhRZ7XsVoQwxfqnjrOma7hcuFevyEJfnmXL6mxC83Sgdo/Y1FfZo51kz9c1/+B3GtsVFOZ4PfgEETtSARLa67YFUJP3B8JTOnZ/S/21ODcVgcF35tv0DpavBO9IZn8P1RhocSgeHDAfa5Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AoNej6fM5tD+6Ydn05gIzTAMMXg3IsVPL3OnXj399yQ=; b=S212kGNLWSZ2hqBa0McRO9FvhDKDK7yTFAguXvxtozIyrv83YjAJzkDK9u6HXWeKgZLhjf161dimSmRLBMrNR1t3vPxX0g+1F9U/oXTZlD7UuRqZNXnzkOUCnewmWJWfvB97PJ5wvLfATOGIPmHfKb8NJoXkJv7e+5zYx+fWKxY=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jacobs-university.de;
Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by PRAP190MB1714.EURP190.PROD.OUTLOOK.COM (2603:10a6:102:29c::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.16; Mon, 7 Feb 2022 20:03:05 +0000
Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::ac24:5a30:ebfa:19af]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::ac24:5a30:ebfa:19af%7]) with mapi id 15.20.4951.019; Mon, 7 Feb 2022 20:03:05 +0000
Date: Mon, 07 Feb 2022 21:03:04 +0100
From: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>
To: ianfarrer@gmx.com
Cc: Martin Björklund <mbj+ietf@4668.se>, Tim Bray <tbray@textuality.com>, jernej.tuljak@mg-soft.si, dhc-chairs@ietf.org, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, netmod@ietf.org, drafts-expert-review@iana.org
Message-ID: <20220207200304.qhkvwrxwl5i56qqk@anna>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: ianfarrer@gmx.com, Martin Björklund <mbj+ietf@4668.se>, Tim Bray <tbray@textuality.com>, jernej.tuljak@mg-soft.si, dhc-chairs@ietf.org, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, netmod@ietf.org, drafts-expert-review@iana.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>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5BDB40B2-F191-41BC-92DF-BD0A94B6E992@gmx.com>
X-ClientProxiedBy: AM0PR01CA0146.eurprd01.prod.exchangelabs.com (2603:10a6:208:aa::15) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b57a6169-405b-4185-598b-08d9ea74da75
X-MS-TrafficTypeDiagnostic: PRAP190MB1714:EE_
X-Microsoft-Antispam-PRVS: <PRAP190MB1714E42CCCD1F9596A5BBAE9DE2C9@PRAP190MB1714.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: GlXqU+c+djhb8eZYWBQxPrLi2+aA0v6GcyiwZyU0ETQPN1DpNXmB9EuPLEJl5Kx/mDwIEqaJFTs7Imnjq1kWXRPYzPsyiJTd9WGT7qSwS3XqoB+3XsPSDckU5bTVJnfQUTFWVj4lldy96vHAsJgBNmzd2rvvo1YKY0p/bVDZqvilNUW1fby1n4QxZOIZYgVZDbJbdxsB/qgvu99SvZMgM9fxPtegVk4P6yKJAFsdfVCNpqEtsoA/nb7K17mzvUWoURxBmv+dTSiMr1JGOuetxgEt0JSfXIPIx0W5cdCvx2n1NdyWYPaaxa9EZAjTcJvz0bDSSSIAX0YWX6liuBXjOtWWuPb+tS1MCmXxApC8Wug6E/8DrDbh9KkugdC98hL19rF97Iu3qRUQ4sh3bDxG0T7Q4I/F7PqaIQs5UK65NODAAZUN4HIpf9Dqh+pfKJrgTwx9FyyPEO1Dw2LTMRJWDowSs0+Wpp/w5N5R6/bZ/RhMiYcYriOHPgFpRR94g0PtBYvF7ghbIjsCmuUdGWWQms/3HgUn2kG3tjnz88Pa5anQlVBqm6P9pqUDR+wx/a3+StX9qxGgyLNkymAaNV32V4sijWFxe2ZsRlaHcyV0wRdXqqRCm2q2sToCoL8ZSmqyahHmGf0UUvoXgprKWN7UagdLfoRYCkkWwNDvnV/6gCnrneNrWYMJu93csh0agJJgFhBBHOyOSifgrUTn//9UANRfbwBtfseHxQ6z+bKZsqgJb2wi8xXlV7HVkjkGUCDCZ17Cj+4lRMJfU+FWykBHiuxKVzgboSlhXs14RfkpUuLWrm2O35dUDwMpd/B34b/vczVADxpKll80IOiAg9PF2YBKP3y+n3ympRPirubrVCI=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(7916004)(366004)(86362001)(6916009)(316002)(786003)(40140700001)(66476007)(85202003)(6512007)(1076003)(85182001)(3450700001)(9686003)(54906003)(6506007)(83380400001)(8676002)(4326008)(66556008)(26005)(2906002)(186003)(66946007)(5660300002)(52116002)(33716001)(508600001)(6486002)(966005)(30864003)(53546011)(38350700002)(38100700002)(66574015)(8936002)(518174003); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: p3njjqI39TBpqpaCOcwPy/wuoxLyVicsxaNAfK1T0gVsKVFABGLVBFt9g4uYwJDeuOvVoRe0It076TFPVhYLvDRQEvhRFHLbgKU2bMKy6iYrhEtrBTDQKqO9nprcvg5Ed466sxy1UfZg+azIh60a/n6NgOCrQjXjdj5wD5USTyuASf7Shr7EIQBfotb/xmRanfLTsjO6C74xOiI2iP0/0iN0r5eIwW23OdimNhSVUJHTHhr/0wnBkON9NLK2NefFFSs+iU1asr1ZaG/yyIGlzh6UvSD/7EVAIRDFcEptk0+vi0ggsDBedVNPrB0EDuHyyZ1GX9owM/0Gm/ljK1lOrERcYJnO1vGsrTjV4Tw2QQqZ3PzymvfW+ypD21mqyFNDA8anZxG6c+YgZ+2qbYfNevFZthxz3K886i9uxGlPTIYHg7xdYhqNlnPyDzbbpKVlBBrSKAPLqoh/8WDYoOmVOesbwHb5Lv4QYoddu+M6ZDxOqyBlHcMw5gmKqM4FD2LJwoF96nI9qofkpQNbQbPy7GBN8oquxpQ8UkpwPNO/CoCOgJkVzwcNFcqKMNDv+rNnE+7RTEmwWZbT9AiiBsDQA+OLtvGEzMVZHW9wPXDPzZnA7Oa6NTioVq6n6a2EPm+mnsIXsgpN70oN0xjt9zgHOp5HyPEo8ZIj/m5j1hVO61az5QKdTyWTVTXryGwn1UFhgPibAiSchHGCvQ3nASCiVUZhlHX+yLagPT6Zj0vjWpIVdwWn/ASif32tM/oIvgVZfWl+KaSBrh56ICAu3VKTOETecOvTWd9QXmpEjd7lhWg/dsFgRPr+FnXWVqs+IgCZUUncHVlkJLxjn/w6Y/G73RfXyts+UPtMe8wvdGAIamNAnseuTXVilft3LGp589HpJDz6cjLVp/kQSx3pYNUGZRyb6UvnZWEFzm8Vw3Q6ztgL4xOtNMmHj+xmn8QnvwAfY9N/yL2pwMEz3KfjLzNoyjKVEDY5KGqGfuhh6D/YLhZQA+rmvXrIjhXSDBQF1Uq+Hv+yUwXd+GRtrcXYZYygT2ZzYoBuslB7CEmi/NiHIflzk3AUZwcoDY6bKCzX3zchA/djIuW3eAtqOVIesM+YhUblWkWG/Z4uuYChS1iTAr5j7qR4z8WfsOO3IhRElc8q9d/6+ggpI46nalOvbqPZvwS2PAif/w3ku1I+KIba4fNscTgglrkSD8fUaFFJVmSJqgEsCpE/JOlb3MkIfDqg8yViPDaXAZY1E2jhGFCsEkpuO47N58TGwCiiWo9Ir2Edi8bmSHazH8xAkkLBW8F+GslFptYDZpUG0AVFm1d0X/iXCVPdcmjCrJoCXhivmgK1DlE6Agadx/MM1SkSm4oWmiB4klzWDuOq3a4P+hsXXYRLYb/gfSU906xBiSHB0+MwCFZykcnXMHtfNJwXUHr6ABIxGBN8izXD5oR0yxld2LCHn92DDIl0KXAPw2GVA63zliZe5JHTJ8MU85p15s94BNE4u/vGubeGhxmnc59aRnwyJDKWrO7xKJfUZR4toMw+ArHwla143pu478SwpLCa0L3h94Q4YuvKBUwubprLne0bBPn/HwfsVgB37l/Oea3I2174ayM9Blv1ldnleLfjMLap7y98dVbAaO/lhPcvmc3+kATonZA0sGC0hzTv1IehK5Lp6sWCy8yKmI4xOjoNXw==
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: b57a6169-405b-4185-598b-08d9ea74da75
X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2022 20:03:05.2802 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: urLakJdhCgPpKVUrqGPCuNLZvyFmlVjkCFz62T+telycG969xq4lE2NcV37aQQCH8RtqArqHteVqPYxp+hKCBABmaapjf+pmB2IDB1IoTpQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PRAP190MB1714
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/e04QS3TNGwLaDvtk5KZOjqWhe_c>
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: Mon, 07 Feb 2022 20:03:14 -0000

While adding such a disclaimer may help you to move your document
forward (which I assume is your main priority), this looks to me like
a disclaimer added to an arbitrary YANG document for the sake of
making a reviewer happy while (i) we never did this before and (ii) we
likely have no plan to do this in the future.

If this issue is really important, then someone should write an I-D or
an errata for RFC 7950 that clarifies this for _all_ YANG modules.

Given that YANG is 11+ years old, I am not convinced this clarification
is needed, but that certainly may be a biased opinion.

Hence, my preference is to add no disclaimer and to move forward.

/js

On Mon, Feb 07, 2022 at 08:40:49PM +0100, ianfarrer@gmx.com wrote:
> Hi,
> 
> Reading back through the discussion, I think I can summarise the outcome to the following 2 points:
> 
> 1,The examples in the DHCPv6 YANG draft can keep the current use of XML prefixes (e.g. ianaift:ethernetCsmacd)
> 
> 2, In the XML examples appendix, I will change the first paragraph to read:
> 
> XML Examples for DHCPv6 Element Configuration
> 
> This section contains XML examples of data trees for the different
> DHCPv6 elements. In order for the XML data to be used correctly,
> the XML prefix must be the same as the namespace prefix. i.e, for
> The client configuration example, the characters before the colon
> (or 'ianaift:’ in the "interface/type” element content) must match the
> xmlns defined for "urn:ietf:params:xml:ns:yang:iana-if-type”. In this
> case xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type”.
> Therefore, XML software must be chosen that makes the namespace prefix
> information available.
> 
> Does this sound like the right way to proceed?
> 
> Thanks,
> Ian
> 
> 
> 
> 
> > On 4. Feb 2022, at 16:15, Martin Björklund <mbj+ietf@4668.se> wrote:
> > 
> > Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
> >> 
> >> 
> >> On 04/02/2022 08:18, Martin Björklund wrote:
> >>> Tim Bray <tbray@textuality.com> wrote:
> >>>> On Thu, Feb 3, 2022 at 10:21 AM Martin Björklund <mbj+ietf@4668.se>
> >>>> wrote:
> >>>> 
> >>>>> If an XML document has <foo xmlns:bar="...">, won't the XML processor
> >>>>> pass the attribute "xmlns:bar" and its value to the application?  This
> >>>>> should be enough even if the XML processor doesn't provide a mapping
> >>>>> table between prefix and namespace (it requires more work in the
> >>>>> application of course).
> >>>>> 
> >>>> Nope, there's no requirement that they do and some don't.
> >>> Does this mean that an XML processor might not pass attributes in
> >>> general to the application?  If so, we might have other similar
> >>> problems.  Or does it mean that an XML processor might just not pass
> >>> these "special" attributes?  If so, where is that specified?  (I tried
> >>> to find this info in the spec, but didn't find it).
> >> 
> >> Names that start with "xml" (case insensitive) are reserved by XML 1.0
> >> specification, "xmlns" in an attribute name included (2.3 Common
> >> Syntactic Constructs). They are special. There is also a guideline on
> >> colon usage within names.
> > 
> > Yes, I know.  But I can't see that the spec says that attributes w/
> > reserved names should be treated differently wrt. the application than
> > other attributes.
> > 
> >> All processors I'm aware of differentiate between attributes and
> >> namespace attributes in their APIs. What Tim is probably saying is
> >> that some XML processors either don't implement Namespaces in XML 1.0
> >> or need to be explicitly configured to become "namespace aware". If
> >> not configured as namespace aware, they might simply ignore namespace
> >> attributes therefore not passing them. If they are configured as
> >> namespace aware, they might remove prefix information and pass only
> >> "namespace : local-name" pairs where required (and that excludes text
> >> node content).
> > 
> > I guess I wonder if this is b/c the specification says so, or that
> > some implementations choose to do so.
> > 
> > 
> > /martin
> > 
> > 
> > 
> >> 
> >> Jernej
> >> 
> >>> 
> >>> 
> >>> /martin
> >>> 
> >>> 
> >>>>> I think that if special text is needed for identityref values in XML,
> >>>>> that text should go in to the YANG specification (RFC 7950).  All
> >>>>> these other drafts just follow the rules defined in RFC 7950.
> >>>>> 
> >>>> Agreed.
> >>>> 
> >>>> 
> >>>> 
> >>>>> 
> >>>>> /martin
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>>> 
> >>>>>>> Andy
> >>>>>>> 
> >>>>>>> 
> >>>>>>>> I've excerpted an email exchange with Ian Farrer that I think makes
> >>>>> the
> >>>>>>>> potential problem concrete:
> >>>>>>>> 
> >>>>>>>> Hi Ian, I don't think we've met.  I'm the grumpy person on the "XML
> >>>>>>>> Directorate" who's been whining about the namespace prefixes in YANG
> >>>>>>>> internet-drafts. One quick issue: I'm a little surprised, is anyone
> >>>>> still
> >>>>>>>> using XML in this kind of thing any more in 2021?
> >>>>>>>> 
> >>>>>>>> Anyhow, below I've excerpted the issue that's still troubling me.
> >>>>> Here's
> >>>>>>>> the XML:
> >>>>>>>> 
> >>>>>>>>  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >>>>>>>>      xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
> >>>>>>>>      <interface>
> >>>>>>>>        <name>eth0</name>
> >>>>>>>>        <type>ianaift:ethernetCsmacd</type>
> >>>>>>>>        <description>DHCPv6 Relay Interface</description>
> >>>>>>>>        <enabled>true</enabled>
> >>>>>>>>      </interface>
> >>>>>>>>    </interfaces>
> >>>>>>>> 
> >>>>>>>> So my question is, I see the XML namespace prefix and the prefix for
> >>>>> the
> >>>>>>>> <type> element content are identical. Is this a coincidence?  For
> >>>>> example,
> >>>>>>>> would the following work, changing the namespace prefix to "foo"?
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>>  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >>>>>>>>      xmlns:foo="urn:ietf:params:xml:ns:yang:iana-if-type">
> >>>>>>>>      <interface>
> >>>>>>>>        <name>eth0</name>
> >>>>>>>>        <type>ianaift:ethernetCsmacd</type>
> >>>>>>>>        <description>DHCPv6 Relay Interface</description>
> >>>>>>>>        <enabled>true</enabled>
> >>>>>>>>      </interface>
> >>>>>>>>    </interfaces>
> >>>>>>>> 
> >>>>>>>> [if - This example would not work and fails validation with yanglint:
> >>>>>>>> 
> >>>>>>>> $ yanglint --strict --verbose -t config -p $IETFYANG
> >>>>>>>> $IETFYANG/iana-if-type.yang $IETFYANG/ietf-interfaces.yang test1.xml
> >>>>>>>> err : Invalid value "ianaift:ethernetCsmacd" in "type" element.
> >>>>>>>> (/ietf-interfaces:interfaces/interface[name='eth0']/type)
> >>>>>>>> ]
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> Follow-up, would the following work, foo for both namespace and
> >>>>> content
> >>>>>>>> prefix?
> >>>>>>>> 
> >>>>>>>> <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >>>>>>>>      xmlns:foo="urn:ietf:params:xml:ns:yang:iana-if-type">
> >>>>>>>>      <interface>
> >>>>>>>>        <name>eth0</name>
> >>>>>>>>        <type>foo:ethernetCsmacd</type>
> >>>>>>>>        <description>DHCPv6 Relay Interface</description>
> >>>>>>>>        <enabled>true</enabled>
> >>>>>>>>      </interface>
> >>>>>>>>    </interfaces>
> >>>>>>>> 
> >>>>>>>> Thanks in advance!
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> [if - This does validate with yanglint, however the convention in the
> >>>>>>>> IETF examples I’ve seen seems to be to use the prefix that is defined
> >>>>> in
> >>>>>>>> the original YANG module for imports for consistency, e.g. (from
> >>>>>>>> iana-if-type.yang):
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> On Thu, Feb 3, 2022 at 8:03 AM Andy Bierman <andy@yumaworks.com>
> >>>>> wrote:
> >>>>>>>>> Hi,
> >>>>>>>>> 
> >>>>>>>>> I think the text from sec 4 refers to the usage within an
> >>>>> application.
> >>>>>>>>> The XML instance document is the on-the-wire representation and
> >>>>>>>>> the I-D example looks correct.
> >>>>>>>>> 
> >>>>>>>>> https://www.w3.org/TR/xml-names/#ns-qualnames
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> Andy
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> On Thu, Feb 3, 2022 at 3:53 AM tom petch <ietfc@btconnect.com>
> >>>>> wrote:
> >>>>>>>>>> From: netmod <netmod-bounces@ietf.org> on behalf of
> >>>>> ianfarrer@gmx.com <
> >>>>>>>>>> ianfarrer@gmx.com>
> >>>>>>>>>> Sent: 03 February 2022 09:37
> >>>>>>>>>> 
> >>>>>>>>>> Hi,
> >>>>>>>>>> 
> >>>>>>>>>> A draft I have been working on (
> >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/)
> >>>>> contains
> >>>>>>>>>> a number of XML configuration examples. During the XML expert
> >>>>> review, a
> >>>>>>>>>> question has been raised about the use of XML namespaces in these
> >>>>> examples.
> >>>>>>>>>> I’m raising it here as I don’t have the XML knowledge to answer.
> >>>>>>>>>> 
> >>>>>>>>>> <tp>
> >>>>>>>>>> 
> >>>>>>>>>> Ian
> >>>>>>>>>> 
> >>>>>>>>>> This looks like the issue I raised on this list 14jan2022 with a
> >>>>>>>>>> subject line of
> >>>>>>>>>> XML and prefix
> >>>>>>>>>> although I have not checked that the usage is exactly the same; the
> >>>>>>>>>> 'XML Expert' comment would appear to be.
> >>>>>>>>>> 
> >>>>>>>>>> Tom Petch
> >>>>>>>>>> 
> >>>>>>>>>> In my example:
> >>>>>>>>>> 
> >>>>>>>>>> <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >>>>>>>>>> 
> >>>>>>>>>>      xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
> >>>>>>>>>>      <interface>
> >>>>>>>>>>        <name>eth0</name>
> >>>>>>>>>>        <type>ianaift:ethernetCsmacd</type>
> >>>>>>>>>>        <description>DHCPv6 Relay Interface</description>
> >>>>>>>>>>        <enabled>true</enabled>
> >>>>>>>>>>      </interface>
> >>>>>>>>>>    </interfaces>
> >>>>>>>>>> 
> >>>>>>>>>> The question is related to the use of the ‘ianaift:’ prefix. This is
> >>>>>>>>>> quite commonly use in XML examples in YANG documents (e.g. RFC8344)
> >>>>> so I
> >>>>>>>>>> think the question is generally applicable.
> >>>>>>>>>> 
> >>>>>>>>>> The specific comments from the expert review are:
> >>>>>>>>>> 
> >>>>>>>>>> -
> >>>>>>>>>> For the correct processing of these documents requires that whatever
> >>>>>>>>>> XML software is being used makes available to application code the
> >>>>>>>>>> namespace prefixes.
> >>>>>>>>>> 
> >>>>>>>>>> Whilst the recommended tools (e.g. yanglint) provides this
> >>>>> function, it
> >>>>>>>>>> is not an XML best practice. Quoting from the Namespaces in XML,
> >>>>> section 4:
> >>>>>>>>>> "Note that the prefix functions only as a placeholder for a
> >>>>> namespace name.
> >>>>>>>>>> Applications SHOULD use the namespace name, not the prefix, in
> >>>>> constructing
> >>>>>>>>>> names whose scope extends beyond the containing document.”
> >>>>>>>>>> 
> >>>>>>>>>> I think that violating a SHOULD assertion in a W3C standard is a
> >>>>>>>>>> problem.
> >>>>>>>>>> 
> >>>>>>>>>> There is no requirement for XML processors to provide this prefix
> >>>>>>>>>> information, and software that (quite legally) doesn't, will not
> >>>>> work
> >>>>>>>>>> correctly with YANG documents constructed as specified in this I-D.
> >>>>>>>>>> 
> >>>>>>>>>> 1, YANG specifications should note this fact and specify that
> >>>>> software
> >>>>>>>>>> which is used to process YANG documents MUST provide an interface
> >>>>> such that
> >>>>>>>>>> applications can retrieve the prefix-namespace mappings.
> >>>>>>>>>> 2, For constructs such as <type>ianaift:ethernetCsmacd</type> the
> >>>>>>>>>> Internet-Draft should specify that the prefix ("ianaift" in this
> >>>>> case) MUST
> >>>>>>>>>> be identical to the xmlns namespace prefix representing the
> >>>>> namespace name
> >>>>>>>>>> urn:ietf:params:xml:ns:yang:iana-if-type
> >>>>>>>>>> 3, Alternately, the draft could specify that for the namespace
> >>>>>>>>>> urn:ietf:params:xml:ns:yang:iana-if-type, the XML namespace prefix
> >>>>> ianaift
> >>>>>>>>>> MUST be used. Another XML bad practice because software that
> >>>>> generates XML
> >>>>>>>>>> programmatically should feel free to generate synthetic prefixes
> >>>>> without
> >>>>>>>>>> breaking the content, but at least this would solve the problem.
> >>>>>>>>>> -
> >>>>>>>>>> 
> >>>>>>>>>> BCP216 (RFC8407 - Guidelines for Authors and Reviewers of Documents
> >>>>>>>>>> Containing YANG modules) doesn’t make any mention of how XML
> >>>>> namespaces
> >>>>>>>>>> should be used, only that example XML/ JSON should be included and
> >>>>> that
> >>>>>>>>>> these examples need to be validated (pyang and yanglint are
> >>>>> mentioned for
> >>>>>>>>>> this).
> >>>>>>>>>> 
> >>>>>>>>>> Does this guidance need to be updated to reflect expert review
> >>>>> comments
> >>>>>>>>>> above?
> >>>>>>>>>> 
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Ian
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> netmod mailing list
> >>>>>>>>>> netmod@ietf.org
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>>>>>>>> 
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >> 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 

> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>