Re: [netmod] [yang-doctors] YANG 'when' with absolute path

tom petch <ietfc@btconnect.com> Fri, 04 February 2022 09:53 UTC

Return-Path: <ietfc@btconnect.com>
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 271003A1356; Fri, 4 Feb 2022 01:53:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 rdK-uTKUgaEc; Fri, 4 Feb 2022 01:53:17 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::729]) (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 891253A1358; Fri, 4 Feb 2022 01:53:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iFX1SV9H22PB8KnHBohVb0H8xd5NBtIHPDWvMgoCfkYPnEAaHiEGof5JiyyX+X3BSxX4aA+s3lPTGpCMkz5N18W0GWagn28ydtJVjQ+sSQhJimVDu3pGnRuIt8GkRQO6+qNo0sIKokkKWcrUDGv+K8yoSjfaSel8clQfTIcQyDWRrY0T95cSAPMwztGaFf8PR3lNABZ5mLXG9+idTE7tOjzs3589Iv1pgH+3ogJrlzsQLuO6sVVvyqgtT7iq/bI6mfJ5NHeXIzViCzI2mh5B8WxGTQuz2BOesVkn0q6W5im5Hn32LXfesg4y/8h5+ym2Jao0rO/CnJMCNkQXzipzNw==
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=Z1ofjHTC/gG8Iabyv3SIcEnQh3tBvGeh2oeMN7WGlDE=; b=NblQt3QWhSSmuxkO3vSNpJQjxPjBaymo3FrFFUSpW2tdDMMwmsylr/2i+LMHoCrioUN6mHv6F08sv5Uvpte3MfmAH1TjAEeq/8876piA3vAsWdQRutlJ7EZI4ZiK7YbEy2oT7aWHzp+JrJsqiKkLl+1ScOq4HwdmLoL+A9yBnBHfN8XlMlcqtYE+zjMNB0qXf3yVUwEtvHdmTWcPvD3ba6h+d6Bsbqeq11iWP9TFEzLj28J6A1QGzw8+ak1A6Nw2zcTnHWsWHzGZz7o2bRTJahQLDVM6UyLj5/OuEy72saDwP0WL4ILhi69R5MxatpDeDnpAZJe3gaTTzN7r+/T+3A==
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=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z1ofjHTC/gG8Iabyv3SIcEnQh3tBvGeh2oeMN7WGlDE=; b=F8ylvfnXW8BcRX4W7LcNW8xhCRP/Xmeeh1Vn2X8Sgnd4AI8IvkiOuWj/PiHNTswzeVFVko0RWGCK2lfgkIK90rizr2SoSuhhfjsYb4nOEl5irusoRYEWHsn7udJg8gatCf0t4A0QTTcI1Cum0Gcf08Qjv1mzEASTUgM0q+Qrv/c=
Received: from VI1PR07MB6256.eurprd07.prod.outlook.com (2603:10a6:800:133::7) by PA4PR07MB7390.eurprd07.prod.outlook.com (2603:10a6:102:cf::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.10; Fri, 4 Feb 2022 09:53:11 +0000
Received: from VI1PR07MB6256.eurprd07.prod.outlook.com ([fe80::b887:2ae9:2a3:298]) by VI1PR07MB6256.eurprd07.prod.outlook.com ([fe80::b887:2ae9:2a3:298%5]) with mapi id 15.20.4951.014; Fri, 4 Feb 2022 09:53:11 +0000
From: tom petch <ietfc@btconnect.com>
To: Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <ladislav.lhotka@nic.cz>
CC: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, Italo Busi <Italo.Busi=40huawei.com@dmarc.ietf.org>, "draft-ietf-ccamp-flexigrid-yang@ietf.org" <draft-ietf-ccamp-flexigrid-yang@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] [yang-doctors] YANG 'when' with absolute path
Thread-Index: AQHYGH5c+6sS5mjPeEG+RP8YxuxSf6yDJ3GD
Date: Fri, 04 Feb 2022 09:53:10 +0000
Message-ID: <VI1PR07MB6256496ACB4DD1F5AEED0764A0299@VI1PR07MB6256.eurprd07.prod.outlook.com>
References: <010ba32d4f934498be4a032b864a65bc@huawei.com> <49b-61e66700-61-555dec00@38936218> <150e7ecee5d24bbb9ddc77cf7c71929d@huawei.com> <7EA67782-7510-48B4-926B-474C99056C22@tail-f.com> <87mtj9ppe1.fsf@nic.cz> <16E2374B-329F-41D9-993F-572ACEF74CEB@tail-f.com> <14308fa8-1e66-0925-01e3-b742ed804046@nic.cz> <CABCOCHQqATdb_mw2fEQSE7NoOhh1ENj25CdCDreC3kB2FUPwMA@mail.gmail.com>
In-Reply-To: <CABCOCHQqATdb_mw2fEQSE7NoOhh1ENj25CdCDreC3kB2FUPwMA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
suggested_attachment_session_id: 3273ea15-2225-786f-b8e9-b30c798c2a3a
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 51074f11-580c-45fb-a314-08d9e7c42763
x-ms-traffictypediagnostic: PA4PR07MB7390:EE_
x-microsoft-antispam-prvs: <PA4PR07MB7390FD76AD22D43D437FFCF9A0299@PA4PR07MB7390.eurprd07.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: 7RXPKoBblhcxSlrjEU0eecDdBHqF7q4j156xx724mJgvlMxAw2QOPdBcGPX2EtfFjmFIjU82uGip40dXBbTMfwpnfHS+a6VBzTsAHAlKUhmTlyeYBNyqvN6UR60oniZg8CxQfBbOGYLXpnbkwQyZCniIncgJVmrxyA8e4XLZ8hGppLtLkphd1nxM9ehW8h5ACzD3LMHGfBZb+Md0cLS2e7JhMY5atjM/BO9f0F5ZLSo5WpgPzLMFnpDqqVDw+k3fR2jrTmK43JCqvQi1d/CWJKZjvWiCyeCUMRNKzFtfcCbNbooyyU0eVejTOZApjCW7jl+vxO0UyD4a7fUB62DNdkicsip1dlQay2X8VsLm0p9+oIVEeWul7vq2w0bdLXwMa0iMNAsKeaYo0Zh4enwzZQEaG06HUxBIFj6Xyz+9xKmhpW4Q+T2NhwWLXBOJ2ti0xx3bHOaUZRM4YXrIrQyHXTElyhBgUkTZ2ejza3nvg3vBMVY5TzQaojabL/OrZuXov0XfA5NUJuRUcKDLLaKp12/NRg6jR7gAh8LJXrRK+lZxU5aC/tqwlL8VHdLpy2/N7YjjC7TU4tfg/7qwQ8Zcwrslf6vTf1HNeHjSEItmSr/TMLeW6h1oyZM/lxAkF7VUnRrQE8kbWnGeSo69WlYngTH9gHs1q0y8BUNbae6dMjc7YmXfROc/GTj62C6Ngf7egWeNoJ1d8XXAROL3LNc1N6F8H6v5v8bwtsO9k1u3GfTH3EFhLRi9tGUtA23uiPBa4isu1rEyItUFkf8lASkXMayI4xBvZ8JT0YEgG8ZRK/g=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6256.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(38100700002)(82960400001)(33656002)(55016003)(508600001)(86362001)(5660300002)(8676002)(4326008)(71200400001)(8936002)(2906002)(83380400001)(186003)(26005)(54906003)(110136005)(53546011)(966005)(316002)(7696005)(9686003)(64756008)(66446008)(66476007)(66556008)(66946007)(122000001)(91956017)(6506007)(76116006)(52536014)(38070700005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: lVFzdeaZ8LYzJ9IkUVqcjjHyOnfgMJl+NMA1J59wGVUBV5gSNMwsrtj6n7x+UGBKdQsbEcwpcBDm166Jzv7Snh5SSVQFxpGKr7r18GByejHh9XuDyoTavGQYYqd1YouCkRK3CNIbvI0pwmuwma0BIzqm8Z0G412GHJnwUhJSNoVvaIYREA/EfAGT7MSyRb4ohtZcr4tjlobvlZ/f28Cshgy7OIZY8skhqKQxxWeHpISk33gGZqlSHuoaB/rGj5vHuSu3Lc9O4yyNA1bFX2UpsQgHeHKAGJh/uM6w1UhE+2KGVevWhL8KUiUJ+Lnh9TVRYAhi7hHWe5+iNmo7EtrjWGFzeSBZbU4zRiocoQSU9Z1se+qygF4dKdW7zaPGoIRTSbP/J/fOqfKlTGYzcZ/7RleXCWtKrSa+bJPj5s6kRYmSlQaPk9S4eCDjMNoPLyLdmBV04IiDJw7/QWeBsPi8O5N1OJg+XBhgM09GoInAmd/tnOY15+IyMIqw3IHfm/VzW7arCLvDiqVqcTvFplW/UCMKiD6VKuFEpLQMok5kCJ4UBbeAjxXp9HjIsd+MJ5ebSlY9hYERufhISdQWd0bNGF9u1oI3WjppDH5crBNP7upHBTBQSgUvYy1gyqyiEx31gJKt3DgJ+PAgBBsM48Rn9+qhrDLODec626zDVYJhRWiBdYOj/6l0kr22U+xCsb4ae0od6ZV5KUYcWMpaDgQmRbHsNFf7Y5Z+9pBZgI0m4JJ8g/bDM+07y+geltnzI+4ASv7KYCz5Beuc5/S+ItcC4dGE3c0n9upbJBp6JP5Z0fCriOS7Jrlmrx2WP9BJJgkI8Zofup5EGj8OnuIMwzqPaYbGwh0Vn5ncwNbLuHnbPnMuM+eS390DjGjxb81vhiCYh89EAoWSm0k/qSaPcsLvynmucL9i2AMPyQiucRyNMZ6fkN50j8HULWYfNtQReEBWPoubrqPwQYcxxEe1qvGX1dFbL/+eRzu3z06VefPhKIVJBbeMJYGmqK8pq++/SYndZRWMQc1dzQBhGHqtFG4DxKPc/JxezyJQ+PLaZBXBt7TrScXwQll7XRzPsg/WgcAYCOhDx4duRXs4GiJpL6H5iLYEcqrjbuZujnOChBvLPX92zR+fWi4usfzuGP6BtEGAvnnZGOrnKtnXPflFbPOSzgWC5mtb4gtTBy9kMXoqqKFb+uX/BLcpfjTdShAT/yoqe2qX3Q+VnT+XJFNM42K14pgTqQoC3D2Z+LqGzenjzAiwGQkJX4Ek1545ZvaedamnfMzEGJrks4C/5c5b9biqUDxkpPSc2nl5NpToNKBNcDqKv6ujuOZ/x+Bo04e5L9z7tGrDcbg70VNl3s+NDlgm/Ru1yUNh64Dgojp96o1Kpvs22swwQDshSWDrWXTPFfYo7b7ahwcqO3pR49X2rmld70fte5LUeQySkBFW4c7KeQyswslR8ZzcTLtQW58NJ516suwUFPNtSD8IkuAmN5+KlivGZ2QV4iKV2KsYh99tkBfQP340ZjvC4cXni5Xuqj/Bp4iVx560Ou/x1iJeKYvw50ux0NRtQjQpPa7yRmvU+EYlHZlyPSA2tsrRL6jVVXusUsguo0gbCKWs0r7SSXYc0A==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6256.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 51074f11-580c-45fb-a314-08d9e7c42763
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2022 09:53:10.8521 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XxQyNuxT5s5F9ExUT8yQDaXpRXKnZPqO9LQfMXa+y24tFHONJdExiwnI6ugQ1nO8fouseq0IC0B2IJ8i0bX20w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR07MB7390
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/e8M55d5yO2mbzAf85yGk58zkluw>
Subject: Re: [netmod] [yang-doctors] YANG 'when' with absolute path
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: Fri, 04 Feb 2022 09:53:22 -0000

From: netmod <netmod-bounces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com>
Sent: 02 February 2022 21:46

<tp>
Agreeing with Andy, Lada and so on but adding a contextual note.

This augment/when construct is widely used in TEAS and CCAMP modules, of which there are a very large number, and in any one module, the augment/when can appear over 100 - yes one hundred - times because of the way that the base module that is being augmented has been structured so the potential gain in simplicity, readability is considerable.

Tom Petch



On Wed, Feb 2, 2022 at 2:41 AM Ladislav Lhotka <ladislav.lhotka@nic.cz<mailto:ladislav.lhotka@nic.cz>> wrote:
On 02. 02. 22 11:15, Jan Lindblad wrote:
> Lada,
>
>>> While I agree that tools are easier to update than WG documents, and
>>> that a broken yanglint isn't a strong reason to avoid the proposed
>>> axis construct, I do think it will have a cost. In current YANG
>>> practice, XML axis constructs are esoteric, and many implementations
>>> will either not support it, or have not been tested properly in this
>>> area before. Many engineers will never have seen this before, and
>>> might stumble.
>>>
>>> Bottom line, this is valid YANG, and it is supposed to work. For many
>>> people it will definitely be less readable than a relative path. I
>>> expect choosing the axis solution will slow the uptake of this module.
>>
>> I disagree. Tools should faithfully implement the standard, and
>> especially those that are used as "authoritative" in RFC validation
>> process. I don't see how axes could be considered esoteric - in fact,
>> they are very fundamental in XPath and things like '..' or '//' are
>> just syntactic sugar for axes contructs.
>
> I'm not going to argue with you when it comes to XPath in general. Axes
> are (a fundamental) part of it.
>
> I'm just speaking of current YANG practice. Out of the 45k YANG modules
> in the IETF YANG repo on Github (which includes standard, experimental
> and many vendor modules), I did not find any using axes today. I think
> that observation makes it reasonable to call them esoteric in YANG context.

This is a slippery slope. It's quite likely that none of existing
modules has ever used other XPath features, such as some built-in
functions. Does it mean that implementations may ignore them and fail
upon encountering such features. Who is going to decide what is esoteric
and what not?

RFC 8470 lists some XPath features that should not be used for good
reasons (including some axes), but the rest should IMO be OK to use.



I think you mean RFC 8407.
I checked and it does not say to avoid using the ancestor axis.
I checked our tools which support full XPath and no problems.

Looking at the actual usage (below), the 'ancestor' approach is more
readable and easier for the writer to generate correctly.
Given that the "network" node must be present in the augment-stmt,
it is not a concern that it is used directly in the when-stmt.


 augment "/nw:networks/nw:network/nw:node/tet:te/"
        + "tet:te-node-attributes/tet:connectivity-matrices/"
        + "tet:label-restrictions/tet:label-restriction" {

    when "ancestor::nw:network/nw:network-types/"
       + "tet:te-topology/flexgt:flexi-grid-topology";

/*
    when "../../../../../../nw:network-types/tet:te-topology/"
       + "flexgt:flexi-grid-topology" {
      description
        "Augmentation parameters apply only for networks with
         flexi-grid topology type.";
    }
*/
    description
      "Augment TE label range information for the TE node
       connectivity matrices.";
    uses l0-types:flexi-grid-label-range-info;
  }



Andy


>
> I have seen axes used in the real world YANG modules a handful of times.
> Each time it led to real world problems. They could be worked around and
> resolved, but it required YANG expert involvement and additional coding
> and testing efforts. My conclusion is that usage of axes is typically
> causing trouble and decreasing readability+understanding in the real world

In my experience, the complexity is not so much in XPath itself but
rather in brittle semantics of 'when'.

Lada

>
> Best Regards,
> /jan
>

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>
https://www.ietf.org/mailman/listinfo/yang-doctors