Re: [yang-doctors] [netconf] Require-instance problem [was: RE: WGLC: draft-ietf-netconf-notification-capabilities-11]

Radek Krejci <rkrejci@cesnet.cz> Mon, 16 March 2020 09:28 UTC

Return-Path: <rkrejci@cesnet.cz>
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 E1CA83A127C; Mon, 16 Mar 2020 02:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cesnet.cz
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 h_BaMh6Omzut; Mon, 16 Mar 2020 02:28:15 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (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 D76283A1283; Mon, 16 Mar 2020 02:28:12 -0700 (PDT)
Received: from [192.168.55.109] (ip4-83-240-38-102.cust.nbox.cz [83.240.38.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 194D9400052; Mon, 16 Mar 2020 10:28:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2-2020; t=1584350888; bh=tA+AyCnV5F4SLPGmC/hCQr2BIFZPCQ9Ih1zp5KGx8/M=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=DW2L5UKn4HZRfZJSOoA4h/yw0AnfiIY/7Lzz38srl4I99MOPFzb+3KqNrTCn4viCk wYDJywoOw1WpUJDo+Y+hznaUVfGEM9CN+fbFwFw4USOcO5s3pjyA1RIUTvhf/+yVt9 l6o1B+oL/0JaYdYzqqshxMsG+HlAr4SK/gcbEsoC7cCJXl7AEwHjcpovGuZvEEN6hm FhWgHffWXeyP5zyQpYUYNEIONXgpscL05stcIJY+Yv3mROCup7DNEVPkYaQv823IJA CzQi/7gINknweHlmppm3KNiGvBA02XZYMBV0rEWcySTC3IzbEWSYpsViW142k2Etn8 EX+NLeq9vI4lg==
To: Balázs Lengyel <balazs.lengyel=40ericsson.com@dmarc.ietf.org>, Michal Vaško <mvasko@cesnet.cz>
Cc: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
References: <DB7PR07MB4011D375898BD9B8DD213135F0FA0@DB7PR07MB4011.eurprd07.prod.outlook.com> <18a5-5e6b4c80-51-14b8eec0@242693337> <DB7PR07MB4011F15A702E44FA45DE894DF0FA0@DB7PR07MB4011.eurprd07.prod.outlook.com>
From: Radek Krejci <rkrejci@cesnet.cz>
Autocrypt: addr=rkrejci@cesnet.cz; keydata= xsDiBEKfHd4RBADDE8CtJpEtOraXBKfQg0KCRZu7BRALixoLqW98U+N9h+PJ+gCnFaKNmnYu fXWLYKTJRUlaoMGIJOZjHpr/zvwozSR+VJkxCsTyNYTF8vIfN3Iwrxy9e8CNy/O1GI50K/ld WWMDl+3M2NztiBFPrCT0b/U5ErsN7bTrf2XLEQRpZwCg95POGbJPqPAaaok2KU5e2u0/flsD /AyC0aRO66Ci0OGw0R5sCJmzZ5xE5eBUvfx0N0IC16aojrwRYM5yf+bULtBDd4wPI1R+VH/X P6OrDgzlDmutJthVtYfCcho3IhqnVo1R/UvJxjF3ATKbOnVHL4xwiLSrRDb6rKVyd1+Kc7cq +JABgFl+JP4xndytvvUXdVqhuSUFBACCDdDtxutkclBrvEp2guBIftuT4/oK3IWxgtevlGfY LZXwdD6pIWS1z6y6xthoFTsLWS1QCFk2ZXmAgvOV/lnW0iGHwO5kCfzvWJq7weeH2FGuBgq+ WInxhdIFD/QwiXV6EPUWzAoC5Fx4Cz5ySFSd6n0C1Mrzin3ABtPHRpUT8s0pUmFkZWsgS3Jl amNpIChDRVNORVQpIDxya3JlamNpQGNlc25ldC5jej7CYgQTEQIAIgUCTT/pkAIbAwYLCQgH AwIGFQgCCQoLBBYCAwECHgECF4AACgkQIMoxClN+p/31DwCfWVWX1IWaUa6+QbuVvZQIkb6m Rn8AoLRvdANGe/As/Nxabu+KKtrorkQ6zsBNBEKfHeIQBACwORs231u+o9/pM7y85ZlZhnNY iJziZ4P5W9lD5cwcEUFgTt1upUmjjSMWr5x4HL6o5jZeKOQMxiYP+8qA8OPEM6fzemS1Uj9M 6RXUaoUZFrcKD6BvneyyKuGgNa9bQfTG0aDOqaxy4lYFNcHVeo9sXJ+6adVxlCo/GzZ6zznn nwADBQP+IZQoao7aCFkZOVk8F5AW9Iiz0hk1trdCw88vD5fPMqcLxOQEsKrHAjibTWyOy1il 9zgLyVjcBzOs+v6UvbcJRybyaITC7j4IFPr78euVup/AeL+A9ay+ZWKHMFzALD+VjLyYAiRL w2MBjdqAKbPh2Ei1HXJoOX5JTWWnMRsBey/CSQQYEQIACQUCQp8d4gIbDAAKCRAgyjEKU36n /YssAKDVrEroZMSci018ipG4q6w11TsriwCghwCwX0isavqXJTbw10hwJePlDns=
Message-ID: <43ae63dd-a6e8-3e3f-43cd-c9b0f8b2bc8e@cesnet.cz>
Date: Mon, 16 Mar 2020 10:28:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <DB7PR07MB4011F15A702E44FA45DE894DF0FA0@DB7PR07MB4011.eurprd07.prod.outlook.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms050907010203040101090705"
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/vhHUZoq1hHI6nzmQpsU_7yAKtLo>
Subject: Re: [yang-doctors] [netconf] Require-instance problem [was: RE: WGLC: draft-ietf-netconf-notification-capabilities-11]
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: Mon, 16 Mar 2020 09:28:18 -0000

Hi Balasz,

Dne 13. 03. 20 v 10:40 Balázs Lengyel napsal(a):
> Hello Michal,
> While the Require-instance issue may or may not be a problem, it is not caused by my netconf-notification-capabilities draft. I hope we agree on this.
>
> About the require-instance problem:
> Not mentioning derived types for require-instance in 9.9.3 can be intentional or an omission. If I just strictly read the text:
>> The "require-instance" statement, which is a substatement to the
>>    "type" statement, MAY be present if the type is "instance-identifier"
>>    or "leafref".
> This says that the require-instance is allowed under type; full stop.

but there is no full stop, the sentence continues, please read it till
its end, it specifies conditions when the substatement can be used. 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. By your interpretation, require-instance would be allowed
even in integer types since it is not explicitly denied.

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-8610d8a762ca-0a278d65531d4f4f&q=1&e=b7200729-5cfb-4d52-b459-737457b266e0&u=http%3A%2F%2Fwww.yangvalidator.com%2Fyangvalidator%2Fvalidator
>>
>>
>> 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-py3.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