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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 24 April 2020 00:41 UTC

Return-Path: <rrahman@cisco.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 4777C3A0BE1 for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2020 17:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=koJsswYk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ECDPmDZq
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 G4MRbqFUrhe6 for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2020 17:41:13 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C843A0BE3 for <netmod@ietf.org>; Thu, 23 Apr 2020 17:41:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23685; q=dns/txt; s=iport; t=1587688872; x=1588898472; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ljb9+SNKy/CRf8vc9OR6wwZB3vElJWDi+baNAnazfdA=; b=koJsswYkD7vMJChSBcjgCsyDzVdVEvVF+NCs1cJTC2gBPuT7XLkw1sGv lrEzU7h7Sj979eWJHaf0250hpIigx4yuyGk9yqogD8csKc+d8/5lbj1r6 d89Q228xWFeh04YwJnw7ZlV+V/gJadrDkiR+QJCKF0jQEUFlRkykX1GJ3 k=;
IronPort-PHdr: =?us-ascii?q?9a23=3Amz4q7x8tL5dNLP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdSfAE3+JfjCZC0hF8MEX1hgrDm2?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BiCAB4NKJe/5BdJa1mHQEBAQkBEQU?= =?us-ascii?q?FAYF7gSUvKSgFbFggBAsqCoQVg0YDinCCOiWTTYRjglIDVAoBAQEMAQEYAQo?= =?us-ascii?q?KAgQBAYN/RQIXgg8kOBMCAwEBCwEBBQEBAQIBBQRthSoIJAyFcQEBAQEDAQE?= =?us-ascii?q?QER0BAQciAwIJAQ8CAQgHCQEDAQIOGgMCAgIlCxQJCAIEAQ0FFAcHgjlLAYF?= =?us-ascii?q?+TQMuAQ6meQKBOYhidYEygwABAQWBMgGDbBiCDgmBOIJjiVYagUE/gREnDBC?= =?us-ascii?q?CTT6BBIFjAQECggMNCQiCVDKCLY5Zgl2GFCSCUodmj3kKgkWIDI9rAhuCWZo?= =?us-ascii?q?Sj3WBVYdskzgCBAIEBQIOAQEFgWkiKYEtcBU7KgGCPglHGA2FM4wBGINbhRS?= =?us-ascii?q?FQnQCgSeLVi2BBgGBDwEB?=
X-IronPort-AV: E=Sophos;i="5.73,309,1583193600"; d="scan'208,217";a="494646326"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Apr 2020 00:41:10 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 03O0fAHc020710 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Apr 2020 00:41:10 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 23 Apr 2020 19:41:10 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 23 Apr 2020 20:41:09 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 19:41:08 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QtPAxjyKeCnMokVydUru9GMHZyWlKcKBJysikWnsKLcBxPRGWBz+G/PV75Q+GvOomh1AM4mUeKuNArl7IpQgzhOvLaQJ1IMaL4VrvOo/ylidDNHxUmYlC1vR6JCuAnfgSCIRKm5Pp0DlsQom4PuQtyge8h3VILuymt1kLnUUVSQkG7AB/RsjXRMLTJti2IOYn4VreMvQ7UqwwP/bODX6KZ7At+Ivbx5Zorh0swoSs8+lgA5b3M3F+JvzXt2xgjoFi95kj2NcNZ+nLsWmdvcn38uCjhD2iXNiCktpRcz10k2d2idP8NRjMQILKI60BOKLht17eZ9SmrXvT4Biaimhpw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ljb9+SNKy/CRf8vc9OR6wwZB3vElJWDi+baNAnazfdA=; b=QtqzIbvA9xcoDEOA2+JUV0THYKFGILXNZ51Z6eJOadRn474FitnE76KB7lBPqrlxVu7hrHFo/BryTOBJeFqAAmCP+Hhg4KWRCyyTvesbFOLhIccA3qA0O9tDduC/90z+txWsQN4VvJtFwFp34k5EtC0b2shgEDUpAFIHiqmBipS7qmM8Crv1t9Qr6jpAPgdHceOUJnKFTJ6QO6XEc1w37hGXCRHXx5Z/2SgD9UHCNTcU0PfkqmK9CBUQAwfLG97Twq8gPowcpvLLtPSO0/bBsI4KZEonWMghFBE77P4ZtKVk5QyfMJp2aZ3UNEpxjrXmw2w+SnBo4zSC9/GvW+y6nQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ljb9+SNKy/CRf8vc9OR6wwZB3vElJWDi+baNAnazfdA=; b=ECDPmDZqjMtyMVvroJHC2N2NWonwlXlB+bolMrx/v5mUwmtuHM9uutGuuNO9hxc/y9gdO6Zvjas3s5qRkYOSog85sSWFLO+d4jAsFplEhDDu/iT5DNOZ0HhbAS9Oz/NWbq61KjgN6AJzdiHEurCSc7yRMJC/2hjYDfqp5qdFqQc=
Received: from BN6PR11MB1748.namprd11.prod.outlook.com (2603:10b6:404:101::12) by BN6PR11MB1537.namprd11.prod.outlook.com (2603:10b6:405:c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25; Fri, 24 Apr 2020 00:41:08 +0000
Received: from BN6PR11MB1748.namprd11.prod.outlook.com ([fe80::39da:d30f:9899:3b82]) by BN6PR11MB1748.namprd11.prod.outlook.com ([fe80::39da:d30f:9899:3b82%7]) with mapi id 15.20.2921.030; Fri, 24 Apr 2020 00:41:08 +0000
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>, Andy Bierman <andy@yumaworks.com>
CC: "netmod@ietf.org" <netmod@ietf.org>, "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
Thread-Topic: [netmod] [Technical Errata Reported] RFC7950 (6031)
Thread-Index: AQHWBCEZzuRy8idP80CyzzDlf8HWT6hcjXeAgAAFCACAAAp/AIAKu06AgAAX5wCAAAZLgIAAAeaAgAAOQICAABnTgIAACK0AgAQORwCAAA4ygIAFOHsAgAe+IACAAA9dgIAOTScAgAA+BQA=
Date: Fri, 24 Apr 2020 00:41:07 +0000
Message-ID: <42586620-5970-40AD-9026-EC455F63DCF8@cisco.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>
In-Reply-To: <01000171a7fa898b-696030c8-0c3d-4e36-b2f1-49af349e1c0d-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com;
x-originating-ip: [70.31.50.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b66ecc9c-f077-41d9-f3e5-08d7e7e82da2
x-ms-traffictypediagnostic: BN6PR11MB1537:
x-microsoft-antispam-prvs: <BN6PR11MB153766D72C23D935466DF7D9ABD00@BN6PR11MB1537.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03838E948C
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB1748.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(376002)(396003)(346002)(39860400002)(66574012)(4326008)(966005)(6486002)(53546011)(26005)(36756003)(6506007)(54906003)(66946007)(6512007)(71200400001)(110136005)(91956017)(2906002)(478600001)(66476007)(33656002)(5660300002)(2616005)(76116006)(8936002)(86362001)(8676002)(66446008)(64756008)(66556008)(186003)(316002)(81156014); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PN9vzheyE4BtG3j9lGn/zAmbIQLEFhLP8+z2p4qL41lEltI3mWQacKHmeXqucRD70FEMglJPfujFJCUEZ7lGVhy8e6q23cOyl3Dqbi3RMyC4cKslJrAEctDZw4vN94nVwdqw8J66ZiLvGY6QmYtVYcdDJnF2l1Oscgm9L9KpUvH5fMmaCtU7QAx9zikPyMyoLUpMYqk0ONM6jAj+DGA537jw9vHVhIqJIN69fWXf1DQBqDkFwQv95FRfs2RGsTHqpX+q3FUGI+SHf7IwcA6dM/OyHBM/EwEs2Id8wMxBe0brof6hpXZFYQxSyu6gF+7I1gU0WR5Isc4VyKxJhxGyoJD3tR7ZfFtzhc5+78Zb/IAHtEtf5JwYhu1EagYkZWEbIA6QQVwjsRsC9pvsbnVvx8X8vVm4p7AR9EKjEaw3B49wRvOIxk0hrsl8kAYF3nWvuIbSv2ez1MIyslSoKtvG9ctEcyKPFVZfsBIPj4dWh+qy6FB+xfDFIdGIhYshrKbSjWxKtSfwbbU2Hs1njsXI5A==
x-ms-exchange-antispam-messagedata: UDMhFZ2n1DUGlB8XJERMar8WRSUj3O0SG8YGKP/RjqNEgRbbDA22s0mzIbazPRx9BXiuIZvtRPoM6N9d/9Oja0bqJc68VFoC1rtnP+mKw6pOLNd+v1y880T602/xcKjDRWJ6lSGRcGKa0Y6xgyWnMg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_42586620597040AD9026EC455F63DCF8ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b66ecc9c-f077-41d9-f3e5-08d7e7e82da2
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 00:41:07.9877 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IOPgqsL2Q6/TmksgSqj7pnVuGt6eHR1TGdz8v1v4CnVEeL0vum6YDf1jk5aCCq3eDhDe9YqqkaIT9nFPMBJshg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1537
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/A0NBsEhuEizLIirMGZ_M1tpq8EE>
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: Fri, 24 Apr 2020 00:41:17 -0000

I finally caught up to this thread. I agree with concerns raised by Radek and Balazs, but as others have mentioned an errata doesn’t seem to be the right medium for this. OTOH, yang-next might be too far away…. Could we do an update to RF7950 just for this? I realize it’s lots of work/overhead for “just” this issue.

Regards,
Reshad.

From: netmod <netmod-bounces@ietf.org> on behalf of Kent Watsen <kent+ietf@watsen.net>
Date: Thursday, April 23, 2020 at 12:59 PM
To: 'Andy Bierman' <andy@yumaworks.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>rg>, "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
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