[Gen-art] Last Call re-review of draft-ietf-idr-error-handling

Tom Taylor <tom.taylor.stds@gmail.com> Fri, 06 March 2015 16:21 UTC

Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id DDE981A01F0; Fri, 6 Mar 2015 08:21:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VoKQHdObrBID; Fri, 6 Mar 2015 08:20:58 -0800 (PST)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC32E1A01EC; Fri, 6 Mar 2015 08:19:32 -0800 (PST)
Received: by iecvy18 with SMTP id vy18so22615818iec.9; Fri, 06 Mar 2015 08:19:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=WWRN59y0w+/BJjVQVjm3F+QMki63ZO7QWZ7MBo1rifs=; b=bzaL7OijXwKMzBWYsl7ipXomgSxZy1bpQ/w8G6PJ7odFkN1WEKfxhW2yZuWsAzqpPz QgNQsa8cvh4aAEl6sRUpVZhBeV42i61Pc3HlJYMBkaIGSJgccJpTEQFffQt9fMkrhBV8 c2GwrdNV+s1uOFVk8UDaciP9z4HLG9cMkR3zUIOlVM65Uybnx5UMO2nuaDo+M9Lowl6e zZAvNjU/vfNuR6+63J994ELVgDjGqULpdhTUzOwfZAJZ1MnHyyhrPGvPfdRYLxzrvMWS d1+sB8uV2ttVcVx1iFwf44EjfeMqMstW4h3YC/ZYqfw1mhU/Y30QYPBA9pYt71VI4fSL 7pqw==
X-Received: by with SMTP id fz4mr10814537icb.71.1425658772251; Fri, 06 Mar 2015 08:19:32 -0800 (PST)
Received: from [] (dsl-173-206-150-251.tor.primus.ca. []) by mx.google.com with ESMTPSA id qr1sm15051614igb.18.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 08:19:31 -0800 (PST)
Message-ID: <54F9D393.1040706@gmail.com>
Date: Fri, 06 Mar 2015 11:19:31 -0500
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Gen Art <gen-art@ietf.org>, enkechen@cisco.com, jgs@juniper.net, mpradosh@yahoo.com, keyupate@cisco.com, Rob Shakir <rob.shakir@bt.com>, Alia Atlas <akatlas@gmail.com>, The IETF <ietf@ietf.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/ymuR_6vlnedoG7ZNqflcAk-pL3E>
Subject: [Gen-art] Last Call re-review of draft-ietf-idr-error-handling
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: Fri, 06 Mar 2015 16:21:01 -0000

I believe this got overlooked, since I don't see any effect on the text 
in the -18 version of the document.

Tom Taylor

-------- 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>, 

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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


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/