Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Radek Krejci <rkrejci@cesnet.cz> Tue, 28 April 2020 08:34 UTC

Return-Path: <rkrejci@cesnet.cz>
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 B409D3A1023 for <netmod@ietfa.amsl.com>; Tue, 28 Apr 2020 01:34:37 -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 FqIGbWUnpN9I for <netmod@ietfa.amsl.com>; Tue, 28 Apr 2020 01:34:32 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::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 CDBF63A1027 for <netmod@ietf.org>; Tue, 28 Apr 2020 01:34:30 -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 4A0EC400064; Tue, 28 Apr 2020 10:34:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2-2020; t=1588062866; bh=ElsF+4SBEG+6J4bwp+wMXxdp934vpVtwQZxVUBuExpg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=OD/6whO+U73H9vjUwaT14zM8wEfPMlcTFiT4Gc2WRLtDdQYzpbjpkICdnVtH0+rge 6CambX9kmIQxsiKnwdcPeSyItMTHrZR4d889j+1AQg7Z93A8tgcBcXsnqaeQaY52xd TApWLG4EwAjwl0Oy7O+O+8G2s4h4bKLFI4i+99FcNcm5bbvVM/ho22qOzrrOfGgTY6 CaEGpRbL1hN66zxdERGzhnI5zFy8P+OInS0axdFV0WBUVKyaqw1le1W1l1Qne7jM4A tCjJzhlYdNJxbqe+GnXgSAF/Tusk9iwEAEWHG8nT88tGzZ0hfvO1wZF+gzO/3PY5iM jNKRgcKmwRJjA==
To: Mahesh Jethanandani <mjethanandani@gmail.com>, Jason Sterne <jason.sterne@nokia.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>, "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
References: <20200327161318.ykrx2s36bhmaglxq@anna.jacobs.jacobs-university.de> <DM5PR08MB263377515563D05220D299919BC70@DM5PR08MB2633.namprd08.prod.outlook.com> <9c3ee87c0e9d14c8921796c4b53d44620b53a942.camel@nic.cz> <MN2PR11MB4366BB6982E7A530F5654789B5C70@MN2PR11MB4366.namprd11.prod.outlook.com> <20200403165538.2lk4x5j32e3ctl4t@anna.jacobs.jacobs-university.de> <0a546588-6f87-3362-17da-37de8ea08956@cesnet.cz> <20200406074235.o6gkpjsim77xfzv7@anna.jacobs.jacobs-university.de> <010001715f8c4aa2-21fad32a-36d7-441e-bbb7-24e3aef1c229-000000@email.amazonses.com> <5319ca95-1f3a-33e6-aae3-cfd9861d59d7@cesnet.cz> <CABCOCHTkXAWTXybB2hN8B79v0GRCXBsaRg9O5SkfqbCqoh-J1A@mail.gmail.com> <01000171a7fa898b-696030c8-0c3d-4e36-b2f1-49af349e1c0d-000000@email.amazonses.com> <MN2PR11MB4366BEF8C6E05E8A5386AFE2B5D00@MN2PR11MB4366.namprd11.prod.outlook.com> <DM5PR08MB26333F2BEF0D6F11FB1A1B599BD00@DM5PR08MB2633.namprd08.prod.outlook.com> <73F9BE25-EE7E-4A99-B61D-3740BB850E35@gmail.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: <ef0b2fe5-ed9f-3410-a700-2d1a0d4b82a6@cesnet.cz>
Date: Tue, 28 Apr 2020 10:34:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <73F9BE25-EE7E-4A99-B61D-3740BB850E35@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000704020200090700090405"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/QSO76l6yKG9O00qKysmDqy2mBIk>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
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: Tue, 28 Apr 2020 08:34:38 -0000

+1

Thanks Kent and Rob for moving this forward, we should release
libyang/yanglint with this change within 2 weeks.

Regards,
Radek


Dne 27. 04. 20 v 19:30 Mahesh Jethanandani napsal(a):
> +1.
>
>> On Apr 24, 2020, at 12:39 PM, Sterne, Jason (Nokia - CA/Ottawa)
>> <jason.sterne@nokia.com <mailto:jason.sterne@nokia.com>> wrote:
>>
>> That seems like a reasonable approach to me.
>> Jason
>>  
>> *From:* netmod <netmod-bounces@ietf.org
>> <mailto:netmod-bounces@ietf.org>> *On Behalf Of *Rob Wilton (rwilton)
>> *Sent:* Friday, April 24, 2020 3:34 PM
>> *To:* Kent Watsen <kent+ietf@watsen.net
>> <mailto:kent+ietf@watsen.net>>; netmod@ietf.org <mailto:netmod@ietf.org>
>> *Subject:* Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
>>  
>> Hi Kent,
>>  
>> Thanks for creating the issue.
>>  
>> I think that errata falls under section 7
>> ofhttps://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/,
>> and could be classified as “Hold for Document Update”.  I.e. “Changes
>> that modify the working of a protocol to something that might be
>> different from the intended consensus when the document was approved
>> should be either Hold for Document Update or Rejected. Deciding
>> between these two depends on judgment. Changes that are clearly
>> modifications to the intended consensus, or involve large textual
>> changes, should be Rejected. In unclear situations, small changes can
>> be Hold for Document Update.”
>>  
>> I think that the consensus of the long term fix (e.g. in YANG 1.2) is
>> that “require-instance” should be allowed under typedefs that refined
>> types that allow it.
>>  
>> Pragmatically, I think that we can mark this errata is a “Hold for
>> Document Update”, with the accompanying errata notes (derived from
>> Radek’s comments) changed to:
>>  
>> “The document does not specify whether the “require-instance” keyword
>> is allowed in typedef refinements derived from the “leafref” or
>> “instance-identifier” base types, but it is anticipated that a future
>> revision of YANG would allow this.   It is suggested that modules
>> using YANG language versions 1 [RFC 6020] and 1.1 [RFC 7950] avoid
>> using this construct, YANG module validation tools flag a warning if
>> this construct is used, but implementations allow this if possible.”
>>  
>> Does anyone object to this course of action (or wishes to refine my
>> errata notes)?
>>  
>> Regards,
>> Rob
>>  
>>  
>> *From:* Kent Watsen <kent+ietf@watsen.net <mailto:kent+ietf@watsen.net>> 
>> *Sent:* 23 April 2020 17:59
>> *To:* Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>>
>> *Cc:* Radek Krejci <rkrejci@cesnet.cz <mailto:rkrejci@cesnet.cz>>;
>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de
>> <mailto:j.schoenwaelder@jacobs-university.de>>; Martin Björklund
>> <mbj+ietf@4668.se <mailto:mbj+ietf@4668.se>>; netmod@ietf.org
>> <mailto:netmod@ietf.org>; Rob Wilton (rwilton) <rwilton@cisco.com
>> <mailto:rwilton@cisco.com>>
>> *Subject:* Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
>>  
>> The consensus seems to be that:
>>   - the errata should be rejected
>>         - Rob, do you agree?
>>   - YANG-next should fix it later
>>         - I created https://github.com/netmod-wg/yang-next/issues/104
>>   - implementations should try to do the right thing now
>>         - Radek’s suggestion below LGTM!
>>  
>>  
>> Tallies:
>>    - for reject: Andy, Martin, Juergen, and Kent 
>>    - for accept: Radek, and Balazs
>>    - unclear: Lada, Rob, and Jason
>>  
>>  
>> Kent // as co-chair
>>  
>>
>>  
>>
>>     On Apr 14, 2020, at 10:35 AM, Andy Bierman <andy@yumaworks.com
>>     <mailto:andy@yumaworks.com>> wrote:
>>      
>>     Hi,
>>      
>>     I agree with Juergen that this errata should be rejected and the
>>     issue resolved in yang-next.
>>     No IETF module should use this construct. It is easy to convert
>>     to an equivalent form that is not under dispute.
>>      
>>      
>>     Andy
>>      
>>      
>>     On Tue, Apr 14, 2020 at 6:40 AM Radek Krejci <rkrejci@cesnet.cz
>>     <mailto:rkrejci@cesnet.cz>> wrote:
>>
>>         Hi,
>>
>>         Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):
>>
>>              
>>
>>              
>>
>>                 On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder
>>                 <j.schoenwaelder@jacobs-university.de
>>                 <mailto:j.schoenwaelder@jacobs-university.de>> wrote:
>>                  
>>
>>                 The definition I found in RFC 8639 is this:
>>
>>                        leaf stream {
>>                          type stream-ref {
>>                            require-instance false;
>>                          }
>>                          mandatory true;
>>                          description
>>                            "Indicates the event stream to be
>>                 considered for
>>                             this subscription.";
>>                        }
>>
>>                 This could be changed to:
>>
>>                        leaf stream {
>>                          type leafref {
>>                     path "/sn:streams/sn:stream/sn:name";
>>                            require-instance false;
>>                          }
>>                          mandatory true;
>>                          description
>>                            "Indicates the event stream to be
>>                 considered for
>>                             this subscription.";
>>                        }
>>
>>              
>>             I can confirm that `yanglint` validates the module
>>             cleanly after this change.
>>              
>>              
>>              
>>
>>                 On Apr 6, 2020, at 7:38 AM, Martin Björklund
>>                 <mbj+ietf@4668.se <mailto:mbj+ietf@4668.se>> wrote:
>>                  
>>                 I think the correct fix is to change the text so that
>>                 "require-instance" is not classified as a restriction
>>                 and keep the
>>                 default.  
>>
>>              
>>             Agreed.
>>              
>>
>>              
>>
>>                 Also, I think that it would be easiest (for backwards
>>                 compatibility w/ existing models) to allow
>>                 "require-inetance" to be
>>                 changed in derived types.
>>
>>                 However, this cannot imo be done in an errata.
>>
>>              
>>             While I appreciate Radek and Michal’s perspective, I also
>>             think that is would be best for the community for
>>             `yanglint` to support this, as they are published modules
>>             doing it.
>>              
>>
>>
>>         I don't feel as an expert for IETF processes, so I don't know
>>         if this issue can be solved in errata or not (and I'm not
>>         sure there is a consensus on this in mailing list). For the
>>         implementation, I would appreciate at least a consensus on a
>>         solution. So far I saw opinions to allow it, to disallow and
>>         also to make it implementation-specific (which means in fact
>>         to disallow from the authors perspective, since there can be
>>         a tool disallowing it and we are saying that such a tool is
>>         ok). So, there is no clear way for implementors, which means
>>         problems for interoperability - there will be always someone
>>         unhappy and so far I don't know what is the major opinion to go. 
>>
>>         So far, I tend to allow it (accept by libyang), but print
>>         warning to warn authors about possible problems (some tool
>>         can refuse such a module). Is it ok?
>>
>>         Radek
>>
>>             As an aside, I feel that all modules should be tested
>>             against all available validation tools during the
>>             publication process, but to find issues in the modules
>>             and well as possibly improve the tools.
>>              
>>             Sadly, I only have `yanglint` and `yangson` available to
>>             me.  I just checked for the “yang validator” project, but
>>             both www.yangvalidator.com
>>             <http://www.yangvalidator.com/> and https://www.yangcatalog.org/yangvalidator seem
>>             to be down.
>>              
>>              
>>             Kent // contributor
>>              
>>
>>          
>>         _______________________________________________
>>         netmod mailing list
>>         netmod@ietf.org <mailto:netmod@ietf.org>
>>         https://www.ietf.org/mailman/listinfo/netmod
>>
>>  
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod