Hi Ali and John, We have updated our files with John’s requested changes.
As an FYI, if we are unable to reach Rick this week, you may choose one of the following options: 1) The author can be removed as an author and moved to the Acknowledgements section. 2) The author can be removed as an author and moved to the Contributors section. 3) A stream manager can approve the document in place of the unavailable author (this option is typically used in instances where the missing author made significant contributions to the document and the other authors are not comfortable removing the individual from the author list). --FILES-- The updated XML file is here: https://www.rfc-editor.org/authors/rfc9784.xml The updated output files are here: https://www.rfc-editor.org/authors/rfc9784.txt https://www.rfc-editor.org/authors/rfc9784.pdf https://www.rfc-editor.org/authors/rfc9784.html These diff files show all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9784-auth48diff.html https://www.rfc-editor.org/authors/rfc9784-auth48rfcdiff.html (side by side) These diff files show all changes made to date: https://www.rfc-editor.org/authors/rfc9784-diff.html https://www.rfc-editor.org/authors/rfc9784-rfcdiff.html (side by side) Best regards, RFC Editor/kc > On Jun 17, 2025, at 11:35 AM, Ali Sajassi (sajassi) <[email protected]> wrote: > > Hi Karen, > > I just pinged Rick via another email. Let’s wait till end of the week > (Friday). If we don’t hear back from him, please remove him from the author > list and proceed with publication. > > Thanks, > Ali > > On Jun 17, 2025, at 1:11 PM, John Drake <[email protected]> wrote: > > Karen, > > My affiliation is 'independent' and my email address is '[email protected]'. > > Thanks, > > John > > On Tuesday, June 17, 2025 at 11:38:19 AM PDT, Ali Sajassi (sajassi) > <[email protected]> wrote: > > > Hi John, > > > Are you OK with your affiliation as “Juniper”. Or do you prefer > “Independent”. If latter, then we need to let Karen now. If former, we don’t > need to do anything. It seems like your Juniper email account is still active > ☺ > > > Cheers, > > Ali > > > From: John Drake <[email protected]> > Date: Tuesday, June 17, 2025 at 6:40 AM > To: Karen Moore <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, > Patrice Brissette (pbrisset) <[email protected]>, Ali Sajassi (sajassi) > <[email protected]>, Rick Schell <[email protected]> > Cc: [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, > [email protected] <[email protected]>, > [email protected] <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9784 > <draft-ietf-bess-evpn-virtual-eth-segment-19> for your review > > I approve the draft for publication > > > On Monday, June 16, 2025 at 09:54:35 PM PDT, Ali Sajassi (sajassi) > <[email protected]> wrote: > > > > Hi Karen, > > > Thanks again for your review and corresponding suggestions. Please refer to > my reply inline. > > > John, Rick: > > If you are OK with the document, please approve. > > > Regards, > > Ali > > > From: Karen Moore <[email protected]> > Date: Monday, June 16, 2025 at 11:52 AM > To: Ali Sajassi (sajassi) <[email protected]>, [email protected] > <[email protected]>, [email protected] > <[email protected]>, [email protected] > <[email protected]>, Patrice Brissette (pbrisset) <[email protected]> > Cc: [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, > [email protected] <[email protected]>, > [email protected] <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9784 > <draft-ietf-bess-evpn-virtual-eth-segment-19> for your review > > Hi Ali, > > Thank you for the clarifications (we have left “PBB-EVPN” singular) . We now > await responses to the three questions below as well as approvals from John > and Richard. > > 1) Please let us know how we may update the title of Figure 1 with “SH” > expanded (perhaps A or B?): > > > > Ali> single-homed > > > Original: > Figure 1: A Dual-Homed Device/Network (Both SA/AA) and SH on the Same ENNI > > Current: > Figure 1: A Dual-Homed Device/Network (Both SA/AA) and Single-Homed on the > Same ENNI > > Perhaps A: > Figure 1: A Dual-Homed Device/Network (Both SA/AA) That is Single-Homed on > the Same ENNI > > Perhaps B: > Figure 1: A Dual-Homed and Single-Homed Device/Network (Both SA/AA) on the > Same ENNI > > Ali> It should be: > > “Figure 1: Single-Homed Devices and a Dual-Homed Device/Network on the Same > ENNI” > > … > 2) In Section 4.1, is “ES-Import extended community" the same as "ES-Import > Route Target extended community"? > If so, should it be updated, or is this short form of the name sufficiently > clear? (It seems to be "ES-Import Route Target" in > <https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn> > and in RFC-to-be 9786). > > Current: > When a PE discovers the vESI or is configured with the vESI > associated with its attached vES, it advertises an ES route > with the associated ES-Import extended community attribute. > > Perhaps: > When a PE discovers the vESI or is configured with the vESI > associated with its attached vES, it advertises an ES route > with the associated ES-Import Route Target extended community > attribute. > > Ali> Perfect! > > 3) Please confirm if any key words are desired. > > > <!-- [rfced] Please insert any keywords (beyond those that appear in > > the title) for use on https://www.rfc-editor.org/search. > > --> > > Ali> Keywords: vES, Virtual ES > > > > Best regards, > RFC Editor/kc > > > > On Jun 15, 2025, at 10:09 PM, Ali Sajassi (sajassi) <[email protected]> > > wrote: > > > > Hi Karen, > > > > Please refer to my comments inline marked with Ali>> > > > > From: Karen Moore <[email protected]> > > Date: Tuesday, June 10, 2025 at 6:21 PM > > To: Ali Sajassi (sajassi) <[email protected]>, > > [email protected]<[email protected]>, > > [email protected] <[email protected]>, Ali Sajassi > > (sajassi) <[email protected]>, Patrice Brissette (pbrisset) > > <[email protected]> > > Cc: [email protected] <[email protected]>, > > [email protected] <[email protected]>, [email protected] > > <[email protected]>, [email protected] <[email protected]>, > > [email protected] <[email protected]>, > > [email protected]<[email protected]>, > > [email protected] <[email protected]> > > Subject: Re: AUTH48: RFC-to-be 9784 > > <draft-ietf-bess-evpn-virtual-eth-segment-19> for your review > > > > Dear Ali, Jorge, and Patrice, > > > > Thank you for your replies. We have updated our files accordingly (see the > > files below). We have marked approvals for Ali and Jorge; however, please > > note that we have some follow-up questions. > > > > 1) We updated the title with “PBB-EVPN” expanded because “PBB” is not > > marked as a well-known term (see > > https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list). Please let us > > know if the following update is correct or if you prefer otherwise (should > > “Provider Backbone Bridge” be singular or plural here?). > > > > > Ali> I would prefer “Virtual Ethernet Segments for EVPN and PBB-EVPN” for > > > the title > > > > > > Current: > > Virtual Ethernet Segments for EVPN and Provider Backbone Bridge EVPN > > > > Ali>> That’s fine > > > > > > > > ... > > 2) Please clarify the following request. Is it correct that “Provider > > Backbone Bridge” as well as “PBB-EVPN” should be updated to the plural > > forms everywhere in the document (e.g., “Provider Backbone Bridges” and > > “PBBs-EVPN”)? Should “PBB” and “PBB-EVPN” remain singular in the > > Terminology list (Section 2) for consistency with the other terms, or do > > you prefer both to be plural in that section? Note that only “PBB-EVPN” > > (not "PBBs-EVPN") has been used in the RFC Series. > > > > Ali>> I am sorry for the confusion that I created. Your original text of > > singular is correct and PPB stands for Provider Backbone Bridge. I just > > went back to IEEE 802.1Q 2014 and verified there. > > > > Ali>> Please change everything back to singular. The reason for my > > confusion was because some IEEE documents refer to PBB as singular and some > > as plural and yet some as “Provider Backbone Bridged”. However, in the > > context of this document, the most correct one is “Provider Backbone > > Bridge”. > > > > > > > > Regards, > > > > Ali > > > > > > > > > Ali> Please change “Provider Backbone Bridge” to “Provider Backbone > > > Bridges” throughout this document. > > > > > > Some examples > > > > Current: > > Ethernet VPN (EVPN) and Provider Backbone Bridge EVPN (PBB-EVPN) > > introduce a comprehensive suite of solutions for delivering Ethernet > > services over MPLS/IP networks. > > > > Perhaps: > > Ethernet VPN (EVPN) and Provider Backbone Bridges EVPN (PBBs-EVPN) > > introduce a comprehensive suite of solutions for delivering Ethernet > > services over MPLS/IP networks. > > > > Current: > > PBB: Provider Backbone Bridge > > PBB-EVPN: Provider Backbone Bridge EVPN > > > > Perhaps: > > PBBs: Provider Backbone Bridges > > PBBs-EVPN: Provider Backbone Bridges EVPN > > > > Current: > > This section describes the requirements specific to vES for EVPN and > > PBB-EVPN solutions. > > > > Perhaps: > > This section describes the requirements specific to vES for EVPN and > > PBBs-EVPN solutions. > > > > ... > > 3) Please let us know how we may update the title of Figure 1 with “SH” > > expanded. > > > > > Ali> single-homed > > > > > > Original: > > Figure 1: A Dual-Homed Device/Network (Both SA/AA) and SH on the Same > > ENNI > > > > Current: > > Figure 1: A Dual-Homed Device/Network (Both SA/AA) and Single-Homed on > > the Same ENNI > > > > Perhaps A: > > Figure 1: A Dual-Homed Device/Network (Both SA/AA) That is Single-Homed > > on the Same ENNI > > > > Perhaps B: > > Figure 1: A Dual-Homed and Single-Homed Device/Network (Both SA/AA) on > > the Same ENNI > > > > ... > > 4) In Section 4.1, is "ES-Import extended community" the same as "ES-Import > > Route Target extended community"? > > If so, should it be updated, or is this short form of the name sufficiently > > clear? (It seems to be "ES-Import Route Target" in > > <https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn> > > and in RFC-to-be 9786). > > > > Current: > > When a PE discovers the vESI or is configured with the vESI > > associated with its attached vES, it advertises an ES route > > with the associated ES-Import extended community attribute. > > > > Perhaps: > > When a PE discovers the vESI or is configured with the vESI > > associated with its attached vES, it advertises an ES route > > with the associated ES-Import Route Target extended community > > attribute. > > > > 5) Please confirm if any key words are desired. > > > > > <!-- [rfced] Please insert any keywords (beyond those that appear in > > > the title) for use on https://www.rfc-editor.org/search. > > > --> > > > > > > > > --FILES-- > > The updated XML file is here: > > https://www.rfc-editor.org/authors/rfc9784.xml > > > > The updated output files are here: > > https://www.rfc-editor.org/authors/rfc9784.txt > > https://www.rfc-editor.org/authors/rfc9784.pdf > > https://www.rfc-editor.org/authors/rfc9784.html > > > > These diff files show all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9784-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9784-auth48rfcdiff.html (side by > > side) > > > > These diff files show all changes made to date: > > https://www.rfc-editor.org/authors/rfc9784-diff.html > > https://www.rfc-editor.org/authors/rfc9784-rfcdiff.html (side by side) > > > > Note that it may be necessary for you to refresh your browser to view the > > most recent version. Please review the document carefully to ensure > > satisfaction as we do not make changes once it has been published as an RFC. > > > > Please contact us with any further updates or with your approval of the > > document in its current form. We will await approvals from John and Rick > > prior to moving forward in the publication process. > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9784 > > > > Best regards, > > RFC Editor/kc > > > > > > > On Jun 10, 2025, at 12:26 PM, Ali Sajassi (sajassi) > > > <[email protected]> wrote: > > > > > > Hi Karen, > > > > > > Please refer to my comments inline starting with “Ali>”. After > > > incorporating my comments, you can reflect my approval for this document. > > > Thank you! > > > > > > From: [email protected] <[email protected]> > > > Date: Thursday, May 15, 2025 at 1:28 PM > > > To: Ali Sajassi (sajassi) <[email protected]>, Patrice Brissette > > > (pbrisset) <[email protected]>, [email protected] > > > <[email protected]>, [email protected] <[email protected]>, > > > [email protected] <[email protected]> > > > Cc: [email protected] <[email protected]>, > > > [email protected] <[email protected]>, [email protected] > > > <[email protected]>, [email protected] > > > <[email protected]>, [email protected] > > > <[email protected]>, > > > [email protected]<[email protected]> > > > Subject: Re: AUTH48: RFC-to-be 9784 > > > <draft-ietf-bess-evpn-virtual-eth-segment-19> for your review > > > > > > Authors, > > > > > > While reviewing this document during AUTH48, please resolve (as > > > necessary) the following questions, which are also in the XML file. > > > > > > 1) <!--[rfced] To align with the Abstract/Introduction, we made > > > "Virtual Ethernet Segment" plural in the document title and the > > > short title (which appears in the running header of the PDF). > > > Please let us know of any changes. > > > > > > Ali> That’s fine. > > > > > > Additionally, please consider if "Provider Backbone Bridge EVPN" > > > should be included in the document title per the scope. And for > > > clarity, would it be correct for "Solutions", "Requirements", or > > > other to be included? > > > > > > Ali> Please change “Provider Backbone Bridge” to “Provider Backbone > > > Bridges” throughout this document. > > > > > > > > > Original: > > > EVPN Virtual Ethernet Segment > > > > > > Current: > > > EVPN Virtual Ethernet Segments > > > > > > Perhaps: > > > EVPN and Provider Backbone Bridge EVPN Solutions for > > > Virtual Ethernet Segments > > > --> > > > > > > Ali> I would prefer “Virtual Ethernet Segments for EVPN and PBB-EVPN” for > > > the title > > > > > > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > > the title) for use on https://www.rfc-editor.org/search. > > > --> > > > > > > > > > 3) <!--[rfced] For clarity, may "on a per individual PW" be rephrased > > > as "on each PW"? Alternatively, if "individual" is necessary, then > > > perhaps "for each individual PW". > > > > > > Original: > > > For instance, if PW3 were terminated into a > > > third PE, e.g. PE3, instead of PE1, the vES would need to be defined > > > on a per individual PW on each PE. > > > > > > Perhaps: > > > For instance, if PW3 were terminated into a > > > third PE, e.g., PE3, instead of PE1, the vES would need to be defined > > > on each PW on each PE. > > > --> > > > > > > Ali> That’s fine. > > > > > > > > > 4) <!--[rfced] Section 3.2: Why is this item numbered "R3a" instead of > > > "R2a"? > > > In other words, The preceding section is R1a, R1b, etc., so > > > should this be "R2a" instead of "R3a"? > > > > > > Ali> Yes, it should be “R2a” because we removed one subsection. > > > > > > > > > If your answer is "R2a", then the subsequent requirements will be > > > updated as well (i.e. R4a, R4b, etc., will become R3a, R3b, etc.) > > > > > > Ali> Yes. > > > > > > > > > Original: > > > (R3a) A PE device that supports the vES function MUST support local > > > switching among different vESes associated with the same service > > > instance on a single physical port. > > > --> > > > > > > > > > 5) <!--[rfced] Section 3.4: FYI, we changed "Rbc" to"R5b". > > > Rationale: The preceding item is R5a, and the numbering in the > > > preceding section is R4a, R4b, R4c, etc. Please let us know if > > > you intended otherwise. > > > > > > Original: > > > (Rbc) Each vES MUST be identified by its own virtual ESI (vESI). > > > > > > Current: > > > (R5b) Each vES MUST be identified by its own virtual ESI (vESI). > > > --> > > > > > > Ali> Updated text is fine. > > > > > > > > > 6) <!--[rfced] We had trouble parsing this sentence and updated it for > > > clarity as shown below. Please let us know if it changes the > > > intended meaning. > > > > > > Original: > > > Since many EVCs (and their associated vESes) are aggregated via a > > > single physical port (e.g., ENNI), then the failure of that physical > > > port impacts many vESes and triggers equally many ES route > > > withdrawals. > > > > > > Perhaps: > > > Since many EVCs (and their associated vESes) are aggregated via a > > > single physical port (e.g., ENNI), when there is a failure of that > > > physical port, it impacts many vESes and equally triggers many ES route > > > withdrawals. > > > --> > > > > > > Ali> Updated text is fine. > > > > > > > > > 7) <!-- [rfced] We note that RFC 7623 does not contain Section > > > 7.2.1.1. Was Section 6.2.1.1 ("PE B-MAC Address Assignment") > > > perhaps intended > > > <https://www.rfc-editor.org/rfc/rfc7623#section-6.2.1.1>? > > > > > > Ali> Correct. It should be changed to 6.2.1.1. > > > > > > > > > Original: > > > For PBB-EVPN solution, the main change is with respect to the B-MAC > > > address assignment which is performed similar to what is described in > > > section 7.2.1.1 of [RFC7623] with the following refinements: > > > --> > > > > > > > > > 8) <!--[rfced] Is a word missing after "Single-Active" in the following > > > sentence? Perhaps "scenario"? > > > > > > Original: > > > In case of a Single-Active, when a service moves from one PE in the > > > Redundancy Group to another PE because of DF re-election, the PE, > > > which ends up being the elected DF for the service, MUST trigger a > > > MAC address flush notification towards the associated vES if the > > > multi-homing device is a bridge or the multi-homing network is an > > > Ethernet bridged network. > > > --> > > > > > > Ali> That’s correct – “Single-Active scenario” > > > > > > 9) <!--[rfced] Please clarify "instead of NULL value". Is the intended > > > meaning that an I-SID is carried in the Ethernet Tag ID field > > > instead of in the NULL value (Perhaps A) or that the route is > > > modified to carry an I-SID instead of a NULL value (Perhaps B)? > > > > > > Original: > > > [RFC9541] introduces B-MAC/I-SID route where existing PBB-EVPN B-MAC > > > route is modified to carry an I-SID in the "Ethernet Tag ID" field > > > instead of NULL value. > > > > > > Perhaps A: > > > [RFC9541] introduces a B-MAC/I-SID route where the existing PBB-EVPN > > > B-MAC > > > route is modified to carry an I-SID in the "Ethernet Tag ID" field > > > instead > > > of in the NULL value. > > > or > > > > > > Perhaps B: > > > [RFC9541] introduces a B-MAC/I-SID route where the existing PBB-EVPN > > > B-MAC > > > route is modified to carry an I-SID, instead of a NULL value, in the > > > "Ethernet Tag ID" field. > > > --> > > > > > > Ali> (B) is correct! > > > > > > 10) <!--[rfced] Please clarify if "one for each VLAN" is the same as "one > > > for each I-SID"? And does "one" mean "one route"? > > > > > > Original: > > > However, if the failed EVC carries multiple VLANs each with its own > > > broadcast domain, then the affected PE needs to advertise multiple > > > B-MAC/I-SID routes - one for each VLAN (broadcast domain) - i.e., > > > one for each I-SID. > > > > > > Perhaps: > > > However, if the failed EVC carries multiple VLANs each with its own > > > broadcast domain, then the affected PE needs to advertise multiple > > > B-MAC/I-SID routes, i.e., one route for each VLAN (broadcast domain), > > > meaning one route for each I-SID. > > > --> > > > > > > Ali> Updated text is correct! > > > > > > 11) <!--[rfced] Please clarify what "(1)" is referring to in the > > > text below. Is "(1)" within the same section (Section 5.3) or a > > > different section? Or, perhaps "one (1)" was intended? > > > > > > Original: > > > 4. When this message is received, the remote PE MAY detect the > > > special vES mass-withdraw message by identifying the Grouping > > > Ethernet A-D per ES route. The remote PEs MAY then access the > > > list created in (1) of the vESes for the specified color, and > > > initiate locally MAC address invalidating procedures for each of > > > the vESes in the list. > > > --> > > > > > > Ali> Yes, (1) refers to the same section. Perhaps “1.” should be used? > > > > > > > > > 12) <!-- [rfced] We found the following URL for [MEF63]: > > > https://www.mef.net/resources/mef-6-3-subscriber-ethernet-service-definitions/. > > > May we add this URL to the reference entry for easy access? > > > > > > Original: > > > [MEF63] Metro Ethernet Forum, "Subscriber Ethernet Services > > > Definitions", MEF Standard, MEF 6.3, November 2019. > > > > > > Perhaps: > > > [MEF63] Metro Ethernet Forum, "Subscriber Ethernet Services > > > Definitions", MEF Standard, MEF 6.3, November 2019, > > > <https://www.mef.net/resources/mef-6-3-subscriber- > > > ethernet-service-definitions>. > > > --> > > > > > > Ali> Yes, thanks! > > > > > > 13) <!-- [rfced] Terminology > > > > > > a) Throughout the text, the following terminology appears to be used > > > inconsistently. Please review these occurrences and let us know if/how > > > they may be made consistent. > > > > > > Ethernet A-D per ES route (16) vs. > > > Ethernet A-D per ES (5) > > > [Note: should "route" be added to the 5 instances that > > > do not include it? > > > > > > Ali> Yes! > > > > > > MAC Mobility Extended Community vs. > > > MAC Mobility Extended community vs. > > > MAC mobility Extended community > > > [Note that the case used in RFCs 7432 and 7623 is > > > "MAC Mobility extended community".] > > > > > > Ali> should be made consistent with RFC 7432 & 7623 > > > > > > b) For consistency, we updated the document to use the form on the > > > right. Please let us know of any objections. > > > > > > Core Network -> core network > > > DF Election -> DF election > > > Ethernet segment -> Ethernet Segment > > > Multi-Homed and Multi-homed -> multi-homed > > > Redundancy Group -> redundancy group > > > Service Provider -> service provider > > > Single-homed -> single-homed > > > > > > Ali> Yes, that’s fine. > > > > > > c) May "multi-homed" and "multi-homing" > > > be changed to "multihomed" and "multihoming" per common > > > use in the RFC series (and in particular, in RFCs 7432, > > > 7623, and 8584)? Your reply to this will be applied to the > > > other documents in this cluster (9785 and 9786). > > > --> > > > > > > Ali> Yes, that’s fine. > > > > > > 14) <!-- [rfced] Abbreviations > > > > > > a) FYI: We have added expansions for the following abbreviations > > > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > > expansion in the document carefully to ensure correctness. > > > > > > - Label Distribution Protocol (LDP) > > > - Media Access Control (MAC) > > > > > > Ali> Yes, that’s fine. > > > > > > b) For consistency (within the RFC series and cluster 492), we updated > > > this document to use the forms on the right. Please let us know of > > > any objections. > > > > > > All-Active Redundancy Mode (AA) -> All-Active (AA) Redundancy Mode > > > > > > Broadcast, Unknown-unicast, Multicast (BUM) -> > > > Broadcast, Unknown Unicast, and Multicast (BUM) (per RFC 7432) > > > > > > External Network-to-Network Interface (ENNI) (Section 1.2) vs. > > > External Network-Network Interface (Section 2) > > > -> updated to the latter for consistency. > > > > > > Provider Backbone (PBB) -> Provider Backbone Bridge (PBB) (per RFC 7623) > > > > > > Single-Active Redundancy Mode (SA) -> Single-Active (SA) Redundancy Mode > > > > > > Virtual Pseudowire Service (VPWS) -> > > > Virtual Private Wire Service (VPWS) (per RFC 8214) > > > > > > Ali> Yes, all the above are fine. > > > > > > c) Please let us know how we may expand the following term: > > > > > > - SH (in the title of Figure 1) > > > > > > Ali> single-homed > > > > > > d) As recommended in the Web Portion of the Style Guide > > > <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>, > > > once an abbreviation is introduced, the abbreviated form > > > should be used thereafter. Please consider if you would > > > like to apply this style for the following term: > > > > > > - Ethernet Segment (ES) -> use "ES" thereafter > > > --> > > > > > > Ali> Yes! > > > > > > 15) <!-- [rfced] Please review the "Inclusive Language" portion of the > > > online > > > Style Guide > > > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > > and let us know if any changes are needed. Updates of this nature > > > typically > > > result in more precise language, which is helpful for readers. > > > > > > Note that our script did not flag any words in particular, but this > > > should > > > still be reviewed as a best practice. > > > --> > > > > > > Ali> we are good! > > > > > > Thank you. > > > > > > RFC Editor/kc/ar > > > > > > > > > On May 15, 2025, [email protected] wrote: > > > > > > *****IMPORTANT***** > > > > > > Updated 2025/05/15 > > > > > > RFC Author(s): > > > -------------- > > > > > > Instructions for Completing AUTH48 > > > > > > Your document has now entered AUTH48. Once it has been reviewed and > > > approved by you and all coauthors, it will be published as an RFC. > > > If an author is no longer available, there are several remedies > > > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > > > > > You and you coauthors are responsible for engaging other parties > > > (e.g., Contributors or Working Group) as necessary before providing > > > your approval. > > > > > > Planning your review > > > --------------------- > > > > > > Please review the following aspects of your document: > > > > > > * RFC Editor questions > > > > > > Please review and resolve any questions raised by the RFC Editor > > > that have been included in the XML file as comments marked as > > > follows: > > > > > > <!-- [rfced] ... --> > > > > > > These questions will also be sent in a subsequent email. > > > > > > * Changes submitted by coauthors > > > > > > Please ensure that you review any changes submitted by your > > > coauthors. We assume that if you do not speak up that you > > > agree to changes submitted by your coauthors. > > > > > > * Content > > > > > > Please review the full content of the document, as this cannot > > > change once the RFC is published. Please pay particular attention to: > > > - IANA considerations updates (if applicable) > > > - contact information > > > - references > > > > > > * Copyright notices and legends > > > > > > Please review the copyright notice and legends as defined in > > > RFC 5378 and the Trust Legal Provisions > > > (TLP – https://trustee.ietf.org/license-info). > > > > > > * Semantic markup > > > > > > Please review the markup in the XML file to ensure that elements of > > > content are correctly tagged. For example, ensure that <sourcecode> > > > and <artwork> are set correctly. See details at > > > <https://authors.ietf.org/rfcxml-vocabulary>. > > > > > > * Formatted output > > > > > > Please review the PDF, HTML, and TXT files to ensure that the > > > formatted output, as generated from the markup in the XML file, is > > > reasonable. Please note that the TXT will have formatting > > > limitations compared to the PDF and HTML. > > > > > > > > > Submitting changes > > > ------------------ > > > > > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > > > the parties CCed on this message need to see your changes. The parties > > > include: > > > > > > * your coauthors > > > > > > * [email protected] (the RPC team) > > > > > > * other document participants, depending on the stream (e.g., > > > IETF Stream participants are your working group chairs, the > > > responsible ADs, and the document shepherd). > > > > > > * [email protected], which is a new archival mailing list > > > to preserve AUTH48 conversations; it is not an active discussion > > > list: > > > > > > * More info: > > > > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > > > > > * The archive itself: > > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > > > > * Note: If only absolutely necessary, you may temporarily opt out > > > of the archiving of messages (e.g., to discuss a sensitive matter). > > > If needed, please add a note at the top of the message that you > > > have dropped the address. When the discussion is concluded, > > > [email protected] will be re-added to the CC list and > > > its addition will be noted at the top of the message. > > > > > > You may submit your changes in one of two ways: > > > > > > An update to the provided XML file > > > — OR — > > > An explicit list of changes in this format > > > > > > Section # (or indicate Global) > > > > > > OLD: > > > old text > > > > > > NEW: > > > new text > > > > > > You do not need to reply with both an updated XML file and an explicit > > > list of changes, as either form is sufficient. > > > > > > We will ask a stream manager to review and approve any changes that seem > > > beyond editorial in nature, e.g., addition of new text, deletion of text, > > > and technical changes. Information about stream managers can be found in > > > the FAQ. Editorial changes do not require approval from a stream manager. > > > > > > > > > Approving for publication > > > -------------------------- > > > > > > To approve your RFC for publication, please reply to this email stating > > > that you approve this RFC for publication. Please use ‘REPLY ALL’, > > > as all the parties CCed on this message need to see your approval. > > > > > > > > > Files > > > ----- > > > > > > The files are available here: > > > https://www.rfc-editor.org/authors/rfc9784.xml > > > https://www.rfc-editor.org/authors/rfc9784.html > > > https://www.rfc-editor.org/authors/rfc9784.pdf > > > https://www.rfc-editor.org/authors/rfc9784.txt > > > > > > Diff file of the text: > > > https://www.rfc-editor.org/authors/rfc9784-diff.html > > > https://www.rfc-editor.org/authors/rfc9784-rfcdiff.html (side by side) > > > > > > Diff of the XML: > > > https://www.rfc-editor.org/authors/rfc9784-xmldiff1.html > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > https://www.rfc-editor.org/auth48/rfc9784 > > > > > > Please let us know if you have any questions. > > > > > > Thank you for your cooperation, > > > > > > RFC Editor > > > > > > -------------------------------------- > > > RFC9784 (draft-ietf-bess-evpn-virtual-eth-segment-19) > > > > > > Title : EVPN Virtual Ethernet Segments > > > Author(s) : A. Sajassi, P. Brissette, R. Schell, J. Drake, J. > > > Rabadan > > > WG Chair(s) : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) > > > Zhang > > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
