IETF Logo Mail Archive

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

Jeffrey Haas <jhaas@pfrc.org> Wed, 30 November 2016 21:21 UTC

Return-Path: <jhaas@pfrc.org>
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 7E14C1294B9 for <idr@ietfa.amsl.com>; Wed, 30 Nov 2016 13:21:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level:
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, 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 bGlM0h9tdd-V for <idr@ietfa.amsl.com>; Wed, 30 Nov 2016 13:21:26 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9BC129AB0 for <idr@ietf.org>; Wed, 30 Nov 2016 13:21:09 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 3A4AC1E341; Wed, 30 Nov 2016 16:24:28 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_19133C24-0558-4206-B5F1-1F2377AE7F12"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <828EC50E-0659-46F1-90E2-BD883A75A706@juniper.net>
Date: Wed, 30 Nov 2016 16:21:08 -0500
Message-Id: <8FCE845A-5DB6-4630-9F68-949C4B8D3D8F@pfrc.org>
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>
To: John Scudder <jgs@juniper.net>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QHDqjE8dYLMeqRljE_6uFEpQHwc>
Cc: 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:21:28 -0000

> On Nov 30, 2016, at 4:13 PM, John G. Scudder <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/msg17117.html>
> https://www.ietf.org/mail-archive/web/idr/current/msg17118.html <https://www.ietf.org/mail-archive/web/idr/current/msg17118.html>
> https://www.ietf.org/mail-archive/web/idr/current/msg17170.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