John,
Speaking just for myself, I can say that the intent was not crystal clear for 
me – may be my personal problem, of course.

I have looked up the latest version of the 7432bis draft, and I see that the 
authors have added the highlighted text in Section 7.11:

[RFC8214<https://www.rfc-editor.org/info/rfc8214>] defines and requires this 
extended community ("L2-Attr"), to be included with per-EVI Ethernet A-D routes 
when multihoming is enabled.
To me this suggests that that the intention probably was not so clear for other 
people as well😊

My 2c,
Sasha

From: John Scudder <j...@juniper.net>
Sent: Tuesday, March 5, 2024 3:17 PM
To: bess@ietf.org
Subject: [EXTERNAL] Re: [Technical Errata Reported] RFC8214 (7837)

This looks like a candidate “hold for document update”. The original document 
doesn’t seem to be in error, the erratum is just suggesting some editorial 
improvements/clarifications. Note that RFC 2119 keywords are not mandatory [*] 
in IETF specifications, what’s important is that the intent is clear, and I 
think the intent is crystal clear with the lowercase “mandatory“.

Unless there’s disagreement, I’ll verify this as HFDU later this week.

—John

[*] see what I did there?

> On Mar 5, 2024, at 5:50 AM, RFC Errata System 
> <rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>> wrote:
>
>
>
> The following errata report has been submitted for RFC8214,
> "Virtual Private Wire Service Support in Ethernet VPN".
>
> --------------------------------------
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7837__;!!NEt6yMaO-gk!ECfJun-NPxU03B9Sfleq6xIj3IAePWsksETEL7ltxPlKDab3vqjlsXLZwlk3CGcfbqzdDpIW8cKMZwUTyuXDWw$<https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7837__;!!NEt6yMaO-gk!ECfJun-NPxU03B9Sfleq6xIj3IAePWsksETEL7ltxPlKDab3vqjlsXLZwlk3CGcfbqzdDpIW8cKMZwUTyuXDWw$>
>
> --------------------------------------
> Type: Technical
> Reported by: Alexander ("Sasha") Vainshtein 
> <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>
>
> Section: 3.1
>
> Original Text
> -------------
> This document defines a new extended community [RFC4360], to be included with 
> per-EVI Ethernet A-D routes. This attribute is mandatory if multihoming is 
> enabled.
>
> Corrected Text
> --------------
> This document defines a new extended community [RFC4360], to be included with 
> per-EVI Ethernet A-D routes.
>
> If multihoming is enabled, this attribute is MANDATORY regardless of whether 
> the per-EVI Ethernet A-D route is advertised by an EVPN-VPWS instance or by a 
> "bridging" EVPN instance.
>
>
>
> Notes
> -----
> The lower-case "mandatory" used in the original text does not represent any 
> form of requirement in IETF documents, therefore replacing with upper-case 
> "MANDATORY" is needed.
>
> The reference to per-EVI Ethernet A-D routes advertised by both "bridging" 
> EVPN and EVPN-VPWS is needed to remove possible doubts about the scope of 
> this requirement since the standard is about EVPN-VPWS.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC8214 (draft-ietf-bess-evpn-vpws-14)
> --------------------------------------
> Title : Virtual Private Wire Service Support in Ethernet VPN
> Publication Date : August 2017
> Author(s) : S. Boutros, A. Sajassi, S. Salam, J. Drake, J. Rabadan
> Category : PROPOSED STANDARD
> Source : BGP Enabled ServiceS
> Area : Routing
> Stream : IETF
> Verifying Party : IESG

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to