Re: [Idr] Debate about IANA assignment policies for BGP-LS registries
"Acee Lindem (acee)" <acee@cisco.com> Thu, 19 November 2020 14:27 UTC
Return-Path: <acee@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD5E3A0976; Thu, 19 Nov 2020 06:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=b+n8Tgle; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Zg5HChn2
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 pkzjrGkCNyfF; Thu, 19 Nov 2020 06:26:58 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0232D3A07C0; Thu, 19 Nov 2020 06:26:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7152; q=dns/txt; s=iport; t=1605796018; x=1607005618; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MhPUPpDJKZMOw+JOS3BFlwZEAcu2CmXeE073PRrMXSM=; b=b+n8TglejY1hgMsIXhsu2fE6J8kH78qDipGRyNkNqcUVucpOQwjTMTqX TsZKnsZ5SMM3BdbdLvNLQYbna9J7xUCewP4hBm2I+aLn9njHuEEGWryfP 6XQ++eg/dkHJfSXchH3+6C8S20ERWxOTthJ0UOlYX+ekB1y8j5boGlyOt A=;
X-IPAS-Result: A0DzCABOfrZffYgNJK1igQmDIVF7WS8uCoQzg0kDjTYmmQOBQoERA1QLAQEBDQEBGAsKAgQBAYRKAheCEgIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYY8DIVyAQEBBAEBEBERDAEBKQECCAMBCwQCAQgRBAEBAwImAgICJQsVCAgBAQQBDQUigwQBglUDLgEOpA8CgTyIaHaBMoMEAQEFgUdBgwwYghADBoEOKoJzg3aGVxuCAIEQAScMEIFRUC4+gl0BAQIBAYFCGSaCcYJfkHcDgnKkTAqCbYkSkggDH6F8k1SLAZVYAgQCBAUCDgEBBYFrIYFZcBU7KgGCPlAXAg2SEIUUhUR0AjUCBgEJAQEDCXyMOwGBEAEB
IronPort-PHdr: 9a23:D5kKvhxv0bnJTVHXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5ZRaDt/lohUXCG4TW9/wCjPDZ4OjsWm0FtJCGtn1KMJlBTAQMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8r7bkfZ5Hy/8TBUHQ/wZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jBDOpyhF
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,490,1596499200"; d="scan'208";a="594303945"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Nov 2020 14:26:57 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AJEQuZ6027002 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Nov 2020 14:26:57 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 08:26:56 -0600
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 09:26:55 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 19 Nov 2020 08:26:54 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=muhnfgwbxjs8AMw2eTFRCSTqeSJUjglFYNCVNbO4IOPDo9OpG/nvtkQ0IWbjh7of21GGZrljD+RZT0Nez0XMCRxxjOYt2zz0iZcTHEr7znqRxvMvz2uOn36bw3QAhzjip4SaU9gWVICy73TwrvpW8lPCRnp3yoM5BQjHDE1b1KDfvI4qzP67yrhyAeLLrSwZXBn3c+MfQleEdQA2zHhT2jAh7XkfLJBeUV09OfooC+JyVDkpcd/8v1UXogbL439z4x9s18eBHH6WPsoQCt89E4XIB3p1eyQ21khPa4Mfz7hRBt94cQpn4Byz9RheHz5OK3qXp2h5drEBFLmA3t811g==
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=MhPUPpDJKZMOw+JOS3BFlwZEAcu2CmXeE073PRrMXSM=; b=NqFCB3UyW05T8cftAUf3NS/aN29mZbl98tItOa38wueR0dnDvBni60OTIaika2W5uq1rGdQf5hf0iKiyv4alMg3aNCkPprPOPbiPVffIX5iWVPhlN7PVwX3qFKc7VrLJatoJQhG++pWmwKfM3oMibx/Vvf9+pbxDz4qUWxhp+TUx1XZRBRF//BXgaeORND2JL9YXXld9B+whUb46zCgter2HwNeFDcJXAZiC+lVJRTms3OXuyS6gN05DMTkhxvN4k7H1fz1V8ikus2bF7prcGERWYwygQMPfo4l3ETX3YY7ZsOZEymQUkwyOB+3bl9BLWj0jcjlI0DvCKR36JP7juA==
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=MhPUPpDJKZMOw+JOS3BFlwZEAcu2CmXeE073PRrMXSM=; b=Zg5HChn29imxuuhaWVGc3AahDEExNCH26hH6CqxQrQ8AHvWSWz6g2TUrRJDXG9FQ/GZIiL0/6RDA7rPXPckyI5uBfiHwXs5Pi8e52OGIoT/azhRB12DpM1IUq7Y910qh4Fa2nXletkPbtOqVeVeZy0zAl2cyqfKCy1wmXXQQXYE=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BY5PR11MB3879.namprd11.prod.outlook.com (2603:10b6:a03:18f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.28; Thu, 19 Nov 2020 14:26:54 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3564.028; Thu, 19 Nov 2020 14:26:54 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "idr@ietf.org" <idr@ietf.org>
CC: "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Thread-Topic: [Idr] Debate about IANA assignment policies for BGP-LS registries
Thread-Index: Ada+PLvU3A9NOlUuQcaKnNPgaE0wUQAOlcqw//++FYA=
Date: Thu, 19 Nov 2020 14:26:53 +0000
Message-ID: <1FD5175C-FBA0-4CE6-9091-057634527EEA@cisco.com>
References: <080401d6be4d$91edfa60$b5c9ef20$@olddog.co.uk> <MW3PR11MB45704DB8548E20926EADF62DC1E00@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB45704DB8548E20926EADF62DC1E00@MW3PR11MB4570.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.43.20110804
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1eb0d82a-42d0-466c-f0f2-08d88c9729bd
x-ms-traffictypediagnostic: BY5PR11MB3879:
x-microsoft-antispam-prvs: <BY5PR11MB3879D14492FD880FFC31D14EC2E00@BY5PR11MB3879.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: L8ISEHhfdUv1iToB0J5HEgIvl0tV/TDBTYrzXqnPQgDxJ2cFjkLdSeFwlrMcvEXGy6h8X4znKv/sVHmbUUSfVOWFRDe7H6C31jKqcJwCauZCVfwxBRY0zLOFoCTLft8lIOoyF5992ioLD+Ih4uRz9ThClX8F6az0xmV+VPGnTE5yDiNSA9iGIXt6FOpJ3IAPFsI46N4ioPrXzjZBThjdBvBWrTt91o2XCtf9AwVlQMCJYZ5HQi5PI+BE5tQdJ70qQk9/bNyVOc602qbF+CmnGlOaNa3fdmi1zlz2uw2PnZPaADZJeiopte5w3m9Ba8rsOYtyZ0wpmi6XmTCxWbWSl4rGViP83bYg7SXt2RYgZTAzUxesc5Fh4v7fOZGEgxkprv19xcGD75PyLYOPDjxTog==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(136003)(39860400002)(346002)(376002)(66556008)(53546011)(71200400001)(5660300002)(478600001)(6506007)(110136005)(4326008)(91956017)(33656002)(8936002)(64756008)(186003)(66446008)(66946007)(66476007)(8676002)(86362001)(76116006)(36756003)(2616005)(2906002)(26005)(6512007)(83380400001)(966005)(316002)(6486002)(66574015); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: +wPxcZ9lGrGY+zmdRKtl/6aQRyQzJFYwj6QdQ+yCLUh0GnjNFWdSA+jinzIdvz+HyzR3WSCMrGaOPpf5wqIu2NCLqbnUUadrOv776p6932otgK+iH8nFNILhlX64yyWLXH13u7UCHwNG4lDjDPEEmk3XaHp2zBdKM7n7Z/IWI43z77EzZILDAeH60T80ReaU1VpPSqnduEBDZ9i94dPm34ifGuGqqDruMnI82fS7ABcHZfTFIFoLtOtwc6yregBAtdEXnQyV/NWkSEaSBAwEYGPel/krBZzo4KQTa8q/fUC9jR+bbMpHK4VP1YXeTI1u1eSfcB1hKFs42oqoNmFLstU23zO4h/4iMjd3xzYE4908qT+iD4onS5QK7lKyCGeo/A+w3McrCRgDvA5AeTmVWQZzQuw8rVLuZTCtSLlk1w1ZEMcNpTrOzJwsS4k+vfh2S3IfXpRLSHlXK4zBNhDbATnFgBKtvlGztcnqij0YGgVQeMG3OscZgdXDGT7ZhWISckn8v6d1wI5EeqPITe0fJLW6ebDCgtRgJz6f2pqpAi8EWTDyXC973IxEShtNAiYGnDb8NWQ0ELqnnOqrdPH0E7G9Tf2u0ZGhYXMMJjSEB+Yc/5sM9kqXZbYm5OT2Ehwio/0y9Ww/SDace0sjVM+iww==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <681B01A6495979469B2329EBDC033279@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1eb0d82a-42d0-466c-f0f2-08d88c9729bd
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2020 14:26:53.9310 (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: Vyjts/Wf9klKfi9E76gBhZUTYRiWNydMVm1Cc7bvL/pf3j4TBwW/lG//bA/iFcUZ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3879
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/wNG-z23E0SZ48bYXgH3OyMqEIAc>
Subject: Re: [Idr] Debate about IANA assignment policies for BGP-LS registries
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2020 14:27:08 -0000
Hi Adrian,
I agree with Ketan and would vote for #3 - I thought the last thread was just wordsmithing the DE guidance and not grounds for a document reset.
Thanks,
Acee
On 11/19/20, 8:34 AM, "Idr on behalf of Ketan Talaulikar (ketant)" <idr-bounces@ietf.org on behalf of ketant=40cisco.com@dmarc.ietf.org> wrote:
Hi Adrian,
First, thanks for doing this.
You've provided 3 options:
1. Leave the assignment policies and DE instructions in place per 7752 and state that they do what we want.
2. Leave the assignment policies in place per 7752, but change the DE instructions to give explicit advice about Internet-Drafts.
KT> I don't believe the first two options can solve/address the main issue why we went down this path. i.e. the "permanency" point for "Specification Required" in RFC8126 and what is there today in the I-D boilerplate. That is a different battle.
3. Change the assignment policies to be simply "Expert Review" and change the DE instructions to describe what the DE must do.
KT> I would vote for this one. "Expert Review" is what is already there in draft-ietf-idr-bgp-ls-registries. The only change required is the text for DE guidance and for that the text in RFC7370 (i.e. the way it is done in IS-IS) looks apt to me for BGP-LS.
If there is more tweaking that the WG requires, then let us remember that https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/ is following up right behind (hopefully very soon).
The goal of draft-ietf-idr-bgp-ls-registries was to get a "quick point fix" RFC for the allocation scheme for BGP-LS code-points. IMHO stretching it out much further just defeats its purpose.
Thanks,
Ketan
-----Original Message-----
From: Idr <idr-bounces@ietf.org> On Behalf Of Adrian Farrel
Sent: 19 November 2020 13:56
To: idr@ietf.org
Cc: idr-chairs@ietf.org
Subject: [Idr] Debate about IANA assignment policies for BGP-LS registries
Hi,
You may have noticed some recent debate about draft-ietf-idr-bgp-ls-registries on the IDR list.
It is possible that, notwithstanding WG last call, the draft doesn't correctly capture what the working group wanted.
Since I hold the pen for the draft and am one of the Designated Experts for the registry, I will try to set out my understanding of what we currently have, what the document says, and what questions the WG may need to address next.
[For the avoidance of doubt: I'm just trying to serve the WG and clarify the instructions to the DEs, I don't have much of an opinion about this.]
The registries were created by RFC 7752 and currently make assignments according to "Specification Required." RFC 8126 (which post-dated RFC 7752) defines these terms in section 4.6. "Specification Required" includes the requirement for:
- review by a Designated Expert
- documentation in a permanent and readily available public specification
Debate rages about the meaning of "permanent" in this context. Does an Internet-Draft count, does it expire, or is it archived by the tools page?
Does an individual I-D count, or does it need to be adopted first? Does IANA track the I-D version, and if not what does it mean when a new version changes the meaning of a code point?
As Alvaro, our AD remarks, IDR is not the place to have this debate. It is probably an IETF-wide debate and anyone is welcome to take it up with IANA and the IESG.
What we need to do is decide what we want as our policy for these registries to be, and then work out how to achieve it. We can then set the DE guidance (see section 5.1 of RFC 7752) to achieve the right results.
It seems, from various discussions on the list, that the WG (or some of its more vocal participants) want to be able to assign code points based on I-Ds and without requiring to do early allocation (RFC 7120). There seem (to me) to be three ways to approach this:
1. Leave the assignment policies and DE instructions in place per 7752 and state that they do what we want.
2. Leave the assignment policies in place per 7752, but change the DE instructions to give explicit advice about Internet-Drafts.
3. Change the assignment policies to be simply "Expert Review" and change the DE instructions to describe what the DE must do.
The current draft seeks to implement option 3.
I'd note that a secondary issue arises about requests for codepoints arising from outside the IETF. Suppose another SDO or a vendor wants a code point:
Do they have to write an I-D? Does it have to gain adoption in the WG?
The chairs have a slide on this for the meeting on Friday. I'll leave it to them to decide whether there is time in the meeting to discuss the topic, but the agenda was previously full. Perhaps a discussion on this list would be better.
Best,
Adrian
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
- [Idr] Debate about IANA assignment policies for B… Adrian Farrel
- Re: [Idr] Debate about IANA assignment policies f… bruno.decraene
- Re: [Idr] Debate about IANA assignment policies f… Ketan Talaulikar (ketant)
- Re: [Idr] Debate about IANA assignment policies f… Ketan Talaulikar (ketant)
- Re: [Idr] Debate about IANA assignment policies f… Acee Lindem (acee)
- Re: [Idr] Debate about IANA assignment policies f… Gyan Mishra