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

"Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> Fri, 03 April 2020 14:01 UTC

Return-Path: <jason.sterne@nokia.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 188BF3A07AB for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2020 07:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 9FYLTpRMF9jM for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2020 07:01:12 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2138.outbound.protection.outlook.com [40.107.220.138]) (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 A64CA3A07AC for <netmod@ietf.org>; Fri, 3 Apr 2020 07:01:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T0gFN42oL0i8ftoaGG+LYX3qeeT3JqTuVXvH35xB5OtJ8JNqShQwe45AqRi9rfZkTBsBFgniKVvqcATxrJXFbD/gwbYB+T7N0Dzy34p4wJ4K10krpZjYaiaCba3RSoZWEz0tkG25tsSaS45n4QMg6wHdxvj25WpV8xX3LLVU4uQxAr2iin83Kjs4v4Q+pTb5Cnu1S1lWbPBhMLmaxIs3JsjC16/cbdoN3aG6wRGAd8I+wzUouqogx2IYUbKtYhQW7la2krxDbg6aQXsenJgJiaW0M6jXEWq0lWuMiBxBN6UQHKiSKIMhiGBWDAwSfn7bkDjcYPywi2WyqezwXUhMtw==
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=mi/gImpOLd9Vo3dd5/UalDe7biVNbVhfK4iJMHQmZo0=; b=Uu2QSwHS6wragEhTU8mlAETDRvxce8oFOrNmmYvTJrhMQEjc7IGdmJAlTYoaRviqqulFKFSuf2tHW2RsswJQVSgpbtABmbLjH81nUC+5drsltCb/0+/E4MtEJL4cC+jX4iL7wol+D6dRKgtjg3/BrqWcvPuxBbwa7VAknRyAaTuJ3hoR0uzJdcsnAmy9YaEld9rgyovhBbqkhceouPgSYrzXTqfJtIodgl+6KfkWuHE9dMJzwMWuMWYd+Dpr3R1xtqqsI5+DsszkHNlpSF1UkXShGg8UvAvPc02h248A3aF6JuDHsIKlvTpYS70aqzkv+S/d/PEDM8hm2ZaytHEisw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mi/gImpOLd9Vo3dd5/UalDe7biVNbVhfK4iJMHQmZo0=; b=hN2d2mtVgBPsjv+ReYu462VtptmxD3S9cCHsUzQ4MOaifpRXZbvJQOLaQW+MGz0x/ovzqWUG5ng/aD/hSb+jZOY25bjXMd7JU2Oa96OBIwa/S3fUKqbKUL6t1ajKPC3yMUQOq8GN4CTQqTXt+Mhy/ZzUT2C8VDksftL+2BxOYes=
Received: from DM5PR08MB2633.namprd08.prod.outlook.com (2603:10b6:3:ca::21) by DM5PR08MB2794.namprd08.prod.outlook.com (2603:10b6:3:144::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.18; Fri, 3 Apr 2020 14:01:10 +0000
Received: from DM5PR08MB2633.namprd08.prod.outlook.com ([fe80::c00d:56c3:675e:ec63]) by DM5PR08MB2633.namprd08.prod.outlook.com ([fe80::c00d:56c3:675e:ec63%3]) with mapi id 15.20.2878.016; Fri, 3 Apr 2020 14:01:10 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
To: Martin Björklund <mbj+ietf@4668.se>
CC: "rwilton=40cisco.com@dmarc.ietf.org" <rwilton=40cisco.com@dmarc.ietf.org>, "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>, "warren@kumari.net" <warren@kumari.net>, "netmod@ietf.org" <netmod@ietf.org>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>
Thread-Topic: [netmod] [Technical Errata Reported] RFC7950 (6031)
Thread-Index: AQHWBCEZ+1dLitN/gE+4JTO6Fuc0uqhcjXeAgAAFCACAAAp/AIAKthqggAAbPjCAAAgogIAAACPQ
Date: Fri, 03 Apr 2020 14:01:09 +0000
Message-ID: <DM5PR08MB263377515563D05220D299919BC70@DM5PR08MB2633.namprd08.prod.outlook.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>
In-Reply-To: <20200403.155421.968858617291773287.id@4668.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com;
x-originating-ip: [65.110.221.64]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 9f32a213-58fa-40b4-3fcd-08d7d7d7766e
x-ms-traffictypediagnostic: DM5PR08MB2794:
x-microsoft-antispam-prvs: <DM5PR08MB279428D9289C5918B314D8079BC70@DM5PR08MB2794.namprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0362BF9FDB
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR08MB2633.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(376002)(136003)(396003)(366004)(346002)(39860400002)(66556008)(66446008)(26005)(76116006)(8676002)(86362001)(53546011)(71200400001)(52536014)(8936002)(64756008)(66946007)(81166006)(54906003)(6506007)(81156014)(33656002)(4326008)(966005)(316002)(66476007)(55016002)(2906002)(7696005)(5660300002)(9686003)(478600001)(186003); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1jLjazD7Lartrn6i53ZoKPDLBlvtvecuFucEWqEeAK7VEhpcgsiMZWL2fdbmAZjrgUm5afSQ0PncTYYvqFvWu1WyDMAIkOL6hjnv+LfIkxlN6GkPgNC9wOW1FK85bbH/do4pwL/eNcE2uroxTULlz87sPU76BD4lGzy4qKdsifJvJp7/yn83uPz7xiKWr/wJHAUV6p9nROKqRgdLtBX9jLKqoOqJlifWjXXNYEm3lWWpl5okNKxqGmd9pJZcsb/NO1pRnRDsfws5IWwoLXqhA8xXBEy87Msz3rBN6hmkFxneuj709VyOY0y+7zKiOEb9z7pb+eMN7an5GefhaOBqChsxoWa0Z4NjuIJjCVetF0vbH4v4PrNW6zBpqOKXER02+7L9qXXEJevUvak2kDSDReouTFhtVid1rfRT5ja2JRCbIfXyocEP5jxk7mmLVQoaq9MQB7VhM7mk0ndQGiKqPPrDdwmHQ5nw76EMv19rSR7ie7F7NKykI6CUdeJVAnrUYDji9uQLK0cxxhH3Ds84Vw==
x-ms-exchange-antispam-messagedata: tbQqHO8Q263ZANGF7x8uwvCubt0oJcSztqzDBbxhhCnSiwluyz+p5zhVqCxovxRzqXqP4/Xjv77rvu64wDNo08fPGsvxlZygp/x7vYdhjQdtg9XxIiTurmuQCuubuanaInVjTqx0uEA1cp28A4rnkg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f32a213-58fa-40b4-3fcd-08d7d7d7766e
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 14:01:10.0042 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9s9ljCYe5bPTdC5WfjsZuKS+M2gO7Q3MNnXWTWG1B3C+t1HmDBUQQ9sEG5wyrtyrG+yGTzqRB552bZSPv0mfwg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2794
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/LsP6JlFYmcERjE4Av9F4dNFdo1A>
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, 03 Apr 2020 14:01:17 -0000

Hi Martin,

I believe you that the technical "value space" doesn't change, but that leaf would suddenly accept more values than it did before right?  I'm wondering if we want to follow the "spirit" here, or stick with the "value space" argument. 

I'm not really certain what the implications are (and maybe someone has an example of why it is better to allow it?) but overwriting require-instance with 'false' doesn't feel right.

Jason

> -----Original Message-----
> From: Martin Björklund <mbj+ietf@4668.se>
> Sent: Friday, April 3, 2020 9:54 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
> Cc: rwilton=40cisco.com@dmarc.ietf.org; j.schoenwaelder@jacobs-
> university.de; mbj+ietf@4668.se; warren@kumari.net; netmod@ietf.org; rfc-
> editor@rfc-editor.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> 
> Hi,
> 
> "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> wrote:
> > I don't think we should allow overwriting a require-instance true with
> > a require-instance false in a derived type. It seems to go against the
> > spirit of avoiding expansion of allowable values.
> 
> As I wrote earlier in this thread, the value space doesn't change with
> require-instance.
> 
> 
> /martin
> 
> 
> 
> >
> > From section 4.1 of RFC7950:
> >
> >         Derived types can restrict their base type's set of valid values
> >
> > And this text in section 7.3.4 implies that derived types only do
> > further restriction:
> >
> >     If the type's default value is not valid according to the new
> >    restrictions specified in a derived type or leaf definition, the
> >    derived type or leaf definition MUST specify a new default value
> >    compatible with the restrictions.
> >
> > Going the other direction (overwriting with require-instance true)
> > seems OK to me.
> >
> > Jason
> >
> >
> > > -----Original Message-----
> > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Rob Wilton
> > > (rwilton)
> > > Sent: Friday, April 3, 2020 8:06 AM
> > > To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;
> > > Martin
> > > Björklund <mbj+ietf@4668.se>
> > > Cc: warren@kumari.net; netmod@ietf.org; rfc-editor@rfc-editor.org
> > > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Juergen
> > > Schoenwaelder
> > > > Sent: 27 March 2020 16:13
> > > > To: Martin Björklund <mbj+ietf@4668.se>
> > > > Cc: ibagdona@gmail.com; warren@kumari.net; netmod@ietf.org; rfc-
> > > > editor@rfc-editor.org
> > > > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > > >
> > > > On Fri, Mar 27, 2020 at 04:35:44PM +0100, Martin Björklund wrote:
> > > > > [re-sent w/ correct address]
> > > > >
> > > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > two comments:
> > > > > >
> > > > > > - It is unclear to me whether this really qualifies as an errata.
> > > > > >
> > > > > > - If we add this, then there should probably text about which
> > > > > >   combinations are allowed. For example, for pattern and ranges,
> there
> > > > > >   is explicit text that says further restrictions of the value space
> > > > > >   are possible, bot not expansions. If we follow that logic, then
> > > > > >
> > > > > >   typedef a {
> > > > > >     type leaf-ref {
> > > > > >       path "/some/thing";
> > > > > >       require-instance true;
> > > > > >     }
> > > > > >   }
> > > > > >
> > > > > >   typedef b {
> > > > > >     type a {
> > > > > >       require-instance false;
> > > > > >     }
> > > > > >   }
> > > > > >
> > > > > >   might be illegal since b has a larger value space than a.
> > > > >
> > > > > The value space of b is the same as for a. "require-instance" doesn't
> > > > > change the value space; it changes semantic validation of the given
> > > > > values ((see my mail from 17 Mar, "Require-instance problem").
> > > > >
> > > > > /martin
> > > >
> > > > OK. If we consider require-instance a constraint and not a
> > > > restriction,
> > > > then the motivation for this errata is at least
> > > > confusing:
> > > >
> > > >   Since no one argued against this understanding, this errata changes
> > > >   the text to the same form as in other restrictions applicable to
> > > >   derived types.
> > > >
> > > > Simply put: Do you think it is OK to overwrite a require-instance true
> > > > with a require-instance false in a derived type?
> > > [RW]
> > > I'm not sure, but going in the other direction seems plausible.
> > >
> > > E.g. you start with a typedef that is explicitly require-instance
> > > false that is then
> > > refined by a typedef to be require-instance true.
> > >
> > > Regards,
> > > Rob
> > >
> > >
> > > >
> > > > /js
> > > >
> > > > --
> > > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > > > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod