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

Radek Krejci <rkrejci@cesnet.cz> Tue, 14 April 2020 13:40 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 C009C3A0651 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2020 06:40:31 -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 mP8wT3wNjVtK for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2020 06:40:26 -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 8D7F33A03F2 for <netmod@ietf.org>; Tue, 14 Apr 2020 06:40:24 -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 7358540005D; Tue, 14 Apr 2020 15:40:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2-2020; t=1586871622; bh=pCVmiRQ6OEGaa//R+POmxoFbF/LU7Qw4lcmjRdW+AFk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=OfQzlghdNND8VtA8BhD3cyV2iOT4loJY/sXlp2LlzcZTokXOHSQ0gUEdp6W1jRRg8 mCWygI/ybLQKvVBCtDZhWy86OCGd8LdTV0iTEdUmXPuL6729/Xsff9JTRM91J0pwXP Kw3tVcTLOCykkpR/cw5Hixz5GJ4tTmmiDiMOHX4NxiBExj7vcd5TOoGXdSXX8yJG5d gJVU4Q1lcQSA+CpLw30lAmxMR9O/M7e7frDVS76Um9u2e4/7SZqVgE/h376CgITLbK wpk99yX3KVqbUXYlNfsD2ilCOTv1TyVJsYyt6jcgx4VTSQQKFdQDdRuM3R74JzmBDl HI3++MVfalB+g==
To: Kent Watsen <kent+ietf@watsen.net>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Björklund <mbj+ietf@4668.se>
Cc: "netmod@ietf.org" <netmod@ietf.org>, "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
References: <20200327161318.ykrx2s36bhmaglxq@anna.jacobs.jacobs-university.de> <MN2PR11MB43666AB22069D14FC3FB9A66B5C70@MN2PR11MB4366.namprd11.prod.outlook.com> <DM5PR08MB26333FAB53D3C4C781AB7B6B9BC70@DM5PR08MB2633.namprd08.prod.outlook.com> <20200403.155421.968858617291773287.id@4668.se> <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>
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: <5319ca95-1f3a-33e6-aae3-cfd9861d59d7@cesnet.cz>
Date: Tue, 14 Apr 2020 15:40:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <010001715f8c4aa2-21fad32a-36d7-441e-bbb7-24e3aef1c229-000000@email.amazonses.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030201050808030809050308"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jmjYjTwjNMoJYMtKgP_Shk0FpZ4>
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, 14 Apr 2020 13:40:32 -0000

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
>