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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 03 April 2020 16:24 UTC

Return-Path: <rwilton@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 4EE9F3A1AB0 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2020 09:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OABIZsot; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kOjAAeuZ
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 nmXrhF_fF6bE for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2020 09:24:39 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02ACD3A1AAE for <netmod@ietf.org>; Fri, 3 Apr 2020 09:24:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10732; q=dns/txt; s=iport; t=1585931079; x=1587140679; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=zT417oNz3HKuexl2L6WYOj+RHvCL3D9QvxjDIeMrpbQ=; b=OABIZsotiSHjrfGdaAyGtnHqqwlfxqKy+UyoWsghhzsOF2ckPEe0zhPu KrSQG9dq5XgO6h00TJa71C+hut5on6nwuEtrDqqmwIsk/uWWw51TYUoPv WNZ1WphPPA1RjxuRHxVZQN1Uq7I1gOC77L6YE+ZHTxKbQA/zKmj8RznYK E=;
IronPort-PHdr: =?us-ascii?q?9a23=3A35NreBwZhYl59+bXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZufFkz/MPnsRyc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEAABzYode/4wNJK1jAxoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBagIBAQEBCwGBU1AFbFggBAsqhBuDRQOKYk6?= =?us-ascii?q?CEYlujjCCUgNUCgEBAQwBARgLCgIEAQGDf0UCF4IvJDcGDgIDAQELAQEFAQE?= =?us-ascii?q?BAgEFBG2FVgyFcAEBAQEDAQEQEREMAQEsDAsCAgIBCBABBAEBAQICJgICAhk?= =?us-ascii?q?GBgsVCAgCBAESCBqDBYJLAy4BDqQNAoE5iGJ1gTKCfwEBBYUnDQuCDAMGBYE?= =?us-ascii?q?JKgGMMBqBQT+BEUOCTT6BBIEaSQEBAoFlFQomgksygiyRA58aMkcKgj2SaoR?= =?us-ascii?q?YgkyZNI8ygVKKDZA+AgQCBAUCDgEBBYFoI4FXcBU7gmlQGA2OHQwXg1CFFIV?= =?us-ascii?q?BdAKBJ4toLYIUAQE?=
X-IronPort-AV: E=Sophos;i="5.72,340,1580774400"; d="scan'208";a="472988964"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Apr 2020 16:24:38 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 033GObif008973 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Apr 2020 16:24:38 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 11:24:37 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 12:24:36 -0400
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 3 Apr 2020 12:24:36 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nJ2tSNKzNrX4T2rfXSKnL/vPrCoekbiP2lkWcLO+T/AWGAdvvh24HYYdH+aDgwkdgV+qkR4kYeZq3MnSCe1tNRoywnal/nBvi4Im/UzUBWSnPci2/1l2aknWtvFavky/5Lg5XOttThHajTTDZ7BUnUiZ2djqmivntRyo96wm83/Hwn2S37dQYywd2KAWfJY3uSXhtp+Ie9W0wURU3BUBdaVg1YlXom7IXYPfQeruD9s/+5l6FeUD5vBfqgb3awzRrJeSt9vwubc+PyNMlyyHHOGbiKy+Mapx+zkR35xEWqfUbDSUDZN22Ns2MfKxYTt6+HmHakssbT5/BcPiR1rmBA==
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=zT417oNz3HKuexl2L6WYOj+RHvCL3D9QvxjDIeMrpbQ=; b=WPeydWy2dR1UNf7ACyFOw/nS+UN57bGNisqoowJuyXSBjcZAsCctRYLeKo2xdvNQ7KyJdVcI/lQnASPqn8hM38Mfv6DEz3CME0oq3iNjV/ySOgipOlm4UZhSblmGfrUyuGFaGvAW5J5EjjLOFTg0+Bf8Rdv3yTpvvuIGVhr5KjnTx2sSI2RHZ1Ls7MgtifKfROB04wx8tthNdaGrpWjy+l2TOfO/vj10t+vd/WPzSSwkFw72buefpOmj4w+3BFT45qorW0vVWHOUKnAkLO7SKcYbT1bUJ+0fiebCd7txlup1JvDe7jjlVS4Zz39bWFbMwbtqWu/fAxy4ixyiBOXMRg==
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=zT417oNz3HKuexl2L6WYOj+RHvCL3D9QvxjDIeMrpbQ=; b=kOjAAeuZJQeqjrRRrhcEA5LP9mzRAOlG4ElaOTrgO735OYxjIOqKsvDt2DKg6slslTX8MZ3zz0PaRPOEfFVT1nxtFD+gl6vtvAVG+Mqwv1otMBcneWDXYR3dV4Gig+OWC4vxPLJYFK7F+1LJ+6lDQ//9V+/jsLHGb+cMmg4Pq/0=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4480.namprd11.prod.outlook.com (2603:10b6:208:191::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Fri, 3 Apr 2020 16:24:35 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3%5]) with mapi id 15.20.2856.019; Fri, 3 Apr 2020 16:24:35 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] [Technical Errata Reported] RFC7950 (6031)
Thread-Index: AQHWBCEZ+1dLitN/gE+4JTO6Fuc0uqhcjXeAgAAFCACAAAp/AIAKthqggAAbPjCAAAgogIAAACPQgAAQA4CAABcY0A==
Date: Fri, 3 Apr 2020 16:24:35 +0000
Message-ID: <MN2PR11MB4366BB6982E7A530F5654789B5C70@MN2PR11MB4366.namprd11.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> <DM5PR08MB263377515563D05220D299919BC70@DM5PR08MB2633.namprd08.prod.outlook.com> <9c3ee87c0e9d14c8921796c4b53d44620b53a942.camel@nic.cz>
In-Reply-To: <9c3ee87c0e9d14c8921796c4b53d44620b53a942.camel@nic.cz>
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=rwilton@cisco.com;
x-originating-ip: [2001:420:c0c8:1005::2b4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4a5e8cd7-55c3-4927-bf65-08d7d7eb7f92
x-ms-traffictypediagnostic: MN2PR11MB4480:
x-microsoft-antispam-prvs: <MN2PR11MB4480BEC1C54090DE7F53DBF7B5C70@MN2PR11MB4480.namprd11.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:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(366004)(346002)(376002)(136003)(39860400002)(966005)(2906002)(186003)(9686003)(110136005)(66946007)(478600001)(71200400001)(316002)(33656002)(55016002)(7696005)(8936002)(6506007)(64756008)(66574012)(76116006)(5660300002)(66556008)(81166006)(81156014)(52536014)(86362001)(8676002)(66476007)(66446008)(53546011); 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: rXMRAlw2EuR+dJ11m/CNbiOXpnhwwteRJ0NXTqCDwrpHVvzTJp1/mRzZ0pNUou3kcfq8qQOg2AnGZS+znX8S2Fd5L6jvmN1qrvJGBpgQlCyjsn7JeR7AUplrXCrjoIdZx5zeJR47f6uAs5vtsEuui/zkkYF4OQs5+MatAuTaryql48hYBN/kyQ3zgfysl1UbQisQC5CdYXj86n/0LHdkf1GBMHbwZGhBRMdhbcjbPMtOUsQfTLzODT2bKRPGSxdsu47uvbfxuE6hEY1eelb/ChemQ6c8yswKY9t22JXYS0VvcTe3FoB5Rk9lIbrT1rNHc4WEZgJffqaxTWjHkMnrA8JSbE99mafOUzuyBJcy8U1AB15wcuELvGLcnhIc+gv0aqg4BkGCnEpcMiTVxvvn6ENZ7gwqV2PAurq2R31p+PnB/oQBBUCCBWTZghlAwf2+1iKfCXFR+mHPAy6t5btAwSwnl5MeHh1YQrIGaIa64koa26MgsO82dQre2teyNTnccCSHX3gg7qCIDZobpUvGjA==
x-ms-exchange-antispam-messagedata: GxOHU25G5f8U/vCmI8zutuGBu6tsCVLOdXHwdvnFN9Ocrd8I3BD8kKkF2V2Rtb4ibEsJ20z27Q7X35jEjzl+De9I5lsmMUCpSF5BHRU79amhfMYnJnfONxp5N+8VbVahcHt0yGC6RCzCzXJm2umlFYoz8ixiSFajGOSJ2W5YCMg=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a5e8cd7-55c3-4927-bf65-08d7d7eb7f92
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 16:24:35.0976 (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: yHYM1x1iqJJZv8kfRqUFDXzi9GVC0RL51PEGF7CL8Ej5a2t5deUVqM/aIZX6qpJIzjPNfxpWVD6fyfXP01FCOQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4480
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/KkIKVEBBSO2YeKiNnSIzlJ25eAg>
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 16:24:42 -0000

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>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