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

Balázs Lengyel <balazs.lengyel@ericsson.com> Wed, 08 April 2020 08:27 UTC

Return-Path: <balazs.lengyel@ericsson.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 ABB133A0D0A for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2020 01:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.268
X-Spam-Level:
X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-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=ericsson.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 btpsHNURGpHf for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2020 01:27:56 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40078.outbound.protection.outlook.com [40.107.4.78]) (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 61EAB3A0D06 for <netmod@ietf.org>; Wed, 8 Apr 2020 01:27:56 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TtFnpY0lXr4ba4LStMMbIFtYnLZRHgp4hxs7wRQx/lB1k2zqXgnWm4QKRQrB96QVPvhD/W2kdPvxfvfcXvJZ92YIBmEB6to4fyF50lRSqCmuV9GyAhrAsANZPTV2uuL5G9y4PSHePWDg0DzhJSGHG64rFvq2uded4XTBZrpYmOnqGegIv5Hhjn0EIBTmhK6vw9WLEHY/sQeWGutNubDiUuURWNonUjA9jss6R+9vFYn6aPxWamr/b/s7Gf7b36wvV2byHDBAl9Xh1aRcHTxY2ok9u3/1lH4/xAE7MH6/9EAsoWKtdp/eU2gpvx33/oYP8906zpNAaDnFpg4F9LCwIA==
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=paLZFAoOLo/LfSJdYRAHB7mx9wMjnMwxDat/88a2tws=; b=Y4059+1jwjuAGhwsxPFIjmgWg4DYrkAtJJaviA+oY777G+Hrejh1KoRfQnzKYiekdfHkxMjN30vN3xge1lxrDyKCtwvVUAtpxdnSS8dTyugJmexubNumAJXq63IDixebTg76UNh0ooXvuc3z5e0Tlz7XL0YQWyj/yOCfbb9gzJmf0VSWXrj/8qmHPS3hjeRxa/2hmdNfrRwuvX2992egGAzHO+eufM0kS739hM3St9buyuR8zdDwHh7TQA4I3L6RcE7PkZNhSE1jbLLyb9ccd27RXtTKatMvtP/oTVDi9FBwnOfnYGW8lfbu61ZOelke5XRGrKdOCTkgq6BI3oosMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=paLZFAoOLo/LfSJdYRAHB7mx9wMjnMwxDat/88a2tws=; b=e4QrWxaXvn7o7nmI1YkVLyyb04KTjp/b+CkQ3d3qiyzIaXduamsv71mXH60JquraOTqpMks09qpKsncWYNhEcE3+xB3HTVeD31NHDs8T9tbf/ARm5ZbSH8KbAPT/56m0KstGkXoY151N+4YqUvnlPfC6qMpJw4M2FHw0jAYeQtc=
Received: from DB7PR07MB4011.eurprd07.prod.outlook.com (52.134.97.155) by DB7PR07MB3961.eurprd07.prod.outlook.com (52.134.97.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.14; Wed, 8 Apr 2020 08:27:53 +0000
Received: from DB7PR07MB4011.eurprd07.prod.outlook.com ([fe80::a07e:3b6:fa05:3b37]) by DB7PR07MB4011.eurprd07.prod.outlook.com ([fe80::a07e:3b6:fa05:3b37%4]) with mapi id 15.20.2900.012; Wed, 8 Apr 2020 08:27:53 +0000
From: Balázs Lengyel <balazs.lengyel@ericsson.com>
To: Martin Björklund <mbj+ietf@4668.se>, "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>
CC: "netmod@ietf.org" <netmod@ietf.org>, "rwilton=40cisco.com@dmarc.ietf.org" <rwilton=40cisco.com@dmarc.ietf.org>
Thread-Topic: [netmod] [Technical Errata Reported] RFC7950 (6031)
Thread-Index: AQHWBCEaiCiZ2sgM9kikrn4tE8QlqqhcjXeAgAAFCACAAAp/AIAKu06AgAAX5wCAAAZLgIAAAeaAgAAOQICAABnTgIAACK0AgAQORgCAAA4zgIAAQcyAgALuEgA=
Date: Wed, 08 Apr 2020 08:27:53 +0000
Message-ID: <DB7PR07MB4011359C1CF4CB6110F941B0F0C00@DB7PR07MB4011.eurprd07.prod.outlook.com>
References: <20200403165538.2lk4x5j32e3ctl4t@anna.jacobs.jacobs-university.de> <0a546588-6f87-3362-17da-37de8ea08956@cesnet.cz> <20200406074235.o6gkpjsim77xfzv7@anna.jacobs.jacobs-university.de> <20200406.133805.1967759410136484672.id@4668.se>
In-Reply-To: <20200406.133805.1967759410136484672.id@4668.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
x-originating-ip: [80.98.254.17]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 84c9c603-4bb5-4644-d683-08d7db96bbc6
x-ms-traffictypediagnostic: DB7PR07MB3961:
x-microsoft-antispam-prvs: <DB7PR07MB3961EE2867FB89AC08868E8EF0C00@DB7PR07MB3961.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3276;
x-forefront-prvs: 0367A50BB1
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB4011.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(136003)(346002)(39860400002)(366004)(396003)(66556008)(2906002)(66446008)(4326008)(81156014)(8676002)(6506007)(66616009)(5660300002)(66946007)(8936002)(53546011)(99936003)(76116006)(71200400001)(66574012)(26005)(316002)(30864003)(54906003)(9686003)(7696005)(86362001)(52536014)(186003)(66476007)(33656002)(81166007)(55016002)(64756008)(478600001)(110136005)(966005); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: oqqxr1pL1FjahJw0JNBX8BajBaB/oFMxTLs20lxZPeQXPXmxAFetNkmSjepok/74jH5E5M1RbokONNfkR95/e4OXALOubgMURXRuqLsTjFhkLNlmoD7ZoR+Uja4aYiaGbo4zgs5+IIdXpGVfGZOK2J1ca01HaOGYBZ5pq+GKG3heFkRyV02NibFycMs38Vbsqhy/oTB5LN67FctbAoRqAB2LO9zNGCcW5bxeuoP0kW11V35eoFMKtZ54jxsFrFVq/8X3ZDuU2uA1j3AKKcaOfoBfHIn5Vs/1D5lwNZ0ZnNThpF2HT96oRyLTGo/w+xJCueMAzKwTTqE7UGTr2syNZec/85oa2hMsjljyBSjsafDemQmnXeEVfL40aqOpDsSnVj95IRL0TS+ig05iy9iKEkcUBKP37FtArvgWrgnFDZCbqs7OnMrktONHuX6MN7Fb2R9nq4lFrXaNmqlY2fEnVqiW+BoswjH96B57zonCj6v6o4V3zE0ntuUa05LEgdneGJkZ/azxDiI8rTMiOmSMdQ==
x-ms-exchange-antispam-messagedata: xKhvtrro/so+smpQX0ulnX8vlaAdhzDsG1f5UvcsraoyQcr/7vawSWw6etdXSitbR1TKJArRF1EkW/T62jV/GJoGk7RzLJWUBmCPwfb/X/7CYlja4GX/LdjZCTKlEa9ZGd4TtqRmvcU/kru8HDQ36Q==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0254_01D60D90.5BB94AD0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 84c9c603-4bb5-4644-d683-08d7db96bbc6
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 08:27:53.6972 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3MwlzzQX+ztBkJeenVHdCFWDT37Sij3BvhPVmd8wSq6P6QYsMbvZavM0KMqxcej55ni3F5aoyEBrIZCkAEexISwlzBZLyCZFgS567wv9gb4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB3961
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/BkuFBTsFj9UqXQjRL5vAG5A3uyQ>
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: Wed, 08 Apr 2020 08:28:00 -0000

I would like to allow require-instance in derived types (done in errata or
any other way) because we allow other constraints to be changed. Regularity
of YANG is very important for me. Learning YANG is difficult enough without
adding new exception cases.

Also as I consider this undefined, it is better to document whether this is
allowed or not. This is a binary decision, either/or. If setting it as a
YANG language rule is to strict, we still need a guideline at least for RFC
authors, shall we consider it a problem or not? 
Balazs

-----Original Message-----
From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Björklund
Sent: 2020. április 6., hétfő 13:38
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org; rwilton=40cisco.com@dmarc.ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Mon, Apr 06, 2020 at 08:51:46AM +0200, Radek Krejci wrote:
> > Hi,
> > I just want to emphasis, what are the consequences of the option 1. 
> > This way, the tools are allowed to not accept require-instance in 
> > derived types, so actually schema authors SHOULD NOT use 
> > require-instance this way. Since there is at least 1 YANG model in 
> > RFC (8639 and I would expect more), which has require-instance in 
> > the derive type, errata will be needed in this case(s).
> >
> 
> RFC 7950 says in 9.9.3:
> 
>   If this statement is not present, it defaults to "true".
> 
> This means that require-instance is 'on by default'. Hence, it is 
> necessary to use what RFC 7950 calls a 'restriction' (9.9.1) to 
> effectively _remove_ what seems like a restriction (or constraint).
> (This text apparently has already been in RFC 6020.)

I think the correct fix is to change the text so that "require-instance" is
not classified as a restriction and keep the default.  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.


/martin

> 
> 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.";
>         }
> 
> What bothers me here is that I find the design of the default 
> behaviour backwards. If the default would have been
> 
>   If this statement is not present, it defaults to "false".
> 
> then require-instance could be used to add a constraint in derived 
> types but not to remove it (like the other type restrictions).
> 
> If people were to agree that the default here is wrong, can the 
> problem be fixed?  Likely not since changing the default (even in say 
> YANG 2.0) could have drastic consequences and would essentially 
> require to be always explicit about the require-instance property to 
> be on the safe side.
> 
> /js
> 
> > Regards,
> > Radek
> > 
> > 
> > Dne 03. 04. 20 v 18:55 Juergen Schoenwaelder napsal(a):
> > > I propose option 1) and add an issue on yang-next (if not already 
> > > there yet).
> > >
> > > /js
> > >
> > > On Fri, Apr 03, 2020 at 04:24:35PM +0000, Rob Wilton (rwilton) wrote:
> > >> For the errata, it looks like there are two choices:
> > >>
> > >> 1) We reject this errata, on the grounds that it is unclear on what
the behaviour was expected to be.  It is left unspecified as to whether
require-instance is allowed in a typedef.  We add an issue on the YANG.Next
issue tracker to sort this out in a future revision of YANG.
> > >>
> > >> 2) We agree on what the expected behaviour should be, in which case
it may be possible that this can be "Hold for document update", although it
still seems questionable whether this really fits as an errata.
> > >>
> > >> Regards,
> > >> Rob
> > >>  
> > >>
> > >>> -----Original Message-----
> > >>> From: netmod <netmod-bounces@ietf.org> On Behalf Of Ladislav 
> > >>> Lhotka
> > >>> Sent: 03 April 2020 15:52
> > >>> To: netmod@ietf.org
> > >>> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > >>>
> > >>> On Fri, 2020-04-03 at 14:01 +0000, Sterne, Jason (Nokia - 
> > >>> CA/Ottawa)
> > >>> wrote:
> > >>>> 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 agree with Martin here. Moreover, if such a derived type is 
> > >>> added, it doesn't change anything related to existing data, 
> > >>> because they use the base type as before. New data nodes may use 
> > >>> the new type but no confusion can arise - their type has
"require-instance false", which is correct.
> > >>>
> > >>> Lada
> > >>>
> > >>>> 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
> > >>>> _______________________________________________
> > >>>> netmod mailing list
> > >>>> netmod@ietf.org
> > >>>> https://www.ietf.org/mailman/listinfo/netmod
> > >>> --
> > >>> Ladislav Lhotka
> > >>> Head, CZ.NIC Labs
> > >>> PGP Key ID: 0xB8F92B08A9F76C67
> > >>>
> > >>> _______________________________________________
> > >>> 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
> > 
> > 
> 
> 
> 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103
<https://protect2.fireeye.com/v1/url?k=58bd6cd1-04696b7d-58bd2c4a-8667c4afe1
3e-71a13094f514c718&q=1&e=191787dd-7c26-48db-93a5-c2bba7224ee6&u=https%3A%2F
%2Fwww.jacobs-university.de%2F>
> 
> _______________________________________________
> 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