IETF Logo Mail Archive

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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Thu, 14 December 2017 19:31 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 D4A75124D6C for <idr@ietfa.amsl.com>; Thu, 14 Dec 2017 11:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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
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 98Z-VE3-r7Tt for <idr@ietfa.amsl.com>; Thu, 14 Dec 2017 11:31:41 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45511200C1 for <idr@ietf.org>; Thu, 14 Dec 2017 11:31:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2458; q=dns/txt; s=iport; t=1513279901; x=1514489501; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ur5K6Vc9HB7MKGnNz5KxoFO1ChvjK0tLse3jFN+vWMw=; b=iYbu0o5vyCznxwwnxz8u5DF01eS+KcqUpCBTu3oPC3DJWg3iDP6Aeljo /xC1B/7hNDB6UFHD9vrO/GJTB9zEYa2sLHlzzTgAJ8ASwd5fMtoZlDGri qtMBK+ZoAhPfQq4qPpm8QJYUGkZLl6Pi226sAdoU8igsL8SGj6Tq8xehK w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BmAgBm0TJa/5FdJa1dGQEBAQEBAQEBAQEBAQcBAQEBAYM+ZnQnB50jgX2XKoIBChgLhRgChHdDFAEBAQEBAQEBAWsohSMBAQEBAgEBATg0CwUHBAIBCBEEAQEBHgkHJwsUCQgCBAENBQiKGggQq1yKYAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg2WCDoFWhRSDLgGBMhaGHgWjJQKVH5N1lkACERkBgToBNiKBTm8VOoIphFZ4iA+BMoEVAQEB
X-IronPort-AV: E=Sophos;i="5.45,401,1508803200"; d="scan'208";a="44190284"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 19:31:22 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vBEJVM5r007671 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 19:31:22 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Dec 2017 13:31:22 -0600
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Thu, 14 Dec 2017 13:31:22 -0600
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Job Snijders <job@ntt.net>, Jeffrey Haas <jhaas@pfrc.org>
CC: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Peter Hessler <phessler@theapt.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] draft-snijders-idr-rfc8203bis
Thread-Index: AQHTcDvoN5NHVY0xNUqvjmXbgd8Js6M6Rb4AgAAxIoCACPa3AIAAErYAgAAB5ACAAAgGgIAACXeA//+t/VA=
Date: Thu, 14 Dec 2017 19:31:21 +0000
Message-ID: <ab7036f61e664884aff4663d08aef2a9@XCH-ALN-014.cisco.com>
References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> <CAEm8Q109fbvUuCMOOvnDBianMnTsYR9zdBzp-Jc84uVYt03TUA@mail.gmail.com> <20171214160102.GS37665@gir.theapt.org> <13067_1513271281_5A32AFF1_13067_469_1_53C29892C857584299CBF5D05346208A479212FF@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20171214171446.GN95845@vurt.meerval.net> <4D213F3F-DAC8-4F18-ABA6-517A8213BFA7@pfrc.org> <20171214181721.GP95845@vurt.meerval.net>
In-Reply-To: <20171214181721.GP95845@vurt.meerval.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.131.126]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BphRsl50oFKaGHGJLd2-hfTqGcU>
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: Thu, 14 Dec 2017 19:31:44 -0000

The argument for Cyrillic makes sense.
I have not seen any arguments for longer strings from any other language speakers.
255 keeps it simple. And sufficient.

Thanks,
Jakob


-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders
Sent: Thursday, December 14, 2017 10:17 AM
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: bruno.decraene@orange.com; Peter Hessler <phessler@theapt.org>; idr@ietf.org
Subject: Re: [Idr] draft-snijders-idr-rfc8203bis

On Thu, Dec 14, 2017 at 12:43:29PM -0500, Jeffrey Haas wrote:
> > On Thu, Dec 14, 2017 at 05:08:00PM +0000, bruno.decraene@orange.com wrote:
> >>> From: Idr idr-bounces@ietf.org On Behalf Of Peter Hessler
> >>> The len field is 8 bits, which allows for a max of 255.
> >>> 
> >>> If longer is desired, then we'll need a new error code point.
> >> 
> >> Alternatively, another field may be added after the existing
> >> "Shutdown Communication" field.  Either as a replacement (setting
> >> the length of the first field to zero) or as a concatenation. 
> > 
> > Bruno is right (of course, since the length field was his idea to
> > begin with :-), there are options available to extend beyond 255 if
> > needed.
> 
> If the limit was 127 rather than 128, the top bit could have been
> used. 
> 
> The closest thing that can be done will depend partly on what deployed
> implementations do when 128 is exceed.  The spec says nothing right
> now... and thus you might not do anything beyond saying "up to 255 is
> fine".  

Most of the open source implementations I'm aware of will log a message
"invalid shutdown communication", and perhaps print a hexdump of that
data. Since we're relatively early in the deployment cycle, I think it
is feasible to upgrade the field and patch the existing implementations.

> To get beyond 255, the simplest but gross one is to say "there may be
> a second message after the shutdown communication field".

If (and only if) we pick the route of going beyond 255, I'd consider
deprecating RFC 8203 and have the new thing require the first byte to be
a zero. I don't think there should be two 'shutdown communications'.

> -- Jeff (and people wonder why I'm pushy about using large "length"
> fields.)

Not anymore! :)

Kind regards,

Job

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email