Hi karen, Rick’s email is: rick_sch...@outlook.com<mailto:rick_sch...@outlook.com> Please change his designation to “Independent” from “Verizon”
Thanks, Ali From: Karen Moore <kmo...@staff.rfc-editor.org> Date: Monday, June 16, 2025 at 12:38 PM To: Ali Sajassi (sajassi) <saja...@cisco.com>, jdr...@juniper.net <jdr...@juniper.net>, jorge.raba...@nokia.com <jorge.raba...@nokia.com>, Patrice Brissette (pbrisset) <pbris...@cisco.com>, richard.sch...@verizon.com <richard.sch...@verizon.com> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, laburdet.i...@gmail.com <laburdet.i...@gmail.com>, gunter.van_de_ve...@nokia.com <gunter.van_de_ve...@nokia.com>, auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9784 <draft-ietf-bess-evpn-virtual-eth-segment-19> for your review Authors, We have received a failed delivery message for Richard (richard.sch...@verizon.com). Does anyone happen to have an alternate email address for Richard? Thanks, RFC Editor/kc > On Jun 16, 2025, at 11:51 AM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: > > 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 > > … > 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. > > 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. >> --> > > > > Best regards, > RFC Editor/kc > > >> On Jun 15, 2025, at 10:09 PM, Ali Sajassi (sajassi) <saja...@cisco.com> >> wrote: >> >> Hi Karen, >> >> Please refer to my comments inline marked with Ali>> >> >> From: Karen Moore <kmo...@staff.rfc-editor.org> >> Date: Tuesday, June 10, 2025 at 6:21 PM >> To: Ali Sajassi (sajassi) <saja...@cisco.com>, >> jorge.raba...@nokia.com<jorge.raba...@nokia.com>, richard.sch...@verizon.com >> <richard.sch...@verizon.com>, Ali Sajassi (sajassi) <saja...@cisco.com>, >> Patrice Brissette (pbrisset) <pbris...@cisco.com> >> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, >> jdr...@juniper.net <jdr...@juniper.net>, bess-...@ietf.org >> <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, >> laburdet.i...@gmail.com <laburdet.i...@gmail.com>, >> gunter.van_de_ve...@nokia.com<gunter.van_de_ve...@nokia.com>, >> auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> >> 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) >>> <sajassi=40cisco....@dmarc.ietf.org> 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: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>> Date: Thursday, May 15, 2025 at 1:28 PM >>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Patrice Brissette (pbrisset) >>> <pbris...@cisco.com>, richard.sch...@verizon.com >>> <richard.sch...@verizon.com>, jdr...@juniper.net <jdr...@juniper.net>, >>> jorge.raba...@nokia.com <jorge.raba...@nokia.com> >>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, >>> bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org >>> <bess-cha...@ietf.org>, laburdet.i...@gmail.com <laburdet.i...@gmail.com>, >>> gunter.van_de_ve...@nokia.com <gunter.van_de_ve...@nokia.com>, >>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> >>> 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, rfc-edi...@rfc-editor.org 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 >>> >>> * rfc-edi...@rfc-editor.org (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). >>> >>> * auth48archive@rfc-editor.org, 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, >>> auth48archive@rfc-editor.org 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
