[bess] John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)
John Scudder via Datatracker <noreply@ietf.org> Thu, 07 March 2024 01:08 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: bess@ietf.org
Delivered-To: bess@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67613C14F61D; Wed, 6 Mar 2024 17:08:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-evpn-irb-mcast@ietf.org, bess-chairs@ietf.org, bess@ietf.org, mankamis@cisco.com, mankamis@cisco.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.6.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <170977368941.19049.5136441037407865792@ietfa.amsl.com>
Date: Wed, 06 Mar 2024 17:08:09 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/V8g1hMnZosgE5xnmSFcLRFnQQHg>
Subject: [bess] John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.39
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2024 01:08:09 -0000
John Scudder has entered the following ballot position for draft-ietf-bess-evpn-irb-mcast-11: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. Although dense and slow going, I appreciated the thoroughness and precision and have confidence that the dedicated reader who makes it all the way through will be able to implement this specification. I have some minor comments below that I hope might be of use. - I continue to find the profligate use of acronyms and initialisms that characterizes so many bess documents to be an unnecessary, not to say gratuitous, impediment to readability, but so it goes. (If the authors are open to what might be an extensive revision to address this, I'm willing to dig in and provide more detailed feedback. But I don't expect it, at this late stage, especially since as noted above, I do think the document is usable, my complaint notwithstanding. If I'm mistaken, let me know and we can work on it.) - I agree with Éric Vyncke that there are several places where the text could easily be elucidated with the use of a diagram. Essentially, any of the many (very welcome!) examples seems like an easy candidate, one instance being “Suppose a given Tenant Domain contains three BDs (BD1, BD2, BD3) and two PEs (PE1, PE2). PE1 attaches to BD1 and BD2, while PE2 attaches to BD2 and BD3.” - I'm sure the RFCEd will flag this, but consider replacing the pronoun "he" in Section 1.3 with something not gender-specific. - In Section 1.5.2 you mention an “attachment AC”, which expands as "attachment attachment circuit". Probably drop "attachment" or (better still in my view, see my first bullet) spell out "attachment circuit". - In Section 2.5 you have “This does assume that source S does not send the same (S,G) datagram on two different BDs, and that the Tenant Domain does not contain two or more sources with the same IP address S. The use of multicast sources that have IP "anycast" addresses is outside the scope of this document?” I tried to puzzle out what the consequence would be if that situation arose, but failed. Can you comment?
- [bess] John Scudder's No Objection on draft-ietf-… John Scudder via Datatracker
- Re: [bess] John Scudder's No Objection on draft-i… Jeffrey (Zhaohui) Zhang
- Re: [bess] John Scudder's No Objection on draft-i… John Scudder
- Re: [bess] John Scudder's No Objection on draft-i… Jeffrey (Zhaohui) Zhang