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

Andy Bierman <andy@yumaworks.com> Tue, 14 April 2020 14:35 UTC

Return-Path: <andy@yumaworks.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 E06C73A0831 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2020 07:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 KgSsvnHgoBpP for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2020 07:35:32 -0700 (PDT)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 C4A783A082D for <netmod@ietf.org>; Tue, 14 Apr 2020 07:35:31 -0700 (PDT)
Received: by mail-yb1-xb2d.google.com with SMTP id n2so7297306ybg.4 for <netmod@ietf.org>; Tue, 14 Apr 2020 07:35:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kBKu9fXXzzf35Qe+0zMcddefuFrXFQDuBmY+cSB+P+o=; b=K2M5AnwBrwV+JBNSHvpVGSsaI4QnEuzmh3/CilBHCwIPeEJ54l+/Abyimm78FuiGna zEiJ3ccIien69j9h3urBz7S7VPr4+Ih/KaXb7bFtYH0gGAMsCMwtcigl3q79SD36ioib Rn+n4/oMUvlSKXHrMMqxydM2jIYy6CjMabfPxr5eOq3wFaH/65wB2577Kov9mtuoxjjx Z1qRar3QWdRkjwHFbjmq8EB0pS+yJbiGHgjYV6sBUPKyavMCHLE9rmbUMb562XR1bfsV laidPAl8/3SjVXcg1USN3xd+obMbcDMOe0N5hNeOVv0zjJWvjOo5x7A/JBGamG5B55/J pxsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kBKu9fXXzzf35Qe+0zMcddefuFrXFQDuBmY+cSB+P+o=; b=cJhcsZmCqPB0qmDSeXWfTAkSD/5WoTJ7oc//tvfEcZbBM7uX4xx/rYhjOJemzpJgHC +S6ItRFED9wqQQKyHmru+hn9X9BJBKrb09dDejuHr09GMX6GXtCPcTPdXJv9/NIg4pKq uSjLXWeLmHgr1m3h6LHWeYqC/UB9HQn+fSEyvVIwDid58mr1Fe409+FuaMTUcubGJa05 PgI75d7xoWZZhBqYph9Z1wcnLErKJT3MBPa0rF+HSX1qJtsZPmVeCT5aDpQvBNFQv1CC bRAt4M1/yczPOxcL5aErd8fNXtEYIxejTHcW+gqevO9Qxy5BiJNQaWDRJkbVSdB61+IX 9MfA==
X-Gm-Message-State: AGi0PubCrOlLeSW3ZP9+TcNELSdDfD7j3jDoyio89PD3N0UfqzaksVZ7 vUO3zldgExuSBcG/tgS88xcSuhwm8gkdEwWlKFX3e4Ms
X-Google-Smtp-Source: APiQypKbUceT0iuwEQJcYgA1XV5gxJFt2ZPaezSUo+Wfzd2arg2Ud0FiK7suSsZnbYi7kFpuQFx0kbL3BKYuKmBNNWI=
X-Received: by 2002:a25:7c2:: with SMTP id 185mr573251ybh.44.1586874930408; Tue, 14 Apr 2020 07:35:30 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <5319ca95-1f3a-33e6-aae3-cfd9861d59d7@cesnet.cz>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 14 Apr 2020 07:35:19 -0700
Message-ID: <CABCOCHTkXAWTXybB2hN8B79v0GRCXBsaRg9O5SkfqbCqoh-J1A@mail.gmail.com>
To: Radek Krejci <rkrejci@cesnet.cz>
Cc: Kent Watsen <kent+ietf@watsen.net>, 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>
Content-Type: multipart/alternative; boundary="00000000000087ca1505a3411ca9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SjgZUiZVzaLhi9EX8-u4zpJxcRo>
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 14:35:36 -0000

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> 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> 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> 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
>  and https://www.yangcatalog.org/yangvalidator seem to be down.
>
>
> Kent // contributor
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>