Hi James and John,

We have updated your email addresses and affiliations accordingly.

Thank you,
RFC Editor/st

> On Mar 10, 2025, at 2:47 PM, je_dr...@yahoo.com wrote:
> 
> Sarah,
> 
> Would you please also change my affiliation to ‘Independent’?
> 
> Thanks,
> 
> John
> 
> Sent from my iPhone
> 
>> On Mar 10, 2025, at 12:35 PM, je_dr...@yahoo.com wrote:
>> 
>> Thanks!
>> 
>> Sent from my iPhone
>> 
>>> On Mar 10, 2025, at 12:14 PM, Sarah Tarrant <starr...@staff.rfc-editor.org> 
>>> wrote:
>>> 
>>> Hi John,
>>> 
>>> We have updated your email address accordingly.
>>> 
>>> We will await approvals from each of the parties listed at the AUTH48 
>>> status page prior to moving this document forward in the publication 
>>> process (see https://www.rfc-editor.org/auth48/rfc9744).
>>> 
>>> Thank you,
>>> RFC Editor/st
>>> 
>>>>> On Mar 10, 2025, at 8:37 AM, je_dr...@yahoo.com wrote:
>>>> 
>>>> Sarah,
>>>> 
>>>> Please update my email address in the RFC to be.
>>>> 
>>>> Thanks,
>>>> 
>>>> John
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>>> On Mar 10, 2025, at 9:34 AM, Sarah Tarrant 
>>>>>> <starr...@staff.rfc-editor.org> wrote:
>>>>> 
>>>>> Hi John and Patrice,
>>>>> 
>>>>> Thank you for your replies. We have marked your approval on the AUTH48 
>>>>> status page for this document (see 
>>>>> https://www.rfc-editor.org/auth48/rfc9744).
>>>>> 
>>>>> John - Apologies for this email chain from not getting to your correct 
>>>>> email. Would you like to have your information in the draft be updated? 
>>>>> Also, the entire email thread for this pending RFC can be viewed at the 
>>>>> IETF Mail Archive: https://mailarchive.ietf.org/arch/.
>>>>> 
>>>>> We will await approvals from each of the parties listed at the AUTH48 
>>>>> status page prior to moving this document forward in the publication 
>>>>> process.
>>>>> 
>>>>> Thank you,
>>>>> RFC Editor/st
>>>>> 
>>>>>> On Mar 7, 2025, at 3:52 PM, Patrice Brissette (pbrisset) 
>>>>>> <pbris...@cisco.com> wrote:
>>>>>> 
>>>>>> Hi everyone,
>>>>>> The document looks very good. Thanks for the hard work from Ali and 
>>>>>> everyone.
>>>>>> I approve it.
>>>>>> Regards,
>>>>>> Patrice Brissette
>>>>>> Distinguished Engineer
>>>>>> Cisco Systems
>>>>>> From: Sarah Tarrant <starr...@staff.rfc-editor.org>
>>>>>> Date: Thursday, March 6, 2025 at 10:09
>>>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Patrice Brissette 
>>>>>> (pbrisset) <pbris...@cisco.com>, utt...@att.com <utt...@att.com>, 
>>>>>> jdr...@juniper.net <jdr...@juniper.net>, sbout...@ciena.com 
>>>>>> <sbout...@ciena.com>, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, 
>>>>>> Matthew Bocci (Nokia) <matthew.bo...@nokia.com>
>>>>>> Cc: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, 
>>>>>> rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, bess-...@ietf.org 
>>>>>> <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, 
>>>>>> slitkows.i...@gmail.com <slitkows.i...@gmail.com>, 
>>>>>> auth48archive@rfc-editor.org <auth48archive@rfc-editor.org>
>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> 
>>>>>> for your review
>>>>>> Hello all,
>>>>>> 
>>>>>> We have updated the document accordingly and have no further questions 
>>>>>> or comments. We will await approvals from each author prior to moving 
>>>>>> forward in the publication process.
>>>>>> 
>>>>>> Please review the document carefully to ensure satisfaction as we do not 
>>>>>> make changes once it has been published as an RFC. Contact us with any 
>>>>>> further updates or with your approval of the document in its current 
>>>>>> form.
>>>>>> 
>>>>>> The updated files have been posted here (please refresh):
>>>>>> https://www.rfc-editor.org/authors/rfc9744.txt
>>>>>> https://www.rfc-editor.org/authors/rfc9744.pdf
>>>>>> https://www.rfc-editor.org/authors/rfc9744.html
>>>>>> https://www.rfc-editor.org/authors/rfc9744.xml
>>>>>> 
>>>>>> The relevant diff files have been posted here (please refresh):
>>>>>> https://www.rfc-editor.org/authors/rfc9744-diff.html (comprehensive diff)
>>>>>> https://www.rfc-editor.org/authors/rfc9744-auth48diff.html (AUTH48 
>>>>>> changes only)
>>>>>> 
>>>>>> Note that it may be necessary for you to refresh your browser to view 
>>>>>> the most recent version.
>>>>>> 
>>>>>> For the AUTH48 status of this document, please see:
>>>>>> https://www.rfc-editor.org/auth48/rfc9744
>>>>>> 
>>>>>> Thank you,
>>>>>> RFC Editor/st
>>>>>> 
>>>>>>>> On Mar 6, 2025, at 4:42 AM, Matthew Bocci (Nokia) 
>>>>>>>> <matthew.bo...@nokia.com> wrote:
>>>>>>> 
>>>>>>> Hi Sarah, Ali
>>>>>>> This looks good to me.
>>>>>>> Thanks
>>>>>>> Matthew
>>>>>>> From: Sarah Tarrant <starr...@staff.rfc-editor.org>
>>>>>>> Date: Wednesday, 5 March 2025 at 20:14
>>>>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Gunter van de Velde 
>>>>>>> (Nokia) <gunter.van_de_ve...@nokia.com>, Matthew Bocci (Nokia) 
>>>>>>> <matthew.bo...@nokia.com>
>>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice 
>>>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com 
>>>>>>> <utt...@att.com>, jdr...@juniper.net <jdr...@juniper.net>, 
>>>>>>> sbout...@ciena.com<sbout...@ciena.com>, Jorge Rabadan (Nokia) 
>>>>>>> <jorge.raba...@nokia.com>,bess-...@ietf.org <bess-...@ietf.org>, 
>>>>>>> bess-cha...@ietf.org <bess-cha...@ietf.org>, slitkows.i...@gmail.com 
>>>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org 
>>>>>>> <auth48archive@rfc-editor.org>
>>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> 
>>>>>>> for your review
>>>>>>> [You don't often get email from starr...@staff.rfc-editor.org. Learn 
>>>>>>> why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>>>>> 
>>>>>>> CAUTION: This is an external email. Please be very careful when 
>>>>>>> clicking links or opening attachments. See the URL nok.it/ext for 
>>>>>>> additional information.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Hi Ali, Gunter, and Matthew,
>>>>>>> 
>>>>>>> Thank you for your replies.
>>>>>>> 
>>>>>>> Ali - Thank you for the new proposed text.
>>>>>>> 
>>>>>>> Gunter - Thank you for your approval of Ali's proposed text.
>>>>>>> 
>>>>>>> Matthew - Are there any objections to Ali's proposed text and document 
>>>>>>> updates? We ask because Ali wrote:
>>>>>>> 
>>>>>>>> Hi Sarah, if no objections from Matthew and Gunter, then please update 
>>>>>>>> the draft accordingly.
>>>>>>> 
>>>>>>> A)
>>>>>>> Original:
>>>>>>> Additionally, when the remote ES fails and the PE receives the "mass
>>>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE
>>>>>>> device can quickly update its BGP list of available remote entries to
>>>>>>> invalidate all VPWS service tunnels sharing the ESI field and achieve
>>>>>>> fast convergence for multi-homing scenarios.  Even if fast
>>>>>>> convergence was not needed, there would still be a need for signaling
>>>>>>> each AC failure (via its corresponding VPWS service tunnel)
>>>>>>> associated with the failed ES so that the BGP path list for each of
>>>>>>> them gets updated accordingly and the packets are sent to a backup PE
>>>>>>> (in case of Single-Active multi-homing) or to other PEs in the
>>>>>>> redundancy group (in case of All-Active multi-homing).  In the
>>>>>>> absence of updating the BGP path list, the traffic for that VPWS
>>>>>>> service tunnel will be black-holed.
>>>>>>> 
>>>>>>> Proposed:
>>>>>>> Additionally, when the remote ES fails and the PE receives the "mass
>>>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE
>>>>>>> device can quickly update its next-hop adjacency list (adjacency list)
>>>>>>> for all VPWS service tunnels sharing the ESI field and achieve
>>>>>>> fast convergence for multi-homing scenarios.  Even if fast
>>>>>>> convergence was not needed, there would still be a need for signaling
>>>>>>> each AC failure (via its corresponding VPWS service tunnel)
>>>>>>> associated with the failed ES so that the adjacency list
>>>>>>> gets updated and the packets are sent to a backup PE
>>>>>>> (in case of Single-Active multi-homing) or to other PEs in the
>>>>>>> redundancy group (in case of All-Active multi-homing). In the
>>>>>>> absence of updating the adjacency list properly, the
>>>>>>> traffic for that VPWS service tunnel will be dropped by the egress PE 
>>>>>>> with a failed ES/AC.
>>>>>>> 
>>>>>>> B)
>>>>>>> Original:
>>>>>>> *  Default FXC (Figure 1): In the default mode, a VLAN or AC failure
>>>>>>>  is not signaled.  Consequently, in case of an AC failure, such as
>>>>>>>  VID1 on CE2, there is nothing to prevent PE3 from directing
>>>>>>>  traffic from CE4 to PE1, leading to a potential black hole.
>>>>>>> 
>>>>>>> Proposed:
>>>>>>> *  Default FXC (Figure 1): In the default mode, a VLAN or AC failure
>>>>>>>  is not signaled.  Consequently, in case of an AC failure, such as
>>>>>>>  VID1 on CE2, there is nothing to prevent PE3 from directing
>>>>>>>  traffic from CE4 to PE1, leading to a potential packet loss at the 
>>>>>>> egress
>>>>>>>  PE with a failed AC.
>>>>>>> 
>>>>>>> C)
>>>>>>> Replace all instances of the following terms with "adjacency list":
>>>>>>> BGP list
>>>>>>> BGP path list
>>>>>>> path list
>>>>>>> 
>>>>>>> Sincerely,
>>>>>>> RFC Editor/st
>>>>>>> 
>>>>>>> 
>>>>>>>> On Mar 5, 2025, at 1:16 PM, Ali Sajassi (sajassi) <saja...@cisco.com> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Thanks Gunter!
>>>>>>>> Sarah, can you please update the draft based on the proposed text.
>>>>>>>> Thanks very much,
>>>>>>>> Ali
>>>>>>>> From: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>
>>>>>>>> Date: Wednesday, March 5, 2025 at 12:09 AM
>>>>>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Matthew Bocci (Nokia) 
>>>>>>>> <matthew.bo...@nokia.com>, Sarah Tarrant 
>>>>>>>> <starr...@staff.rfc-editor.org>, Ali Sajassi (sajassi) 
>>>>>>>> <sajassi=40cisco....@dmarc.ietf.org>
>>>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice 
>>>>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com 
>>>>>>>> <utt...@att.com>, jdr...@juniper.net <jdr...@juniper.net>, 
>>>>>>>> sbout...@ciena.com <sbout...@ciena.com>, Jorge Rabadan (Nokia) 
>>>>>>>> <jorge.raba...@nokia.com>, bess-...@ietf.org <bess-...@ietf.org>, 
>>>>>>>> bess-cha...@ietf.org <bess-cha...@ietf.org>, slitkows.i...@gmail.com 
>>>>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org 
>>>>>>>> <auth48archive@rfc-editor.org>
>>>>>>>> Subject: RE: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> 
>>>>>>>> for your review
>>>>>>>> Ali,
>>>>>>>> Thanks. This sounds good to me, and approved. It describes the failure 
>>>>>>>> impacts more accurately.
>>>>>>>> G/
>>>>>>>> From: Ali Sajassi (sajassi) <saja...@cisco.com>
>>>>>>>> Sent: Wednesday, March 5, 2025 4:44 AM
>>>>>>>> To: Matthew Bocci (Nokia) <matthew.bo...@nokia.com>; Gunter van de 
>>>>>>>> Velde (Nokia) <gunter.van_de_ve...@nokia.com>; Sarah Tarrant 
>>>>>>>> <starr...@staff.rfc-editor.org>; Ali Sajassi (sajassi) 
>>>>>>>> <sajassi=40cisco....@dmarc.ietf.org>
>>>>>>>> Cc: rfc-edi...@rfc-editor.org; Patrice Brissette (pbrisset) 
>>>>>>>> <pbris...@cisco.com>; utt...@att.com; jdr...@juniper.net; 
>>>>>>>> sbout...@ciena.com; Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>; 
>>>>>>>> bess-...@ietf.org; bess-cha...@ietf.org; slitkows.i...@gmail.com; 
>>>>>>>> auth48archive@rfc-editor.org
>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> 
>>>>>>>> for your review
>>>>>>>> CAUTION: This is an external email. Please be very careful when 
>>>>>>>> clicking links or opening attachments. See the URL nok.it/ext for 
>>>>>>>> additional information.
>>>>>>>> Hi Matthew, Gunter:  Thanks for your input. In the context of the 
>>>>>>>> failure scenarios that is being discussed, there won’t be a routing 
>>>>>>>> loop or other misrouting but rather a traffic loss (aka black hole). I 
>>>>>>>> think for better clarification,  the term “next-hop adjacencies” needs 
>>>>>>>> to be used instead of “BGP path list”. So, I’d like to purpose the 
>>>>>>>> following changes:
>>>>>>>> Hi Sarah, if no objections from Matthew and Gunter, then please update 
>>>>>>>> the draft accordingly.
>>>>>>>> ORIGINAL#1:
>>>>>>>> Additionally, when the remote ES fails and the PE receives the "mass
>>>>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE
>>>>>>>> device can quickly update its BGP list of available remote entries to
>>>>>>>> invalidate all VPWS service tunnels sharing the ESI field and achieve
>>>>>>>> fast convergence for multi-homing scenarios.  Even if fast
>>>>>>>> convergence was not needed, there would still be a need for signaling
>>>>>>>> each AC failure (via its corresponding VPWS service tunnel)
>>>>>>>> associated with the failed ES so that the BGP path list for each of
>>>>>>>> them gets updated accordingly and the packets are sent to a backup PE
>>>>>>>> (in case of Single-Active multi-homing) or to other PEs in the
>>>>>>>> redundancy group (in case of All-Active multi-homing).  In the
>>>>>>>> absence of updating the BGP path list, the traffic for that VPWS
>>>>>>>> service tunnel will be black-holed.
>>>>>>>> PROPOSED#1:
>>>>>>>> Additionally, when the remote ES fails and the PE receives the "mass
>>>>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE
>>>>>>>> device can quickly update its next-hop adjacency list (adjacency list)
>>>>>>>> for all VPWS service tunnels sharing the ESI field and achieve
>>>>>>>> fast convergence for multi-homing scenarios.  Even if fast
>>>>>>>> convergence was not needed, there would still be a need for signaling
>>>>>>>> each AC failure (via its corresponding VPWS service tunnel)
>>>>>>>> associated with the failed ES so that the adjacency list
>>>>>>>> gets updated and the packets are sent to a backup PE
>>>>>>>> (in case of Single-Active multi-homing) or to other PEs in the
>>>>>>>> redundancy group (in case of All-Active multi-homing). In the
>>>>>>>> absence of updating the adjacency list properly, the
>>>>>>>> traffic for that VPWS service tunnel will be dropped by the    egress 
>>>>>>>> PE with a failed ES/AC.
>>>>>>>> 
>>>>>>>> ORIGINAL#2:
>>>>>>>> *  Default FXC (Figure 1): In the default mode, a VLAN or AC failure
>>>>>>>>  is not signaled.  Consequently, in case of an AC failure, such as
>>>>>>>>  VID1 on CE2, there is nothing to prevent PE3 from directing
>>>>>>>>  traffic from CE4 to PE1, leading to a potential black hole.
>>>>>>>> 
>>>>>>>> PROPOSED#2:
>>>>>>>> *  Default FXC (Figure 1): In the default mode, a VLAN or AC failure
>>>>>>>>  is not signaled.  Consequently, in case of an AC failure, such as
>>>>>>>>  VID1 on CE2, there is nothing to prevent PE3 from directing
>>>>>>>>  traffic from CE4 to PE1, leading to a potential packet loss at the 
>>>>>>>> egress
>>>>>>>>  PE with a failed AC.
>>>>>>>> Also please replace all instances of  “BGP list” or “BGP path list” or 
>>>>>>>> “path list” with “adjacency list” throughout the document.
>>>>>>>> Cheers,
>>>>>>>> Ali
>>>>>>>> From: Matthew Bocci (Nokia) <matthew.bo...@nokia.com>
>>>>>>>> Date: Tuesday, March 4, 2025 at 7:02 AM
>>>>>>>> To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, Sarah 
>>>>>>>> Tarrant <starr...@staff.rfc-editor.org>, Ali Sajassi (sajassi) 
>>>>>>>> <sajassi=40cisco....@dmarc.ietf.org>
>>>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice 
>>>>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com 
>>>>>>>> <utt...@att.com>,jdr...@juniper.net <jdr...@juniper.net>, 
>>>>>>>> sbout...@ciena.com<sbout...@ciena.com>, Jorge Rabadan (Nokia) 
>>>>>>>> <jorge.raba...@nokia.com>, Ali Sajassi (sajassi) <saja...@cisco.com>, 
>>>>>>>> bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org 
>>>>>>>> <bess-cha...@ietf.org>,slitkows.i...@gmail.com 
>>>>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org 
>>>>>>>> <auth48archive@rfc-editor.org>
>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> 
>>>>>>>> for your review
>>>>>>>> I am not sure “pathologies” is the right word here. Can I suggest 
>>>>>>>> rephrasing that sentence to “potential routing loops or other 
>>>>>>>> conditions where traffic is unintentionally misrouted or discarded.”
>>>>>>>> Matthew
>>>>>>>> From: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>
>>>>>>>> Date: Tuesday, 4 March 2025 at 12:37
>>>>>>>> To: Sarah Tarrant <starr...@staff.rfc-editor.org>, Ali Sajassi 
>>>>>>>> (sajassi) <sajassi=40cisco....@dmarc.ietf.org>
>>>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice 
>>>>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com 
>>>>>>>> <utt...@att.com>,jdr...@juniper.net <jdr...@juniper.net>, 
>>>>>>>> sbout...@ciena.com<sbout...@ciena.com>, Jorge Rabadan (Nokia) 
>>>>>>>> <jorge.raba...@nokia.com>, Ali Sajassi (sajassi) <saja...@cisco.com>, 
>>>>>>>> bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org 
>>>>>>>> <bess-cha...@ietf.org>,slitkows.i...@gmail.com 
>>>>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org 
>>>>>>>> <auth48archive@rfc-editor.org>
>>>>>>>> Subject: RE: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> 
>>>>>>>> for your review
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>>> For example, please consider whether the following should be updated:
>>>>>>>>> 
>>>>>>>>> black hole
>>>>>>>>> block-holed
>>>>>>>>> -->
>>>>>>>>> Ali> I would prefer “black hole” and “black holed”
>>>>>>>> 
>>>>>>>> Aloi, All, From an inclusiveness language would the following work?
>>>>>>>> 
>>>>>>>> ORIGINAL#1:
>>>>>>>> In the
>>>>>>>> absence of updating the BGP path list, the traffic for that VPWS
>>>>>>>> service tunnel will be black-holed.
>>>>>>>> 
>>>>>>>> PROPOSED#1:
>>>>>>>> In the
>>>>>>>> absence of updating the BGP path list, the traffic for that VPWS
>>>>>>>> service tunnel will ***suffer from routing loops, misrouting or other 
>>>>>>>> pathologies***.
>>>>>>>> 
>>>>>>>> ORIGINAL#2:
>>>>>>>> *  Default FXC (Figure 1): In the default mode, a VLAN or AC failure
>>>>>>>>  is not signaled.  Consequently, in case of an AC failure, such as
>>>>>>>>  VID1 on CE2, there is nothing to prevent PE3 from directing
>>>>>>>>  traffic from CE4 to PE1, leading to a potential black hole.
>>>>>>>> 
>>>>>>>> PROPOSED#2:
>>>>>>>> *  Default FXC (Figure 1): In the default mode, a VLAN or AC failure
>>>>>>>>  is not signaled.  Consequently, in case of an AC failure, such as
>>>>>>>>  VID1 on CE2, there is nothing to prevent PE3 from directing
>>>>>>>>  traffic from CE4 to PE1, leading to ***potential routing loops, 
>>>>>>>> misrouting or other pathologies***.
>>>>>>>> 
>>>>>>>> G/
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Sarah Tarrant <starr...@staff.rfc-editor.org>
>>>>>>>> Sent: Monday, March 3, 2025 6:08 PM
>>>>>>>> To: Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org>
>>>>>>>> Cc: rfc-edi...@rfc-editor.org; Patrice Brissette (pbrisset) 
>>>>>>>> <pbris...@cisco.com>;utt...@att.com; jdr...@juniper.net; 
>>>>>>>> sbout...@ciena.com; Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>; 
>>>>>>>> Ali Sajassi (sajassi) <saja...@cisco.com>; bess-...@ietf.org; 
>>>>>>>> bess-cha...@ietf.org; slitkows.i...@gmail.com; Gunter van de Velde 
>>>>>>>> (Nokia) <gunter.van_de_ve...@nokia.com>; auth48archive@rfc-editor.org
>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> 
>>>>>>>> for your review
>>>>>>>> 
>>>>>>>> 
>>>>>>>> CAUTION: This is an external email. Please be very careful when 
>>>>>>>> clicking links or opening attachments. See the URL nok.it/ext for 
>>>>>>>> additional information.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Ali,
>>>>>>>> 
>>>>>>>> Thank you for your reply. We have updated the document accordingly.
>>>>>>>> 
>>>>>>>> Please review the document carefully to ensure satisfaction as we do 
>>>>>>>> not make changes once it has been published as an RFC. Contact us with 
>>>>>>>> any further updates or with your approval of the document in its 
>>>>>>>> current form. We will await approvals from each author prior to moving 
>>>>>>>> forward in the publication process.
>>>>>>>> 
>>>>>>>> The updated files have been posted here (please refresh):
>>>>>>>> https://www.rfc-editor.org/authors/rfc9744.txt
>>>>>>>> https://www.rfc-editor.org/authors/rfc9744.pdf
>>>>>>>> https://www.rfc-editor.org/authors/rfc9744.html
>>>>>>>> https://www.rfc-editor.org/authors/rfc9744.xml
>>>>>>>> 
>>>>>>>> The relevant diff files have been posted here (please refresh):
>>>>>>>> https://www.rfc-editor.org/authors/rfc9744-diff.html (comprehensive 
>>>>>>>> diff)https://www.rfc-editor.org/authors/rfc9744-auth48diff.html 
>>>>>>>> (AUTH48 changes only)
>>>>>>>> 
>>>>>>>> Note that it may be necessary for you to refresh your browser to view 
>>>>>>>> the most recent version.
>>>>>>>> 
>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>> https://www.rfc-editor.org/auth48/rfc9744
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> RFC Editor/st
>>>>>>>> 
>>>>>>>>> On Feb 28, 2025, at 12:01 AM, Ali Sajassi (sajassi) 
>>>>>>>>> <sajassi=40cisco....@dmarc.ietf.org> wrote:
>>>>>>>>> 
>>>>>>>>> Dear RFC-Editor,
>>>>>>>>> Thanks you for your recommendations, please refer to my comments 
>>>>>>>>> inline marked with “Ali>” . Once they are incorporated, I will be 
>>>>>>>>> happy to approve it.
>>>>>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>
>>>>>>>>> Date: Wednesday, February 26, 2025 at 2:41 PM
>>>>>>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Patrice Brissette
>>>>>>>>> (pbrisset) <pbris...@cisco.com>, utt...@att.com <utt...@att.com>,
>>>>>>>>> jdr...@juniper.net<jdr...@juniper.net>, sbout...@ciena.com
>>>>>>>>> <sbout...@ciena.com>, 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>, slitkows.i...@gmail.com
>>>>>>>>> <slitkows.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 9744 <draft-ietf-bess-evpn-vpws-fxc-12>
>>>>>>>>> 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] Please note that the title of the document has been
>>>>>>>>> updated as follows. Abbreviations have been expanded per Section 3.6
>>>>>>>>> of RFC 7322 ("RFC Style Guide"). Please review.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> EVPN VPWS Flexible Cross-Connect Service
>>>>>>>>> 
>>>>>>>>> Current:
>>>>>>>>> EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC)
>>>>>>>>> Service
>>>>>>>>> -->
>>>>>>>>> Ali> That’ fine.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2) <!-- [rfced] We're having trouble understanding "can designate on"
>>>>>>>>> in the text below. Should this be updated to "can designate"?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> [RFC8214] describes a solution to deliver P2P services using BGP
>>>>>>>>> constructs defined in [RFC7432].  It delivers this P2P service
>>>>>>>>> between a pair of Attachment Circuits (ACs), where an AC can
>>>>>>>>> designate on a PE, a port, a VLAN on a port, or a group of VLANs on a
>>>>>>>>> port.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> [RFC8214] describes a solution to deliver P2P services using BGP
>>>>>>>>> constructs defined in [RFC7432].  It delivers this P2P service
>>>>>>>>> between a pair of Attachment Circuits (ACs), where an AC can
>>>>>>>>> designate a PE, a port, a VLAN on a port, or a group of VLANs on a
>>>>>>>>> port.
>>>>>>>>> -->
>>>>>>>>> Ali> It should be changed to “…, where an AC on a PE can represent a 
>>>>>>>>> port, a VLAN on a port, or a group of VLANs on a port.”
>>>>>>>>> 
>>>>>>>>> 3) <!--[rfced] To have a 1:1 matchup between the following
>>>>>>>>> abbreviations and their expansions, may we update as follows?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Ethernet A-D:  Ethernet Auto-Discovery (A-D) per EVI and Ethernet A-D
>>>>>>>>>  per ESI routes, as defined in [RFC7432] and [RFC8214].
>>>>>>>>> ...
>>>>>>>>> PE:  Provider Edge device
>>>>>>>>> ...
>>>>>>>>> VRF:  VPN Routing and Forwarding table
>>>>>>>>> ...
>>>>>>>>> IP-VRF:  VPN Routing and Forwarding table, for IP lookup
>>>>>>>>> ...
>>>>>>>>> MAC-VRF:  VPN Routing and Forwarding table, for MAC lookup
>>>>>>>>> ...
>>>>>>>>> VID-VRF:  VPN Routing and Forwarding table, for Normalized VID
>>>>>>>>> lookup
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> Ethernet A-D:  Ethernet Auto-Discovery (per EVI and per ESI routes,
>>>>>>>>> as defined in [RFC7432] and [RFC8214])
>>>>>>>>> Ali> also use “or” instead of “and”:  “ Ethernet A-D:  Ethernet 
>>>>>>>>> Auto-Discovery (per EVI or per ESI routes, as defined in [RFC7432] 
>>>>>>>>> and [RFC8214])”
>>>>>>>>> ...
>>>>>>>>> PE:  Provider Edge
>>>>>>>>> ...
>>>>>>>>> VRF:  VPN Routing and Forwarding
>>>>>>>>> ...
>>>>>>>>> IP-VRF:  VPN Routing and Forwarding for IP lookup
>>>>>>>>> 
>>>>>>>>> MAC-VRF:  VPN Routing and Forwarding for MAC lookup
>>>>>>>>> 
>>>>>>>>> VID-VRF:  VPN Routing and Forwarding for normalized VID lookup
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 4) <!-- [rfced] We were unable to find exactly "12-bit VPWS service
>>>>>>>>> instance identifiers" in [RFC8214]. We did find the following in 
>>>>>>>>> Section 3 of [RFC8214]:
>>>>>>>>> 
>>>>>>>>> The VPWS service instance identifier value MAY be set to a 24-bit 
>>>>>>>>> value,
>>>>>>>>> and when a 24-bit value is used, it MUST be right-aligned.
>>>>>>>>> 
>>>>>>>>> For a more accurate citation, may we update to something like the 
>>>>>>>>> following?
>>>>>>>>> 
>>>>>>>>> Current:
>>>>>>>>> As stated in [RFC8214], 12-bit and 24-bit VPWS service instance 
>>>>>>>>> identifiers
>>>>>>>>> representing normalized VIDs MUST be right-aligned.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> 24-bit VPWS service instance identifiers [RFC8214] as well as 12-bit
>>>>>>>>> VPWS service instance identifiers representing normalized VIDs MUST
>>>>>>>>> be right-aligned.
>>>>>>>>> -->
>>>>>>>>> Ali> That’s fine.
>>>>>>>>> 
>>>>>>>>> 5) <!--[rfced] To clarify the numbered list, we have updated this
>>>>>>>>> sentence in Section 3.2. Please review and ensure that the intended
>>>>>>>>> meaning has not changed. Note that we have made a similar update to a
>>>>>>>>> sentence in Section 3.3.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Additionally, this route
>>>>>>>>> is sent with the EVPN Layer-2 Extended Community defined in
>>>>>>>>> Section 3.1 of [RFC8214] with two new flags (outlined in Section 4)
>>>>>>>>> that indicate: 1) this VPWS service tunnel is for the default
>>>>>>>>> Flexible Cross-Connect, and 2) the normalized VID type (single versus
>>>>>>>>> double).
>>>>>>>>> 
>>>>>>>>> Current:
>>>>>>>>> Additionally, this route
>>>>>>>>> is sent with the EVPN Layer 2 Extended Community defined in
>>>>>>>>> Section 3.1 of [RFC8214] with two new flags (outlined in Section 4)
>>>>>>>>> that indicate: 1) this VPWS service tunnel for the default
>>>>>>>>> Flexible Cross-Connect and 2) the normalized VID type (single versus
>>>>>>>>> double).
>>>>>>>>> -->
>>>>>>>>> Ali>  Please change it to: “…  1) the VPW service tunnel (set to 
>>>>>>>>> default Flexible Cross-Connect) and 2) the normalized VID type (set 
>>>>>>>>> to normalized single-VID or double-VID)”
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 6) <!--[rfced] Please note that a slash (/) can mean "and", "or", or 
>>>>>>>>> "and/or".
>>>>>>>>> We have updated it to "and" in the text below for clarity. Please
>>>>>>>>> review and let us know if any further updates are needed.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> In this mode of operation, similar to the default FXC mode described
>>>>>>>>> in Section 3.2, many normalized VIDs representing ACs across several
>>>>>>>>> Ethernet Segments/interfaces are multiplexed into a single EVPN VPWS
>>>>>>>>> service tunnel.
>>>>>>>>> 
>>>>>>>>> Current:
>>>>>>>>> In this mode of operation, similar to the default FXC mode described
>>>>>>>>> in Section 3.2, many normalized VIDs representing ACs across several
>>>>>>>>> Ethernet Segments and interfaces are multiplexed into a single EVPN 
>>>>>>>>> VPWS
>>>>>>>>> service tunnel.
>>>>>>>>> -->
>>>>>>>>> Ali> That’s fine.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 7) <!--[rfced] May we remove "service" after "FXC" in the following 
>>>>>>>>> sentence?
>>>>>>>>> Additionally, please note that we have numbered the items listed to
>>>>>>>>> improve readability.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> However, only two VPWS
>>>>>>>>> Service Tunnels are required: VPWS Service Tunnel 1 (sv.T1) between
>>>>>>>>> PE1's FXC service and PE3's FXC, and VPWS Service Tunnel 2 (sv.T2)
>>>>>>>>> between PE2's FXC and PE3's FXC.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> However, only two VPWS
>>>>>>>>> Service Tunnels are required: 1) VPWS Service Tunnel 1 (sv.T1) between
>>>>>>>>> PE1's FXC and PE3's FXC and 2) VPWS Service Tunnel 2 (sv.T2)
>>>>>>>>> between PE2's FXC and PE3's FXC.
>>>>>>>>> -->
>>>>>>>>> Ali> That’s fine.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 8) <!--[rfced] May we update the following acronyms and their
>>>>>>>>> expansions to better reflect the text in RFC 5885?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> The failure detection of an EVPN VPWS service can be performed via
>>>>>>>>> OAM mechanisms such as VCCV-BFD (Bidirectional Forwarding Detection
>>>>>>>>> for the Pseudowire Virtual Circuit Connectivity Verification,
>>>>>>>>> [RFC5885]) and upon such failure detection, the switch over procedure
>>>>>>>>> to the backup S-PE is the same as the one described above.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> The failure detection of an EVPN VPWS service can be performed via
>>>>>>>>> OAM mechanisms such as Bidirectional Forwarding Detection (BFD)
>>>>>>>>> for the pesudowire Virtual Circuit Connectivity Verification (VCCV)
>>>>>>>>> [RFC5885], and upon such failure detection, the switch over procedure
>>>>>>>>> to the backup S-PE is the same as the one described above.
>>>>>>>>> -->
>>>>>>>>> Ali> That’s fine.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 9) <!-- [rfced] Terminology
>>>>>>>>> 
>>>>>>>>> A) To match usage in RFC 8214, may we update the following terms to
>>>>>>>>> the format on the right?
>>>>>>>>> 
>>>>>>>>> single-active > Single-Active
>>>>>>>>> all-active > All-Active
>>>>>>>>> EVPN VPWS > EVPN-VPWS
>>>>>>>>> Ethernet A-D per EVI route > Ethernet A-D per-EVI route Ethernet A-D
>>>>>>>>> per ES route > Ethernet A-D per-ES route VLAN-bundle > VLAN bundle
>>>>>>>>> Ali> Please do so.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> B) Throughout the text, the following terminology appears to be used
>>>>>>>>> inconsistently. May we update them to the format on the right?
>>>>>>>>> 
>>>>>>>>> Normalized VID > normalized VID
>>>>>>>>> VLAN-signaled flexible cross-connect > VLAN-signaled FXC VLAN-signaled
>>>>>>>>> Flexible Cross-Connect > VLAN-signaled FXC
>>>>>>>>> Ali> Please do so.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> C) Since RFC 8214 uses "EVPN Layer 2 Attributes Extended Community",
>>>>>>>>> should the following terms be update to match? We ask because of the
>>>>>>>>> possible addition of "Attributes".
>>>>>>>>> 
>>>>>>>>> EVPN Layer 2 Extended Community (Sections 3.2 and 3.3) EVPN Layer 2
>>>>>>>>> attribute extended community (Section 4)
>>>>>>>>> -->
>>>>>>>>> Ali> Please update to match RFC 8214.
>>>>>>>>> 
>>>>>>>>> 10) <!--[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.
>>>>>>>>> 
>>>>>>>>> Autonomous System (AS)
>>>>>>>>> Switching Provider Edge (S-PE)
>>>>>>>>> Ali>  Please change S-PE to PE. I don’t think you need to expand PE 
>>>>>>>>> as it has been used many times previously.
>>>>>>>>> 
>>>>>>>>> B) Both the expansion and the acronym for Ethernet Segment (ES) are
>>>>>>>>> used throughout the document. Would you like to update to using the
>>>>>>>>> expansion upon first usage and the acronym for the rest of the 
>>>>>>>>> document for consistency?
>>>>>>>>> Ali> Please do so.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> C) We note that "FXC" appears to be expanded in different ways
>>>>>>>>> throughout the document. May we update all these instances to be 
>>>>>>>>> "Flexible Cross-Connect"
>>>>>>>>> for consistency?
>>>>>>>>> 
>>>>>>>>> Flexible Xconnect
>>>>>>>>> Flexible Cross Connect
>>>>>>>>> Flexible Cross-Connect
>>>>>>>>> Ali> Please do so.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> D) We note that "VCCV" is expaned in two different ways in this 
>>>>>>>>> document.
>>>>>>>>> Please review and let us know which version should be updated for
>>>>>>>>> consistency.
>>>>>>>>> 
>>>>>>>>> Virtual Circuit Connectivity Verification  Virtual Circuit Connection
>>>>>>>>> Verification
>>>>>>>>> -->
>>>>>>>>> Ali> The top one – ie., Virtual Circuit Connectivity Verification
>>>>>>>>> 
>>>>>>>>> 11) <!-- [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.
>>>>>>>>> 
>>>>>>>>> For example, please consider whether the following should be updated:
>>>>>>>>> 
>>>>>>>>> black hole
>>>>>>>>> block-holed
>>>>>>>>> -->
>>>>>>>>> Ali> I would prefer “black hole” and “black holed”
>>>>>>>>> Regards,
>>>>>>>>> Ali
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thank you.
>>>>>>>>> 
>>>>>>>>> RFC Editor/st/ap
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Feb 26, 2025, at 2:29 PM, rfc-edi...@rfc-editor.org wrote:
>>>>>>>>> 
>>>>>>>>> *****IMPORTANT*****
>>>>>>>>> 
>>>>>>>>> Updated 2025/02/26
>>>>>>>>> 
>>>>>>>>> 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-4Q9l2USxI
>>>>>>>>> Ae6P8O4Zc
>>>>>>>>> 
>>>>>>>>> *  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/rfc9744.xml
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9744.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9744.pdf
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9744.txt
>>>>>>>>> 
>>>>>>>>> Diff file of the text:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9744-diff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9744-rfcdiff.html (side by
>>>>>>>>> side)
>>>>>>>>> 
>>>>>>>>> Diff of the XML:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9744-xmldiff1.html
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Tracking progress
>>>>>>>>> -----------------
>>>>>>>>> 
>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9744
>>>>>>>>> 
>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>> 
>>>>>>>>> Thank you for your cooperation,
>>>>>>>>> 
>>>>>>>>> RFC Editor
>>>>>>>>> 
>>>>>>>>> --------------------------------------
>>>>>>>>> RFC9744 (draft-ietf-bess-evpn-vpws-fxc-12)
>>>>>>>>> 
>>>>>>>>> Title            : EVPN VPWS Flexible Cross-Connect Service
>>>>>>>>> Author(s)        : A. Sajassi, P. Brissette, J. Uttaro, J. Drake, S. 
>>>>>>>>> Boutros, J. Rabadan
>>>>>>>>> WG Chair(s)      : Matthew Bocci, Stephane Litkowski, Zhaohui 
>>>>>>>>> (Jeffrey) Zhang
>>>>>>>>> 
>>>>>>>>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde
>>>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
> 


-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
              • [... Sarah Tarrant via auth48archive
              • [... James Uttaro via auth48archive
              • [... James Uttaro via auth48archive
              • [... John Drake via auth48archive
              • [... Patrice Brissette (pbrisset) via auth48archive
              • [... Sarah Tarrant via auth48archive
              • [... je_drake--- via auth48archive
              • [... Sarah Tarrant via auth48archive
              • [... je_drake--- via auth48archive
              • [... je_drake--- via auth48archive
              • [... Sarah Tarrant via auth48archive
              • [... je_drake--- via auth48archive
              • [... Sarah Tarrant via auth48archive
      • [auth48] Re: AUTH4... Ali Sajassi (sajassi) via auth48archive
  • [auth48] Re: AUTH48: RFC-to... je_drake--- via auth48archive

Reply via email to