Re: [yang-doctors] [netconf] Require-instance problem

Balázs Lengyel <balazs.lengyel@ericsson.com> Tue, 17 March 2020 17:06 UTC

Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C123A08BB; Tue, 17 Mar 2020 10:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=ericsson.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 LVH94HWRSLq0; Tue, 17 Mar 2020 10:06:49 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2069.outbound.protection.outlook.com [40.107.20.69]) (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 CE23C3A08B9; Tue, 17 Mar 2020 10:06:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cpQpD062q1p5DWhoKx1z69+aEf4xPMEezHSHxlZB6uwhTPAMd6TfO6laenXBHBwKhx5mTze09LXMSWmPc7Aez7SvWAyKD36YW+1Y3kTSoU9O9KHta7HBjJEdcEa9dm3afrG78BU74uu5ASNFlZPVawr3wvb39BQAmJTR9+yMzay1hwQjagGceoDqYFzTQHmygDuYnO+pYaB3EK1QkEwxNey4eIlzZrXX6pSq/jGnNy3YKs2kPur6J1Suk/TJq46xCQNXnK7AtAOCVMzuMFW/q00qU1atJuYyt3lZrvTenF7WQoOmbmFBUa6xiESWRJIOn4t/F/R0Jvt8cqPIyhQ4Fg==
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-SenderADCheck; bh=+I/mwAjt+t1FN/h9i+kq8feJUPiYtCqTNnnU8Vbwr7Q=; b=LNyyL5LeDHDUxUMrDOoIMyaO3bAL6gXa5IGaLYkCNNE0K5S8XECQ0w3pJkb/xvERrYxXpxyL6hPOa5RaGWSFG/wgc5UKbe//PLkgghGPgod7YouSLvScAqABOAl4XVdSaReQGFijLblVom5q59G3jx5NR12jlM/pQEeKdtL72DdlNDkOUj8ly/6KdD7HlEaL64C/G8L6TynCVJhFZ8dObVTH1kI/SaOA1fcxLNKyGQKGAemw6iXdBho5TnSAb+L/twahs+sYZZtif1UMem6NpybrqzT9lAJOxBnY8KXBTr6Tumg3XtFnPsro403KeeeTYEQsCJ7iQgqTIjZWV5kzMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+I/mwAjt+t1FN/h9i+kq8feJUPiYtCqTNnnU8Vbwr7Q=; b=Ci1hugH76no1iR1crWtpdmmZ+dMubgiXSHE7Ou9j2FlgeQu9KuM6Wl4Fc3sK+Cj+WC8+acmOlLQ9q/9z4iO+4ZtBn5hXLLg0MN9v/I1j5+ab0P+kfg5V2vpA032Z5A7LpY7cPQodqYzDZhoZaZQiJ5nxprX4xQS+lLJWFHNnB4U=
Received: from DB7PR07MB4011.eurprd07.prod.outlook.com (52.134.97.155) by DB7PR07MB5031.eurprd07.prod.outlook.com (20.177.192.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.12; Tue, 17 Mar 2020 17:06:46 +0000
Received: from DB7PR07MB4011.eurprd07.prod.outlook.com ([fe80::15cf:dc81:c6f4:aa0c]) by DB7PR07MB4011.eurprd07.prod.outlook.com ([fe80::15cf:dc81:c6f4:aa0c%7]) with mapi id 15.20.2835.013; Tue, 17 Mar 2020 17:06:46 +0000
From: Balázs Lengyel <balazs.lengyel@ericsson.com>
To: Martin Björklund <mbj@tail-f.com>, "rkrejci@cesnet.cz" <rkrejci@cesnet.cz>
CC: "mvasko@cesnet.cz" <mvasko@cesnet.cz>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Require-instance problem
Thread-Index: AQHV/Hvwp1NREeN4p0StvqE9Z11ZPKhNAnMg
Date: Tue, 17 Mar 2020 17:06:45 +0000
Message-ID: <DB7PR07MB40110B6BE6E65914C4F0E223F0F60@DB7PR07MB4011.eurprd07.prod.outlook.com>
References: <18a5-5e6b4c80-51-14b8eec0@242693337> <DB7PR07MB4011F15A702E44FA45DE894DF0FA0@DB7PR07MB4011.eurprd07.prod.outlook.com> <43ae63dd-a6e8-3e3f-43cd-c9b0f8b2bc8e@cesnet.cz> <20200317.174822.2184005326651469438.id@tail-f.com>
In-Reply-To: <20200317.174822.2184005326651469438.id@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
x-originating-ip: [80.98.254.17]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2636fe6d-cf48-4679-2d17-08d7ca9592ef
x-ms-traffictypediagnostic: DB7PR07MB5031:
x-microsoft-antispam-prvs: <DB7PR07MB5031A162E5B00919E46DB57BF0F60@DB7PR07MB5031.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0345CFD558
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(366004)(136003)(39860400002)(199004)(478600001)(71200400001)(66946007)(66446008)(66616009)(76116006)(64756008)(9686003)(55016002)(66556008)(66476007)(85202003)(81156014)(81166006)(8936002)(8676002)(5660300002)(966005)(2906002)(4326008)(66574012)(52536014)(316002)(7696005)(54906003)(6506007)(110136005)(85182001)(53546011)(86362001)(186003)(26005)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5031; H:DB7PR07MB4011.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: KeSnO6UXPlxN3mZNQhhMSPpBFEiVxuPiFhhCdlVnR82RAvIpOUI4Qn97rQpeHUwduImiMq2twnB9t7KOaCBS9UuSjIKj3MIYPLzwla2cTvfTInp20q64W/EOBZnK5vUZGZWa6qgRSfNiQGVvEGoOqEv0tPl4OnXy30xKlR1WIIFom7DIDAJTHqH0Ka1gi6bmZ7tvPlL/h/6Rx4fnJpVYXHppBpYvPxQuvPLXz0fDIb6ZVpCXEtNBmcHbJDXaOt0r/9hNVNYXI02H7WwPXE+3kIdJehQ/TX7R9H5iPe1bjC7qX8mQ1i8T9gGkc3auXUPVfRmPWEmbSOtBczsf7aYo7ljg/RJch7ZMO7H193UlBO6pVTftc4ITC9w50Kd4MU6sZ5NYqvlX5r1Gj37TxIbjrq60inkr+xfyacX3VjFkekagm9pBPeRvVkZhUkb3VSuXpjb2o+xXSSgm8IJbD9l2s65F9QAz1Ux+cXehTL3WDAwPdEaj2OHFpS4PO2hcA2cDQf5k1YN6CXCUVAsBot0q5A==
x-ms-exchange-antispam-messagedata: fcIZx2qVfbZMrXWSjAWjNt11a4PQOooQ2o+njlNJECol5Q3RUzu3Vy9gTwD//Hn8sM8fRs0Z5zAaqp4WPCU77cFzG5sBjMQSyIsDoI+ZXVy+Iq82UjBU7RyxPRTEC4s9yrG3TY43i7Ss2pjObXX0Ew==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_02F6_01D5FC86.D10376A0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2636fe6d-cf48-4679-2d17-08d7ca9592ef
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 17:06:45.9161 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 86LkBR9jrZbZEckNk3KRoq37fwuulQH1/gcHJMWBfDbyeWQyusuIqinYQQUE9m61jHTH0pssq1lh0Tp7gqPcdz03O16IsbwDHqfY2vvVbZc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5031
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/7ePwoGyOagyHjy_DX1JHCVdLqts>
Subject: Re: [yang-doctors] [netconf] Require-instance problem
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2020 17:06:53 -0000

Hello Radek, Martin,
At this point I cannot imagine a reason why require-instance would be allowed on a locally defined type, but not in a typedef. Do you see any reason for such restriction?
Regards Balazs

-----Original Message-----
From: Martin Björklund <mbj@tail-f.com> 
Sent: 2020. március 17., kedd 17:48
To: rkrejci@cesnet.cz
Cc: Balázs Lengyel <balazs.lengyel@ericsson.com>; mvasko@cesnet.cz; yang-doctors@ietf.org; netconf@ietf.org
Subject: Re: [netconf] Require-instance problem

Hi,

Some background:

Some types in YANG can be restricted, e.g., an int32 can have a range restriction, a string can have a length restriction etc.  When a type A is restricted in this way, the new type B's value space is a subset of A's value space.

Some types cannot be restricted, i.e., their value space cannot be altered (e.g., "boolean").

Some other types need substatements to properly define the value space, e.g., an "enumeration" needs a set of "enum" statements and a "decimal64" needs a "fraction-digits".

The only way to expand the value space is to use type "union".

So in all cases, the derived type's value space is a subset of its base type's value space.

Now, for instance-identifier and leafref, the "require-instance" is a bit weird.  It is called a "restriction" but it isn't really a restriction, since it doesn't change the value space.  If it is set to "true" it defines a constraint that must be true in valid data.

Radek Krejci <rkrejci@cesnet.cz> wrote:
> Also
> please compare with the text in 9.4.4 (length) or 9.2.4 (range) where 
> the derived types are explicitly mentioned in case the statement is 
> meant to be allowed there. The specification is not supposed to 
> explicitly state where it IS NOT allowed, instead it specifies where 
> it IS allowed.

Agreed.

> By your interpretation, require-instance would be allowed even in 
> integer types since it is not explicitly denied.

I don't think this is the logical interpretation.  Suppose we have two types "foo" and "bar":

   typedef foo {
     type leafref {
       path "...";
     }
   }

   typedef bar {
     type int32;
   }


It makes (some) logical sense to say that "foo" is a "leafref", and hence it would be legal according to 9.9.3 to use "require-instance" in "foo".

But it does not make logical sense to say that "bar" is a "leafref", and hence 9.9.3 doesn't make it legal to use "require-instance" in "bar".
BALAZS: 9.9.3 includes "MAY be present if the type is instance-identifier or leafref" 
Which to me clearly states this is not allowed for an integer.

I don't remember the original intention, but obviously people have interpreted the text in 9.9.3 in different ways, which indicates that it is wrong and should be fixed.  However, I don't think either interpretation is obviously correct.  Thus, I think that we cannot state that the usage of "require-instance" in ietf-subscribed-notification is wrong.


/martin




> 
> Regards,
> Radek
> 
> 
> >  Intentions about the pattern of the text are speculation. The text says it MAY be there. So unless an errata is filed, it is allowed. IMHO if that is the intention we would need an explicit sentence like:
> > "Usage of require-instance is not allowed for derived types."
> > I don't have a strict view on which was the intention (maybe Martin has) but the text is unambiguous to me.
> > Regards Balazs
> >
> > -----Original Message-----
> > From: Michal Vaško <mvasko@cesnet.cz>
> > Sent: 2020. március 13., péntek 10:04
> > To: Balázs Lengyel <balazs.lengyel@ericsson.com>
> > Cc: Mahesh Jethanandani <mjethanandani@gmail.com>; netconf@ietf.org; 
> > yang-doctors@ietf.org
> > Subject: Re: [netconf] Require-instance problem [was: RE: WGLC: 
> > draft-ietf-netconf-notification-capabilities-11]
> >
> > Hi Balazs,
> > just to explain libyang behavior, if you look at (pattern <https://tools.ietf.org/html/rfc7950#section-9.4.5> ) definition, there is explicitly mentioned that it can appear in derived types. There is no such wording for (require-instance <https://tools.ietf.org/html/rfc7950#section-9..9.3> ), it mentions only "instance-identifier" and "leafref" types.
> >
> > Also, libyang does not allow loading invalid schemas so even if you only import it, it will fail.
> >
> > Regards,
> > Michal
> >
> > On Friday, March 13, 2020 09:55 CET, Balázs Lengyel <balazs.lengyel=40ericsson.com@dmarc.ietf.org> wrote: 
> >  
> >> Hello Mahesh,
> >>
> >> Even if there is some problem with ietf-subscribed-notification how does that effect the validity of instance data for ietf-system-capabilities or ietf-notification-capabilities ? I only import a type and a feature from Yangpush (which imports subscribed notification). These seem nothing to do with require-instance.
> >>
> >>  
> >>
> >> Aside from my draft:
> >>
> >> I do not understand some of libyangs statements:  
> >>
> >> “as it turned out (ref <https://tools.ietf.org/html/rfc7950#section-9.9.3> ), you cannot put require-instance into a derived type”. 
> >>
> >> Checking ref I did not find why you cannot put require instance into a typedef.
> >>
> >>  
> >>
> >> By the way I have bigger issues with YangValidator. When I load 
> >> ietf-system-capabilities@2020-03-08 into it I get
> >>
> >>  
> >>
> >> RecursionError at /yangvalidator/validator
> >>
> >> maximum recursion depth exceeded
> >>
> >>
> >> Request Method:
> >>
> >> POST
> >>
> >>
> >> Request URL:
> >>
> >> https://protect2.fireeye.com/v1/url?k=6cc7e6c7-3013efa1-6cc7a65c-86
> >> 10d8a762ca-0a278d65531d4f4f&q=1&e=b7200729-5cfb-4d52-b459-737457b26
> >> 6e0&u=http%3A%2F%2Fwww.yangvalidator.com%2Fyangvalidator%2Fvalidato
> >> r
> >>
> >>
> >> Django Version:
> >>
> >> 3.0.4
> >>
> >>
> >> Exception Type:
> >>
> >> RecursionError
> >>
> >>
> >> Exception Value:
> >>
> >> maximum recursion depth exceeded
> >>
> >>
> >> Exception Location:
> >>
> >> /home/yang/yangvalidator/lib/python3.6/site-packages/pyang-2.1.1-py
> >> 3.6.egg/pyang/statements.py in newf, line 42
> >>
> >>
> >> Python Executable:
> >>
> >> /usr/sbin/uwsgi
> >>
> >>
> >> Python Version:
> >>
> >> 3.6.10
> >>
> >>
> >> Python Path:
> >>
> >> ['/home/yang/yangvalidator/lib/python3.6/site-packages/pyang-2.1.1-
> >> py3.6.egg/pyang/transforms',
> >>
> >>  
> >>
> >> Regards Balazs
> >>
> >>  
> >>
> >> From: Mahesh Jethanandani <mjethanandani@gmail.com>
> >> Sent: 2020. március 12., csütörtök 22:28
> >> To: Balázs Lengyel <balazs.lengyel@ericsson.com>
> >> Cc: Kent Watsen <kent+ietf@watsen.net>; netconf@ietf.org; 
> >> yang-doctors@ietf.org
> >> Subject: Re: [netconf] WGLC: 
> >> draft-ietf-netconf-notification-capabilities-11
> >>
> >>  
> >>
> >> [Adding yang-doctors]
> >>
> >>  
> >>
> >> Hi Balazs,
> >>
> >>  
> >>
> >>  
> >>
> >> On Mar 10, 2020, at 2:06 AM, Balázs Lengyel <balazs.lengyel@ericsson.com <mailto:balazs.lengyel@ericsson.com> > wrote:
> >>
> >>  
> >>
> >> Finally, have all the examples in the appendix been validated?
> >>
> >> BALAZS: Yes, they have been loaded into a live Confd server.
> >>
> >>  
> >>
> >> I bring this up because I ran into issues when validating the https-notif model using ietf-subscribed-notification module, something that you also import. Here is what I see when I try to use yanglint to validate your example. In this case, I named your example as examples-notification-capabilities-1.xml.
> >>
> >>  
> >>
> >> bash-3.2$ yanglint -s -i -t auto -p 
> >> /Volumes/External/git/iana/yang-parameters/ 
> >> ietf-system-capabilities@2020-03-08.yang 
> >> <mailto:ietf-system-capabilities@2020-03-08.yang>  
> >> ietf-notification-capabilities@2020-03-09.yang 
> >> <mailto:ietf-notification-capabilities@2020-03-09.yang>  
> >> examples-notification-capabilities-1.xml
> >>
> >> err : Invalid keyword "require-instance".
> >>
> >> err : Module "ietf-subscribed-notifications" parsing failed.
> >>
> >> err : Importing "ietf-subscribed-notifications" module into "ietf-yang-push" failed.
> >>
> >> err : Module "ietf-yang-push" parsing failed.
> >>
> >> err : Importing "ietf-yang-push" module into "ietf-notification-capabilities" failed.
> >>
> >> err : Module "ietf-notification-capabilities" parsing failed.
> >>
> >>  
> >>
> >> At first I thought the issue was with yanglint, because just like you I used confd and it did not complain. But folks over at libyang tell me that this was discussed as part of their issue  #881 <https://protect2.fireeye.com/v1/url?k=a6420c80-fa9605e6-a6424c1b-8610d8a762ca-d6cddc5edf1151a7&q=1&e=3cd8e8af-8aea-4f96-939b-8e1e455eac74&u=https%3A%2F%2Fgithub.com%2FCESNET%2Flibyang%2Fissues%2F881>  and the conclusion was that you cannot put require-instance in a derived type based on this <https://tools.ietf.org/html/rfc7950#section-9.9.3>  text.
> >>
> >>  
> >>
> >> Who is correct in their assertion, libyang or confd/RFC8639?
> >>
> >>  
> >>
> >> In case anyone is wondering which ietf-subsciribed-notifications module is being imported, here it is:
> >>
> >>  
> >>
> >> bash-3.2$ ls 
> >> ..../iana/yang-parameters/ietf-subscribed-notifications@2019-09-09.
> >> yang 
> >> <mailto:iana/yang-parameters/ietf-subscribed-notifications@2019-09-
> >> 09.yang>
> >>
> >>  
> >>
> >> Cheers.
> >>
> >>  
> >>
> >> BTW, even if I comment out the ‘require-instance’ statement, yanglint complains about other issues with ietf-subscribed-notifications, which I will bring up in a separate thread.
> >>
> >>  
> >>
> >> Mahesh Jethanandani
> >>
> >> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
> >>
> >>  
> >>
> >>  
> >>
> >>  
> >>
> >  
> >  
> >
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>