Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT)

Rob Shakir <> Thu, 12 March 2015 10:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 205E61A9162; Thu, 12 Mar 2015 03:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bI-iI6Dp2LDd; Thu, 12 Mar 2015 03:52:06 -0700 (PDT)
Received: from ( [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 245771A9151; Thu, 12 Mar 2015 03:52:04 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1YW0ia-00012H-M4; Thu, 12 Mar 2015 10:51:56 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_621171C8-5251-452A-9095-426D29E0EF96"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Rob Shakir <>
In-Reply-To: <>
Date: Thu, 12 Mar 2015 10:51:55 +0000
Message-Id: <>
References: <> <122301d0584e$e8395830$b8ac0890$> <> <> <> <>
To: Brian Haberman <>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <>
Cc:,, Rob Shakir <>,,,
Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Mar 2015 10:52:08 -0000


Apologies for the delay in my reply.

> On 9 Mar 2015, at 12:21, Brian Haberman <> wrote:
> I agree that it belongs in the document, but it appears to me to be a
> little opaque.  I read the text in the draft as strictly something the
> operator has to worry about.  The description you provided indicated
> that there needs to be sufficient notification from the router so that
> the operator can act on it.
> Perhaps what is needed is just a little clarification.  Given that I
> raised this as a Comment, making any changes is really up to the
> authors/WG/AD.  My thought would be a slight re-wording of the 2nd
> paragraph to indicate that the router needs to provide a notification
> when a malformed attribute is detected.  That then provides the input
> needed for the operator to act on the recommendation in the section.

I agree — let me work with the authors as part of the post-IESG review comments to see whether we can clarify the wording here (perhaps based around the summaries here). Since there are multiple comments around this clarification, then making changes would seem advisable to me!

Thanks again for the review.