Re: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc8203bis-07: (with DISCUSS and COMMENT)

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Thu, 15 October 2020 05:49 UTC

Return-Path: <jheitz@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 EC46C3A12C1; Wed, 14 Oct 2020 22:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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_DNSWL_BLOCKED=0.001, 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=ltSD9axK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=M/EvOW9r
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 MBGsgcYET75U; Wed, 14 Oct 2020 22:49:14 -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 724ED3A12C0; Wed, 14 Oct 2020 22:49:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10474; q=dns/txt; s=iport; t=1602740954; x=1603950554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8wofA/WDtqholmzl4PG0j4qCLahdSXyPQ08XyTGCEXk=; b=ltSD9axKn3JxwzuQp0emrIH0yRYZyDT8fl2TyzkdIc+NLq2TG174Xf7V 7YE+Qj/jBNfnXpbZyYvYginUPgAZFUuMOSYJJBAg8IKAQjuERXdls9Qyj bqtcBzEAvQrIYpHAvB6cHJJp5WTSGP6/o7ThHRLTb6RIgrTLKbmjf2fSX w=;
IronPort-PHdr: =?us-ascii?q?9a23=3AEa00sxyQvlr6hqzXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWBt/5qi0fER5qd6vQXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoOk9SAMvkeBvTpC764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAAD/4Ydf/5hdJa1gHQEBAQEJARI?= =?us-ascii?q?BBQUBQIE8BwELAYFRUQdwWS8shD2DRgONUYECiQ+OaoEuFIERA1ULAQEBDQE?= =?us-ascii?q?BIwoCBAEBhEoCF4FvAiU1CA4CAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEDARI?= =?us-ascii?q?REQwBATcBBAcEAgEIEQQBAQECAiYCAgIfERUICAIEDgUIGoMFgksDDiABDqB?= =?us-ascii?q?iAoE5iGF2gTKDAQEBBYE3Ag5BgxQNC4IQAwaBDioBgnGDboU4gR4bgUE/gRF?= =?us-ascii?q?DgU8uGzU+ghpCAQEBAgGBHQkBDAYBCBuDFTOCLZAJJDIBAoIwATyjUlQKgmq?= =?us-ascii?q?JBIxfBIUpgxWKCIVGjmOeHIJskkwCBAIEBQIOAQEFgVUBOGdYEQdwFYEVgg9?= =?us-ascii?q?QFwINiHeFKDeDOoUUhUJ0AjYCBgEJAQEDCXyLB4FmXwEB?=
X-IronPort-AV: E=Sophos;i="5.77,377,1596499200"; d="scan'208";a="583099143"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Oct 2020 05:49:13 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 09F5nDG9005727 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2020 05:49:13 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 00:49:12 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 00:49:12 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 15 Oct 2020 01:49:12 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IYHpG8PKMztzXn02dIYHjPVjLcrPsK04gdbQHC/npxGqghQD6Gi3lfpXAaVGxG2qXJtLTQ1+0NaF6c+YpFKAS89Ira9A29H86TdLcJ5hthVbNEwNSLczOHfM87sWNfk6CaKMAQ/aHy7Iy5tXTQJo6GXkRviAvaYKSZ7HTWkuv7qxIKfo1fZUDZA7+OlFA6ljD3tifcLLZCip1U7YjYfMZkPzEI+Wkb7iPuK/G+FGjR5UwwcC67LhoQqnsAlGIF2deSU7HOB+IarGZwkkrxteKCCca/oJcH3VBKEIS35abMoDPc5cunJ062PdCK0SA6lYOAj7w7QdPLCw6UEBWikiiw==
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=8wofA/WDtqholmzl4PG0j4qCLahdSXyPQ08XyTGCEXk=; b=CW6EA7Y/jxdX5nIwFquym8gxV9AW/TbBOb71AItZ9rWHeYIf4d9FGZUmOD5jflMTpVfo4dbSHYgnGNmoDLF8JPjpazpbE9M3D6b0DjDbTFS3a7FhASH9yWwlLmZh48lo3xFqdXuFEvx3pR2QEQ6No2mGarIHlUNjStuv90XvI17AxVu76H2HjVIV6Mm10avgWhpEli8qPdNE/wAHWcEzQv6V/UWOJXh5hZTgtC4gmcQ4LMoihXPhCXFOZZKODxQVCk4pdg3bMJOAbXW2sOy2IagXogc3L/pvtQcfrKNQ5TGuv10VbtHd/xczmJAO2bQB8lxjaxkJaNvSfTScCgHoiQ==
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=8wofA/WDtqholmzl4PG0j4qCLahdSXyPQ08XyTGCEXk=; b=M/EvOW9rz/pwBSCWNa8FNJAJUxQCbS7u9hIvVp11Zb2yaKAF8x7+A5JbuIPyYXsu52UDFo5NQjfN38bpffazsZJYQxB9fWcHsYZN2oguD74iEOLveSqsYKzBtpfcC0dmWDGXs8n9g8XDixcT6q7LXPgIPexaOAbwV/BevRSRmAo=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB2552.namprd11.prod.outlook.com (2603:10b6:a02:c7::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Thu, 15 Oct 2020 05:49:11 +0000
Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::718c:ac63:d72e:f3c9]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::718c:ac63:d72e:f3c9%4]) with mapi id 15.20.3477.020; Thu, 15 Oct 2020 05:49:11 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Alissa Cooper <alissa@cooperw.in>
CC: IESG <iesg@ietf.org>, "draft-ietf-idr-rfc8203bis@ietf.org" <draft-ietf-idr-rfc8203bis@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Alissa Cooper's Discuss on draft-ietf-idr-rfc8203bis-07: (with DISCUSS and COMMENT)
Thread-Index: AQHWnQdoQAdTOQupHUKqT/naq5NLQqmM39qwgAAROgCAADB+AIAAhYAAgABCj3CACkm4wA==
Date: Thu, 15 Oct 2020 05:49:11 +0000
Message-ID: <BYAPR11MB3207A937EA888BCD362E3E3DC0020@BYAPR11MB3207.namprd11.prod.outlook.com>
References: <160211580198.31310.1253552691445772469@ietfa.amsl.com> <BYAPR11MB3207D6A626288B19FC942171C00B0@BYAPR11MB3207.namprd11.prod.outlook.com> <D8FB407E-6B24-452E-AADD-B76A52245329@cooperw.in> <BL0PR11MB3202C971AD064197DDE1BC48C00B0@BL0PR11MB3202.namprd11.prod.outlook.com> <A4C6AFC5-9F7B-4E38-A4FA-91349D0A2BB2@cooperw.in> <BYAPR11MB32072FDAFD60D5CFCEEE9A8AC00B0@BYAPR11MB3207.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB32072FDAFD60D5CFCEEE9A8AC00B0@BYAPR11MB3207.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cooperw.in; dkim=none (message not signed) header.d=none;cooperw.in; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:e075:10f3:651b:166b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 10d916cc-d8e6-4bdb-0ecd-08d870ce0a59
x-ms-traffictypediagnostic: BYAPR11MB2552:
x-microsoft-antispam-prvs: <BYAPR11MB25522111C5DBD8616AB100C8C0020@BYAPR11MB2552.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: 6Id0u8ofuO/34skaa3HaZ4J3a9fu/Aeg69Cf/YsgEKNSme20LmRJxnC9bzJyNpqh+Z75mVGpV4ts43JgSeT/pQI56rhguqwXpZA5ht19hl1KHRhkAhlUZyFriz+B1IXXviq7WihE0Wb4PpYO4IfrOxAbGDu8rkLybH0EbwGehUOoAUu3Xzncwf8raJ8UHPp5i9EeS1Fw4SWDDKjgPDFf0Bk/57Nlzf+kL22BJuM4B01Mq7MZuDW3SfKZMeRNcRM7Udz6RjyC3UtniifNIDuOIP796zsWeCp7HlfOZmU1V42+oYnngyZOy/TXTPMhEavE+i8jHE46s1We4pH1PToZksduzVrpUW6e6RrIqpVkLkqDr0uLAN/sK+g2Y1UBtVuanYH8Y/EP7Xb9JzChvV1uVw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(39860400002)(396003)(136003)(346002)(4326008)(316002)(5660300002)(66574015)(8936002)(86362001)(2906002)(55016002)(54906003)(83380400001)(966005)(71200400001)(76116006)(83080400001)(66476007)(53546011)(52536014)(6506007)(66446008)(478600001)(9686003)(8676002)(64756008)(66946007)(6916009)(186003)(33656002)(66556008)(7696005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: XktEEicUpvolOICm4ux4gzyEPDqbMEDpDNHDN5JIp3yZt7zR9IdqeOpQsjI1BOk6IkJ6YuYOaU9fD11Xy3jMrj04VAnKnETPBSKDrG4tB+JcLjEUa2M92GDxo3vB1u0tkF+cZR8kv1daDQseofRgEzmd0j39eQO4Qxi53cO8CIS0OtSX617vOxWNmmz2mJbP0xkj4heGQIIpH8RGu2+0S+keBKa98sEt3mkpkD7yXPR9qnysrLTnIDToLCfqOO5eXFj1rNmm797j5nqnTnyVjSd48kECY2/2py6Rdrq92EnkWZ07PEzx5wKuUnM/rOysjyEtwmjILAJvFfpNMnyPc5umIrRRoGze+rQwle5zlKjog+Lx08OtF85zVkVFm7YB7Ngl/HIc0Fs/oWDjYMJx5fCOXbAjy/No4/1HN6TndY/TOkXhkUGoyjxKvxHXIP6mrhDm8WE2ePPgBrYtBVDP6w98gBTTgZ2ZIUDyH084fai6JCYtbCnXOMO0RXfzn/PMfaoiVc+Lya/X3mwjY9w/FJEXm/jsHQLLp4CNsgii/PftG/zUwK2TCeS4o+5h4uCvkvRwFPXe9ZZput9CoQfJH+CYeaVV4AbApxwF1PT7cVNMKjN5c3QxvaLpFCgvB5x3XATLAjbGxqAxkhg2rL76uSx/L+wJpjCBB/9KMUR+qK9z/jekAqbyOZgPczcdAwzWRzVj/3SqLzp7hmqTXr69Qg==
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 10d916cc-d8e6-4bdb-0ecd-08d870ce0a59
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 05:49:11.1188 (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: bh6iC6xE5WPifLDU6KMCoIzNHYakPQk98hSaPlPB3z+3qLXYTPzeqsVyl2Db+6RmXKBHOI5QuxUIS6eqECZeRw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2552
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XdQgmP4exyHNxhlh0JE9vbgYFxQ>
Subject: Re: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc8203bis-07: (with DISCUSS and COMMENT)
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, 15 Oct 2020 05:49:17 -0000

Updated.
https://tools.ietf.org/html/draft-ietf-idr-rfc8203bis-08

Regards,
Jakob.

-----Original Message-----
From: Jakob Heitz (jheitz) 
Sent: Thursday, October 8, 2020 9:55 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: IESG <iesg@ietf.org>rg>; draft-ietf-idr-rfc8203bis@ietf.org; idr-chairs@ietf.org; idr@ietf.org; Susan Hares <shares@ndzh.com>om>; aretana.ietf@gmail.com
Subject: RE: Alissa Cooper's Discuss on draft-ietf-idr-rfc8203bis-07: (with DISCUSS and COMMENT)

The way I would see this happening is that any vendor that implemented
8203 could very easily upgrade by just changing a single constant in
the receiver side code. Then a compiler warning would prompt them to remove the length
error check. For the send side code, I would put a warning message at
128 and limit at 255.

I don't see 8203 being out in the field for very long with
the 128 octet limitation. During the short time that it does exist,
there may be some confusion, but no disaster.

Regards,
Jakob.

-----Original Message-----
From: Alissa Cooper <alissa@cooperw.in> 
Sent: Thursday, October 8, 2020 5:43 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: IESG <iesg@ietf.org>rg>; draft-ietf-idr-rfc8203bis@ietf.org; idr-chairs@ietf.org; idr@ietf.org; Susan Hares <shares@ndzh.com>om>; aretana.ietf@gmail.com
Subject: Re: Alissa Cooper's Discuss on draft-ietf-idr-rfc8203bis-07: (with DISCUSS and COMMENT)

This is much better, thanks. So the idea is basically that the operator might learn out-of-band what message length is supported, or might learn by trial-and-error?

Alissa

> On Oct 8, 2020, at 1:22 AM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
> Fair question.
> Proposed text change:
> OLD
>   If a Shutdown Communication longer than 128 octets is sent to a BGP
>   speaker that implements [RFC8203], then that speaker will treat it as
>   an error, the consequence of which is a log message.  For this
>   reason, operators would be wise to keep shutdown communications to
>   less than 128 octets when feasible.
> 
>   There is no guarantee that the receiver supports either this
>   specification or [RFC8203], so any shutdown communication might not
>   be logged in an easily-readable form at all.  Therefore, operators
>   would also be wise not to rely on shutdown communications as their
>   sole form of communication with their peer for important events.
> NEW
>   If a Shutdown Communication longer than 128 octets is sent to a BGP
>   speaker that implements [RFC8203], then that speaker will treat it as
>   an error, the consequence of which should be a log message.
> 
>   If a Shutdown Communication of any length is sent to a BGP
>   speaker that implements neither [RFC8203] nor this specification,
>   then that speaker will treat it as
>   an error, the consequence of which should be a log message.
> 
>   In any case, a receiver of a NOTIFICATION message is unable to
>   acknowledge the receipt and correct understanding of any
>   Shutdown Communication.
> 
>   Operators should not rely on Shutdown Communications as their
>   sole form of communication with their peer for important events.
> 
>   If it is known that the peer BGP speaker supports this specification,
>   then a Shutdown Communication that is not longer than 255 octets MAY be sent.
>   Otherwise, a Shutdown Communication MAY be sent, but it SHOULD NOT be
>   longer than 128 octets.
> END
> 
> 
> Regards,
> Jakob.
> 
> -----Original Message-----
> From: Alissa Cooper <alissa@cooperw.in> 
> Sent: Wednesday, October 7, 2020 6:52 PM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com>
> Cc: IESG <iesg@ietf.org>rg>; draft-ietf-idr-rfc8203bis@ietf.org; idr-chairs@ietf.org; idr@ietf.org; Susan Hares <shares@ndzh.com>om>; aretana.ietf@gmail.com
> Subject: Re: Alissa Cooper's Discuss on draft-ietf-idr-rfc8203bis-07: (with DISCUSS and COMMENT)
> 
> 
> 
>> On Oct 7, 2020, at 8:59 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
>> 
>> There is no way to know whether the neighbor supports RFC8203 either,
>> so the problem is not unique to the bis.
> 
> Ok. How do operators decide whether to use RFC 8203 and, if this document is approved, how long of a message to use?
> 
> Alissa
> 
>> 
>> This is a best-effort message for convenience.
>> The session is going down whether the message makes it or not.
>> If the peer operator is confused, he will pick up the phone and
>> call the NOC or whatever else they do today.
>> The message prevents that phone call.
>> When maintenance is scheduled, it should be agreed upon beforehand,
>> so both ends should be expecting the cease notification anyway.
>> This message serves only as a reminder in case people don't read their email and such.
>> 
>> Regards,
>> Jakob.
>> 
>> -----Original Message-----
>> From: Alissa Cooper via Datatracker <noreply@ietf.org> 
>> Sent: Wednesday, October 7, 2020 5:10 PM
>> To: The IESG <iesg@ietf.org>
>> Cc: draft-ietf-idr-rfc8203bis@ietf.org; idr-chairs@ietf.org; idr@ietf.org; Susan Hares <shares@ndzh.com>om>; aretana.ietf@gmail.com; shares@ndzh.com
>> Subject: Alissa Cooper's Discuss on draft-ietf-idr-rfc8203bis-07: (with DISCUSS and COMMENT)
>> 
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-idr-rfc8203bis-07: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-idr-rfc8203bis/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> "If a Shutdown Communication longer than 128 octets is sent to a BGP
>>  speaker that implements [RFC8203], then that speaker will treat it as
>>  an error, the consequence of which is a log message.  For this
>>  reason, operators would be wise to keep shutdown communications to
>>  less than 128 octets when feasible."
>> 
>> I have a similar question to what Éric asked. Doesn't the above mostly undercut
>> the value of doing this bis at all? If operators can't expect longer messages
>> to be understood, will they implement some kind of policy logic or heuristics
>> to decide when to try to send them and when not? Otherwise, under what
>> circumstances will they send them?
>> 
>> Was it considered to instead add a new subcode to the BGP Cease NOTIFICATION
>> subcode registry to capture this case (admin reset or shutdown with long
>> shutdown message)? That way at least those who want to use it can differentiate
>> between recipients that don't support RFC 8203, those that do, and those that
>> support longer communications. I'm not at all steeped in BGP so I'm happy to
>> drop this if it's unworkable, but I wanted to ask.
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> For the IESG: it would be good to discuss a bit if there is some process we can
>> use to avoid this kind of oversight (that occurred with RFC 8203) in the
>> future. i18ndir didn't exist when it was published, but even if it had I'm not
>> sure we would have caught this.
>> 
>> 
>> 
>