[Gen-art] Gen-ART Last Call review of draft-ietf-idr-bgp-extended-messages-33

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 04 July 2019 14:42 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 413F51200B1; Thu, 4 Jul 2019 07:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HG52NjDCTwz9; Thu, 4 Jul 2019 07:42:35 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BA912008F; Thu, 4 Jul 2019 07:42:31 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x64EgTIn000644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Jul 2019 10:42:29 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: draft-ietf-idr-bgp-extended-messages.all@ietf.org
Cc: General Area Review Team <gen-art@ietf.org>
Message-ID: <e96e60ca-8b54-9209-9789-189447cc1f70@alum.mit.edu>
Date: Thu, 4 Jul 2019 10:42:28 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/kFkRqRn4w3304BQ-u-DaAnFWFCY>
Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-idr-bgp-extended-messages-33
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 04 Jul 2019 14:42:37 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-idr-bgp-extended-messages-33
Reviewer: Paul Kyzivat
Review Date: 2019-07-09
IETF LC End Date: 2019-07-18
IESG Telechat date: ?


This draft is on the right track but has open issues, described in the 


I have very little understanding of the subject matter of this document, 
so this review is limited to the form and structure of the document.


The Abstract and Introduction are written in the abstract, implying (to 
me) that the requirements here are intended to be broadly applicable for 
the stated purposes, over an extended period of time. On the other hand, 
I get the impression that requirements in this document are actually 
more focused, intended for use in a one-time selection of an Internet 
video codec to be a successor to HEVC and VP9.

If this document is intended only for one-time use then it isn't evident 
to me why it ever needs to become an RFC.


Major: 0
Minor: 0
Nits:  2

1) NIT:

Section 4 says:

    If a BGP message with a Length greater than 4,096 octets is received
    by a BGP listener who has not advertised the Extended Message
    Capability, the listener MUST treat this as a malformed message, and
    MUST generate a NOTIFICATION with the Error Subcode set to Bad
    Message Length (see [RFC4271] Sec 6.1).

The "MUST" seems inappropriate because this is not new normative 
behavior. Rather it is the existing behavior, at it states. This is 
already covered by the 2nd paragraph of Section 5, so why does it need 
to be covered here as well?

2) NIT:

Reading the last two security considerations in section 8 leaves me 
concerned. I was expecting to see some further discussion of how these 
issues can be mitigated, or why it is OK that they are not.

Otherwise this short document seems to be in good shape.