John, Lots of thanks for the clarification. HFDU seems good enough. Regards, Sasha
From: John Scudder <j...@juniper.net> Sent: Tuesday, March 5, 2024 3:44 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Cc: bess@ietf.org Subject: [EXTERNAL] Re: [Technical Errata Reported] RFC8214 (7837) Indeed, opinions may vary as to the adjective to apply to “clear” (“crystal” vs. “insufficiently” for instance) but the underlying point remains that the proposed erratum is an improvement, not a correction of an error, and so isn’t a candidate for verification other than as HFDU, per https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/<https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507> As a practical matter, HFDU errata show up when errata are viewed on the RFC editor website, so it still gets the job done almost as well as a verified technical erratum. —John On Mar 5, 2024, at 8:34 AM, Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> wrote: 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://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc8214__;!!NEt6yMaO-gk!ECGwEs5ZsZ6uWKijnemlIXH6DEAmp36EwrLJ1NqN1iGDimkHPIeakyGXhiKZ9xzzGHlXATgu569a5VCZNE_0mtmq$>] 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<mailto:j...@juniper.net>> Sent: Tuesday, March 5, 2024 3:17 PM To: bess@ietf.org<mailto: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
