Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EF5120192; Tue, 30 Jul 2019 07:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 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, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qrdFR4kP7OsG; Tue, 30 Jul 2019 07:39:16 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 405CB120187; Tue, 30 Jul 2019 07:39:16 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id d4so62835004edr.13; Tue, 30 Jul 2019 07:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=nq1y7hvAAKtYIGyJDp3nFYniZ6arXKT2CEOgfBZcgHM=; b=N4s8ZdpPA5Th6Btt8ZaNarhaYqjIBEjd+pEREHqzS5HrI826a3QqMuleS1c0ty0ckw P3Y7MA12Q9Q+Zm6G4sVA5F3AVbOjwUJ+9XYzIXGuEuMDG8Dty+ek5wCG+zi8X8NzY74K 39cst+sW5cakRYVbrmicQDdU3umiDTLqJhuNPOtON2KZh7gFXuaaxenEwxlxo1Ikp5vq TrnnFyK+2EJlk9ElnQBikhLzHQKJ+2Wo8GhGDyx/PbuK5+lRzwSVNgot70hOLlSiWDEu UNZqf77NR5kSBlrZOSfY/Ye9v/eFKvpwFLgxxMp+T1oy6JE7HRIA5TxtyItp3CdOycOD 89kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=nq1y7hvAAKtYIGyJDp3nFYniZ6arXKT2CEOgfBZcgHM=; b=dujNDsjzrt3T/pHqtFBL56Mcjtj3F6nHUGRvUgRMPMsUbhTuQlSjQoblv9Rw+YmKy+ H7XA5dHOiyoqNuwR8JghnteNEGsiQvLn3MgQWSC4mzJz9izrvUhL+ftVpqgVezSpa1yK vVdzjoiJjJaykCGb/hETRffu4INqy5M4FP8iU7OduQjD4vjkZLp7ReED2ptEzlK1AM5+ TGMypQ78TrCWeBFimGPQpAyMUBv4d1PijQphH8BrrvaIviGn48QCxWMezl18tpUQ9gQk d4q9GAcpQeWNGfserahAKJb6YZDJvCFjEFVQ0hbPChoAu8kVSh/cjj5/YxHmAiIJLCVS q/bw== X-Gm-Message-State: APjAAAWeR9Fz+F0tCf0M+U3/LQuvmTYXfWpUP/iPDI3qxfg9exi+DH45 Jgqoqwoz/JGc3z3ljWu1B56oW3zRLIi4SQMdnZI= X-Google-Smtp-Source: APXvYqxwRpv7N+vUhR7b1gumyWVIdhNMb8zNZSLRyU25m3XpVE5pcdJSd5pS7VDHNYB49iJmLHb7iMB8nd+OPTaanrs= X-Received: by 2002:aa7:c313:: with SMTP id l19mr90210872edq.258.1564497554826; Tue, 30 Jul 2019 07:39:14 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 30 Jul 2019 10:39:14 -0400 From: Alvaro Retana In-Reply-To: <156449387998.2643.18137174091685834097.idtracker@ietfa.amsl.com> References: <156449387998.2643.18137174091685834097.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Tue, 30 Jul 2019 10:39:14 -0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , The IESG Cc: draft-ietf-idr-bgp-extended-messages@ietf.org, idr-chairs@ietf.org, jgs@juniper.net, jie.dong@huawei.com, idr@ietf.org Content-Type: multipart/alternative; boundary="00000000000001e9ab058ee6f95b" Archived-At: Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-idr-bgp-extended-messages-33=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 14:39:18 -0000 --00000000000001e9ab058ee6f95b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On July 30, 2019 at 9:38:01 AM, Mirja K=C3=BChlewind via Datatracker ( noreply@ietf.org) wrote: Mirja: Hi! Thanks for your review. ... --------------------------------------------------------------------- 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." This point (and your last one) should be clarified in light of clarifications to rfc5492 (Capabilities Advertisement) that were discussed in Montreal last week. I=E2=80=99ve started a separate thread with the aut= hors. 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/ All the actions on these two points are in fact normatively specified in rfc4271 (which is the reason for the specific references)=E2=80=A6so we sho= uld use non-Normative text in both cases. IOW: your point in #2 is accurate, but the changes suggested in #3 should not be applied. Thanks!! Alvaro. 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? --00000000000001e9ab058ee6f95b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On July 30, 2019 at 9:38:01 AM, Mirja K=C3=BChle= wind via Datatracker (noreply@ietf.org<= /a>) wrote:


--------------------------= -------------------------------------------=C2=A0
COMMENT:=C2=A0=
----------------------------------------------------------------= ------=C2=A0

Some comme= nt on use of normative language:=C2= =A0

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

This point (and your last one) should be clarified in light of clarif= ications to rfc5492 (Capabilities Advertisement) that were discussed in Mon= treal last week.=C2=A0 I=E2=80=99ve started a separate thread with the auth= ors.


All the actions on these two p= oints are in fact normatively specified in rfc4271 (which is the reason for= the specific references)=E2=80=A6so we should use non-Normative text in bo= th cases. =C2=A0

IOW: your point in #2 is accurate, but the changes s= uggested in #3 should not be applied.


Thanks!!

Alvar= o.



--00000000000001e9ab058ee6f95b--