Re: [Idr] draft-snijders-idr-rfc8203bis

Jared Mauch <jared@puck.nether.net> Fri, 08 December 2017 20:12 UTC

Return-Path: <jared@puck.nether.net>
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 EC50F128BB7 for <idr@ietfa.amsl.com>; Fri, 8 Dec 2017 12:12:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 WNWor_FvET2h for <idr@ietfa.amsl.com>; Fri, 8 Dec 2017 12:12:12 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id D5BBD126D3F for <idr@ietf.org>; Fri, 8 Dec 2017 12:12:12 -0800 (PST)
Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id F0ADF54067F; Fri, 8 Dec 2017 15:12:10 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <20171208154735.GH61799@vurt.meerval.net>
Date: Fri, 08 Dec 2017 15:12:04 -0500
Cc: idr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net>
References: <20171208154735.GH61799@vurt.meerval.net>
To: Job Snijders <job@ntt.net>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zJvW3IbMn_5vsvedb0nNtuCyP6k>
Subject: Re: [Idr] draft-snijders-idr-rfc8203bis
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 08 Dec 2017 20:12:18 -0000

Job,


> On Dec 8, 2017, at 10:47 AM, Job Snijders <job@ntt.net> wrote:
> 
> Dear IDR,
> 
> So, it appears I was wrong to push for the arbitrary maximum length of
> 128 octets when we worked on the BGP Administrative Shutdown
> Communication (RFC 8203). At the time, multiple people pointed out that
> it might be better to let the the thing be a little bit longer (255),
> and in retrospect that indeed would've been better. I'm sorry :(
> 
> At this month's peering forum meeting of the Moscow Internet Exchange,
> Misha Grishin (MSK-IX) reported on experiences with the shutdown
> communication, and indicated that the concept was considered useful, but
> that 128 octets is too small in context of multibyte character sets such
> as Cyrillic script and they couldn't easily fit the short messages they
> wanted to send in the communication. The GoBGP authors also questioned
> the 128 limit during the implementation phase, I now see why.
> Operational feedback like this is invaluable and worth our
> consideration.

I support fixing this.

Is 255 the right number?  If all the chars are 4 byte that supports 63 chars.

I’m by no means a unicode expert, but if we fix it, we should ensure the right
number is used.

- Jared

ps - wanting to avoid future 💩