Re: [Gen-art] Early review of draft-ietf-idr-error-handling-15

Jari Arkko <jari.arkko@piuha.net> Wed, 11 March 2015 16:24 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EC61ACDD6 for <gen-art@ietfa.amsl.com>; Wed, 11 Mar 2015 09:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 igDFtg_QxVA9 for <gen-art@ietfa.amsl.com>; Wed, 11 Mar 2015 09:24:12 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6CA1ACD9B for <gen-art@ietf.org>; Wed, 11 Mar 2015 09:24:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9ED122CC6F; Wed, 11 Mar 2015 18:24:03 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_Lzuedpa_VX; Wed, 11 Mar 2015 18:24:02 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 5B91A2CC4D; Wed, 11 Mar 2015 18:24:02 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_3DB9E164-8A13-4D3C-889D-4C50CE3A7DEE"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <544DA2D0.5070102@gmail.com>
Date: Wed, 11 Mar 2015 18:24:01 +0200
Message-Id: <5F2E7F47-6695-48E7-A06C-F250434B56E0@piuha.net>
References: <544D984D.7040605@gmail.com> <544DA2D0.5070102@gmail.com>
To: Tom Taylor <tom.taylor.stds@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/nuCxuwiLXgbkQY6VAoASgL2Grj8>
Cc: Gen Art <gen-art@ietf.org>, draft-ietf-idr-error-handling@tools.ietf.org, Rob Shakir <rob.shakir@bt.com>
Subject: Re: [Gen-art] Early review of draft-ietf-idr-error-handling-15
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2015 16:24:14 -0000

Belated thanks for the review, Tom. 

Jari

On 27 Oct 2014, at 03:41, Tom Taylor <tom.taylor.stds@gmail.com> wrote:

> Resending due to bounce. draft...all E-mail alias not yet established.
> 
> 
> -------- Original Message --------
> Subject: Early review of draft-ietf-idr-error-handling-15
> Date: Sun, 26 Oct 2014 20:56:45 -0400
> From: Tom Taylor <tom.taylor.stds@gmail.com>
> To: Gen Art <gen-art@ietf.org>, draft-ietf-idr-error-handling.all@tools.ietf.org.
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other comments
> you may receive.
> 
> Document: draft-ietf-idr-error-handling-15
> Reviewer: Tom Taylor
> Review Date: 26/10/2014
> IETF LC End Date:
> IESG Telechat date: (if known)
> 
> Summary: This draft has a number of editorial issues but otherwise looks
> good to go. (I am no BGP expert and did not check on the correctness of
> the references to the individual attributes.).
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 1) IdNits has a number of complaints, but the only real one is a m
> question regarding the choice of copyright boilerplate.
> 
> In the copyright matter: are you using the pre-2009 Trust template
> because of the quotations from the older documents that are being
> amended? I suppose that is justified, but others on the Gen-Art list may
> have an opinion.
> 
> 2) Spell out Address Family Identifier / Subsequent Address Family
> Identifier (AFI/SAFI) on first occurrence. See
> 
> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
> 
> Asterisked items there (like BGP) are well-known abbreviations and do
> not have to be spelled out. All others do on first occurrence.
> 
> 3) For the new text proposed in section 3 a., would you consider a
> slight reordering as follows? It highlights the condition (session
> reset) more clearly, I'd suggest.
> 
>  New Text:
> 
>       An error for which a session reset is specified that is
>       detected while processing the UPDATE message MUST ...
> 
> 4) Grammatical and reference problem with the opening part of the new
> text proposed in section 3.c. Suggested text:
> 
>  New Text:
> 
>       If the value of either the Optional or the Transitive bit in
>       the Attribute Flags is in conflict with its value as given
>       in the attribute specification ...
> 
> 5) For section 3.e, do you mean:
> 
>   e.  "Treat-as-withdraw" MUST be used instead of session reset
>       for the cases where [RFC4271] Section 6.3 specifies a
>       session reset and the detected error is found in any of
>       the attributes ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC,
>       or LOCAL_PREF.
> 
> 6) Similar change for section 3.f:
> 
>   f.  "Attribute discard" MUST be used instead of session reset
>       for the cases where [RFC4271] Section 6.3 specifies a
>       session reset and the detected error is found in either
>       of the attributes ATOMIC_AGGREGATE or AGGREGATOR.
> 
> 7) For section 3.h.:
> 
>    s/for the handling of these malformed attributes/
>      for the handling of all of these malformed attributes/
>                          ^^^^^^
> 
> 8) In section 3.i., I think you have to spell out Network Layer
> Reachability Information (NLRI).
> 
> 9) In section 5.1, second bullet of the restrictions is ambiguous. Do
> you mean:
> 
>  o    An UPDATE message MUST NOT contain more than *any* one
>       of the following:
> 
> or do you mean
> 
>   o  An UPDATE message MUST NOT contain more than one of the following:
>                            ... MP_REACH_NLRI attribute, *or*
>      MP_UNREACH_NLRI attribute.
> 
> 10) Section 5.3, first paragraph:
>   s/following are true/following is true/
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art