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

Mahesh Jethanandani <mjethanandani@gmail.com> Mon, 27 April 2020 17:30 UTC

Return-Path: <mjethanandani@gmail.com>
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 9403D3A1229 for <netmod@ietfa.amsl.com>; Mon, 27 Apr 2020 10:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 H7-rrFvpTo08 for <netmod@ietfa.amsl.com>; Mon, 27 Apr 2020 10:30:21 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE633A1233 for <netmod@ietf.org>; Mon, 27 Apr 2020 10:30:21 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id t11so8993687pgg.2 for <netmod@ietf.org>; Mon, 27 Apr 2020 10:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hfee5v/c9nMTcVLCndq1s6NDlULWjSDjp1Qb/W7QcB8=; b=FAUgA9T1znjA26vCV4ksTVG69dsjniqXpKCDNVJxGovNtNGY8jtTQU+6AcazveGVta uK/ptR3cLk61JisVDMhElc/3U0v6ET3rgjQG1RiHKAnbnM76SkAjtHu91XRz4QSK8SiG X4fwgjYREZtP6BckFwjBkblTmqagew0xp+uUemvcYMztsQkyH9lU45VYIsGfwWrejhNP IoYFFeidqfGNhUvOYbya5eD8Au/Pe8YLPB+JNCMxB57+xKnmkvrLfD4HsqUBlAbuyXdD rLwT44B9RSLug94noHtCgxYM1zSAOk5utYvx9SfFdteamUIa0qrc5SdmAkHhPgMi/AEu 2cjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hfee5v/c9nMTcVLCndq1s6NDlULWjSDjp1Qb/W7QcB8=; b=qK/gNHkio7Zdu3U86iqk22zwv/+ruyMqkQ9hRhIIqkz40X2F3a3j5ptO+9134ge98l cI094noIANJspBjYwQwp8iXZZUEX/2+JF8VElFGK9Au+RUfpXXvF3vl6xK1Tp1RLPt8q Pk54Q8rS2TJm0udTHCInyazpMPPOYYeON31K6HTaTvcEtTVtK+SU80LDVIusV5dB3APt 9M3DOMhdjjj9DRQynXagYHMxcvK03xYGZPao2245PZFKO15Hs0zh60bAmgBsN22IHQI+ yByyWCPWfKGYdhzD3u6e3wjrvhgzSeQfblhToikjfHbbyCD66gF7CxfdaaAvsvdE+8ee IGlw==
X-Gm-Message-State: AGi0PuY1J84LB9DEkNa+u+Vhiccrlh7xgNdGATqWawGrruGP5cx6aP1W fogWJxp2r98uw1jGxUKMbtw=
X-Google-Smtp-Source: APiQypLB/Z5q8VWB/C295Gd11KR5BZECBHGG0KayBuZyWKzE5DdU7towmvT/zdgFL3KTpxcpRMbrvQ==
X-Received: by 2002:aa7:9889:: with SMTP id r9mr25345289pfl.233.1588008620957; Mon, 27 Apr 2020 10:30:20 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:a91a:d26:27c6:4cad? ([2601:647:5600:5020:a91a:d26:27c6:4cad]) by smtp.gmail.com with ESMTPSA id w28sm11206398pgc.26.2020.04.27.10.30.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2020 10:30:20 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <73F9BE25-EE7E-4A99-B61D-3740BB850E35@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B5246D7A-245F-4109-8F7B-167B3A1FDC46"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Date: Mon, 27 Apr 2020 10:30:18 -0700
In-Reply-To: <DM5PR08MB26333F2BEF0D6F11FB1A1B599BD00@DM5PR08MB2633.namprd08.prod.outlook.com>
Cc: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>, Kent Watsen <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>
To: Jason Sterne <jason.sterne@nokia.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> <01000171a7fa898b-696030c8-0c3d-4e36-b2f1-49af349e1c0d-000000@email.amazonses.com> <MN2PR11MB4366BEF8C6E05E8A5386AFE2B5D00@MN2PR11MB4366.namprd11.prod.outlook.com> <DM5PR08MB26333F2BEF0D6F11FB1A1B599BD00@DM5PR08MB2633.namprd08.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FUtdqC0S90yGLYgeXHIzDNBA6DE>
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: Mon, 27 Apr 2020 17:30:26 -0000

+1.

> On Apr 24, 2020, at 12:39 PM, Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:
> 
> That seems like a reasonable approach to me.
> Jason
>  
> From: netmod <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>et>; 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/ <https://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 <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 <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>
>  
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod