IETF Logo Mail Archive

Re: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Wed, 30 November 2016 21:34 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 1C032129B21 for <idr@ietfa.amsl.com>; Wed, 30 Nov 2016 13:34:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level:
X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 blRLIWCnpeL3 for <idr@ietfa.amsl.com>; Wed, 30 Nov 2016 13:34:24 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFAEF12949F for <idr@ietf.org>; Wed, 30 Nov 2016 13:34:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13294; q=dns/txt; s=iport; t=1480541663; x=1481751263; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PIVlgYLtnvx2UbdS42LBZJmQQ5wLQonRNsTpGtUtD7s=; b=PX8jgXyWoebVmKpwQMLU2DxOdJkKPA/9cU9uKuxlMYRFhppmGjRF3g1M T2tn7ycuTgQS77KHobnD3w5VTIzzL38vTWoRWI9Nym2UaYvHDEyEPHc2R GBEopnpcQHGkq/cLEcJq39UdLGPChd9Yld+Ov3Rk3gRHGw6qMJp8aoXo4 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAQDxRD9Y/40NJK1dGQEBAQEBAQEBAQEBBwEBAQEBgnM3DgEBAQEBH1iBAweNPpcJj1eFH4IGKYV5AoF9PxQBAgEBAQEBAQFiKIRoAQEBBC1MEAIBCA4DBAEBKAcyFAkIAgQBDQUIiGUOrwqLSAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhj6EW4QbCgYCAVGFKwWJQIsuhWkBkQWBe4R3iUmNc4QLAR43YTaDVh+BXXIBhWyBMIENAQEB
X-IronPort-AV: E=Sophos;i="5.31,574,1473120000"; d="scan'208,217";a="175912792"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2016 21:34:22 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uAULYMnD027316 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Nov 2016 21:34: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.1210.3; Wed, 30 Nov 2016 15:34: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.1210.000; Wed, 30 Nov 2016 15:34:22 -0600
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, John Scudder <jgs@juniper.net>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt
Thread-Index: AQHSSyqW2EetENBl4EGVU2FiDJhWKaDyZJ2AgAACuYCAAAQUgIAAAioA//+dbxA=
Date: Wed, 30 Nov 2016 21:34:22 +0000
Message-ID: <b98866b0eac34bd4a2c7942334bdba90@XCH-ALN-014.cisco.com>
References: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com> <20161130204903.GH10210@Vurt.local> <CC754B0F-B1FE-4C27-B39A-89BF58313CE9@pfrc.org> <828EC50E-0659-46F1-90E2-BD883A75A706@juniper.net> <8FCE845A-5DB6-4630-9F68-949C4B8D3D8F@pfrc.org>
In-Reply-To: <8FCE845A-5DB6-4630-9F68-949C4B8D3D8F@pfrc.org>
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.32.152.76]
Content-Type: multipart/alternative; boundary="_000_b98866b0eac34bd4a2c7942334bdba90XCHALN014ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QawsyAB-pT0Udkp0VN_xF-vDLmc>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 30 Nov 2016 21:34:26 -0000

I agree with Jeff.
The potential to add future stuff to this field is quite limited,
given that the field already exists and may have been used for other
purposes. A text field is about as much as you could get away with
under those circumstances. Please don't anyone say CRC.

Thanks,
Jakob.

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: Wednesday, November 30, 2016 1:21 PM
To: John Scudder <jgs@juniper.net>
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt


On Nov 30, 2016, at 4:13 PM, John G. Scudder <jgs@juniper.net<mailto:jgs@juniper.net>> wrote:

On Nov 30, 2016, at 3:58 PM, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>> wrote:
I'm somewhat behind in my mail, but why was the data length of the notification message not sufficient?

It would have been sufficient had the string length not been limited to 128 bytes, but it is. Beyond that, if you haven't seen these they should provide context.

https://www.ietf.org/mail-archive/web/idr/current/msg17117.html
https://www.ietf.org/mail-archive/web/idr/current/msg17118.html
https://www.ietf.org/mail-archive/web/idr/current/msg17170.html

Thanks, I hadn't gotten to those yet.
(People get behind on email around IETFs?  Who knew?!)




The main motivation for asking is by having two distinct length fields, you now have two different overruns to deal with:
1. The data overruns the length field of the string. (Extra stuff, do what?)

Presumably what everyone does now, hex dump it.


2. The length of the string overruns the data. (Not enough stuff, completely malformed.)

In any case, the connection's going down no matter what so I'm not sure there's a need to be as punctilious about error cases as we are for other message types.

Yes, it's obvious.  The main reason for commenting is you now have additional bits of exception handling in your code.  I was trying to figure out why we would want to accommodate a length and incur that extra code.

I'm personally a bit undersold on the idea of future stuff being added, but I don't strongly object. I'd honestly rather have the option for longer shutdown reasons but I also am not going to push on that point.  Having lengths a bit more congruent with syslog protocol limits seems like a better idea to me.

-- Jeff (although position, length, value feels a bit too XDR like to me for comfort)

v2.23.0 | Report a Bug | By Email