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

Kent Watsen <kent+ietf@watsen.net> Thu, 23 April 2020 16:59 UTC

Return-Path: <01000171a7fa898b-696030c8-0c3d-4e36-b2f1-49af349e1c0d-000000@amazonses.watsen.net>
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 446CA3A0CDE for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2020 09:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=amazonses.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 ESooBx4rW6qq for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2020 09:59:08 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8D33A0CDF for <netmod@ietf.org>; Thu, 23 Apr 2020 09:59:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1587661146; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=P5sAtFqQ0eJ98gmY1lwQVljJUieO7/VsTEEsZp2mfmg=; b=HjNziFj3D+TfpJytg3mTZW1Hgz0yCra6F/vTaGl7uKs4/tLGZXrbL4XgcZRhbIBz FvQ/7MSWQuMyC+7PGhWBfYj7zcCQxKRqhiWHaH3sqZ24O9+CPtFwaUppo36uS/0VSOe +54XaSh4lx1WWuCtvF0c2KQ2/n8UXWqnhGn/6HzQ=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000171a7fa898b-696030c8-0c3d-4e36-b2f1-49af349e1c0d-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_24360AC2-E512-4234-88D7-E9F793CB8AAC"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 23 Apr 2020 16:59:06 +0000
In-Reply-To: <CABCOCHTkXAWTXybB2hN8B79v0GRCXBsaRg9O5SkfqbCqoh-J1A@mail.gmail.com>
Cc: Radek Krejci <rkrejci@cesnet.cz>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Björklund <mbj+ietf@4668.se>, "netmod@ietf.org" <netmod@ietf.org>, "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
To: Andy Bierman <andy@yumaworks.com>
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> <5319ca95-1f3a-33e6-aae3-cfd9861d59d7@cesnet.cz> <CABCOCHTkXAWTXybB2hN8B79v0GRCXBsaRg9O5SkfqbCqoh-J1A@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.04.23-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-DL8bLEqOeKOKN64G_gr3PXtcdA>
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: Thu, 23 Apr 2020 16:59:14 -0000

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> 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 <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 <https://www.ietf.org/mailman/listinfo/netmod>