Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt

"Chris Hall" <chris.hall@highwayman.com> Mon, 10 December 2012 01:06 UTC

Return-Path: <chris.hall@highwayman.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 A8B6A21F8DA3 for <idr@ietfa.amsl.com>; Sun, 9 Dec 2012 17:06:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.261
X-Spam-Level:
X-Spam-Status: No, score=-0.261 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcn2MImlL6m5 for <idr@ietfa.amsl.com>; Sun, 9 Dec 2012 17:06:35 -0800 (PST)
Received: from smtp.demon.co.uk (mdfmta010.mxout.tbr.inty.net [91.221.168.51]) by ietfa.amsl.com (Postfix) with ESMTP id EADD521F8DA4 for <idr@ietf.org>; Sun, 9 Dec 2012 17:06:34 -0800 (PST)
Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id 0C6536F813F; Mon, 10 Dec 2012 01:06:34 +0000 (GMT)
Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id E4EDB6F80DB; Mon, 10 Dec 2012 01:06:33 +0000 (GMT)
Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta010.tbr.inty.net (Postfix) with ESMTP; Mon, 10 Dec 2012 01:06:33 +0000 (GMT)
Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from <chris.hall@highwayman.com>) id 1ThrpJ-0005fy-2r; Mon, 10 Dec 2012 01:06:33 +0000
From: Chris Hall <chris.hall@highwayman.com>
To: idr@ietf.org
References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <CAEGVVtBy-zdLz8hVajLnuAqgzfgQHrseK4r-N9=pOZGtqV7LbA@mail.gmail.com>, <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E10C90F@eusaamb109.ericsson.se>, <07ea01cdd66b$101ca590$3055f0b0$@highwayman.com> <F091D6D0-EE28-44AE-A5AC-FC86D5DB351D@ericsson.com>
In-Reply-To: <F091D6D0-EE28-44AE-A5AC-FC86D5DB351D@ericsson.com>
Date: Mon, 10 Dec 2012 01:06:25 -0000
Organization: Highwayman
Message-ID: <000301cdd672$9820e1c0$c862a540$@highwayman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGjHInVAU6Z2PwCWugrJwLHrUJyAVfMhB0B3NGDJ5ckpxhw
Content-Language: en-gb
X-MDF-HostID: 3
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 10 Dec 2012 01:06:35 -0000

Jakob Heitz wrote (on Mon 10-Dec-2012 at 00:33 +0000):
> On Dec 9, 2012, at 4:12 PM, Chris Hall wrote:
....
> > Hmmm.  Section 3 of the draft states:
> >
> >  "To facilitate the determination of the NLRI field
> >   in an UPDATE with a malformed attribute, the
> >   MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if
> >   present) SHALL be encoded as the very first..."
> >
> > which looks like a change in peer behaviour to me... but my
> > eyesight is not what it was ?

> That is not required. It is a SHALL. If the peer does it, great. If
> not, nothing broke.  It's different to requiring a protocol change.

Dunno where this is getting us, but RFC2119:

  1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean
     that the definition is an absolute requirement of the
     specification.

FWIW I loathe this use of SHALL -- MUST is more direct and obvious.

Anyway, clearly it would be best if improvements can be made to error
handling without requiring both ends to change.

Chris