[Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

Mirja Kühlewind via Datatracker <noreply@ietf.org> Tue, 30 July 2019 13:37 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D7A120182; Tue, 30 Jul 2019 06:37:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-idr-bgp-extended-messages@ietf.org, jgs@juniper.net, aretana.ietf@gmail.com, jie.dong@huawei.com, idr-chairs@ietf.org, idr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Mirja Kühlewind <ietf@kuehlewind.net>
Message-ID: <156449387998.2643.18137174091685834097.idtracker@ietfa.amsl.com>
Date: Tue, 30 Jul 2019 06:37:59 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WqaFoQvXqD64TIfNFyEEYpSm7nU>
Subject: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 30 Jul 2019 13:38:00 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-idr-bgp-extended-messages-33: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some comment on use of normative language:

1) I know what the intention is here but this normative language is not used correctly (sec 4):
"A BGP speaker
   MAY send Extended Messages to a peer only if the Extended Message
   Capability was advertised by both peers."
This should be a MUST anyway (and moving the "only"):
"A BGP speaker
   MUST only send Extended Messages to a peer if the Extended Message
   Capability was advertised by both peers."
Or you go for the MUST NOT (and maybe even two sentence) to make it crystal clear, e.g.
"A BGP speaker
   MUST NOT send Extended Messages to a peer if the Extended Message
   Capability was not advertised by both peers. A BGP speaker
   MAY send Extended Messages to a peer if the Extended Message
   Capability was advertised by both peers."

2) sec 4:
"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)."
If this is specified normatively in RFC4271, you should not use normative language here as well.
I suggest s/MUST/will/

3) sec 4:
s/then it must NOT be sent to the neighbor/then it MUST NOT be sent to the neighbor/
and
s/it must be withdrawn from service/it MUST be withdrawn from service/

4) sec 4
"In an iBGP mesh, if BGP Extended Messages are to be advertized, all
   peers MUST advertize the BGP Extended Message capability."
Which action(s) should be taken if that is not the case?