Hi Alice, It looks good to me.
Regards, Patrice Brissette Distinguished Engineer Cisco Systems From: Alice Russo <aru...@staff.rfc-editor.org> Date: Tuesday, May 20, 2025 at 12:54 To: Patrice Brissette (pbrisset) <pbris...@cisco.com>, Ali Sajassi (sajassi) <saja...@cisco.com>, Luc Andre Burdet (lburdet) <lbur...@cisco.com>, je_dr...@yahoo.com <je_dr...@yahoo.com>, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Cc: Gunter Van De Velde (Nokia - BE/Antwerp) <gunter.van_de_ve...@nokia.com>, bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, Matthew Bocci (Nokia) <matthew.bo...@nokia.com>, auth48archive@rfc-ed <auth48archive@rfc-editor.org>, RFC Editor <rfc-edi...@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9722 <draft-ietf-bess-evpn-fast-df-recovery-12> for your review Authors, This is a reminder that we await word from you regarding this document's readiness for publication as an RFC. The files are here: https://www.rfc-editor.org/authors/rfc9722.html https://www.rfc-editor.org/authors/rfc9722.pdf https://www.rfc-editor.org/authors/rfc9722.txt https://www.rfc-editor.org/authors/rfc9722.xml (source) Diff files of all changes from the approved Internet-Draft: https://www.rfc-editor.org/authors/rfc9722-diff.html https://www.rfc-editor.org/authors/rfc9722-rfcdiff.html (side by side) Diff files of AUTH48 changes only: https://www.rfc-editor.org/authors/rfc9722-auth48diff.html https://www.rfc-editor.org/authors/rfc9722-auth48rfcdiff.html (side by side) This page shows the AUTH48 status of your document: https://www.rfc-editor.org/auth48/rfc9722 Thank you. RFC Editor/ar > On May 9, 2025, at 12:02 PM, Alice Russo <aru...@staff.rfc-editor.org> wrote: > > Luc André and Gunter (as AD)*, > > * Gunter, please review Section 2.3 and let us know if you approve the > changes pasted below (also shown in the diff files). See Luc André's reply > for context. > > Original: > Item 9. in Section 2.1 of [RFC8584], the list "Corresponding actions > when transitions are performed or states are entered/exited" is > changed as follows: > > 9. DF_CALC on CALCULATED: Mark the election result for the VLAN or > VLAN Bundle. > > 9.1 If an SCT timestamp is present during the RCVD_ES event of > Action 11, wait until the time indicated by the SCT minus > skew before proceeding to step 9.3. > > 9.2 If an SCT timestamp is present during the RCVD_ES event of > Action 11, wait until the time indicated by the SCT before > proceeding to step 9.4. > > 9.3 Assume the role of NDF for the local PE concerning the VLAN > or VLAN Bundle, and transition to the DF_DONE state. > > 9.4 Assume the role of DF for the local PE concerning the VLAN > or VLAN Bundle, and transition to the DF_DONE state. > > Current: > Item 9 in Section 2.1 of [RFC8584], in the list "Corresponding > actions when transitions are performed or states are entered/exited", > is changed as follows: > > | 9. DF_CALC on CALCULATED: Mark the election result for the VLAN > | or VLAN bundle. > | > | 9.1 If no Service Carving Time is present during the RCVD_ES > | event of Action 11, proceed to step 9.4 > | > | 9.2 If a Service Carving Time is present during the RCVD_ES > | event of Action 11, wait until the time indicated by the > | SCT minus skew before proceeding to step 9.3. > | > | 9.3 Assume the role of NDF for the local PE concerning the > | VLAN or VLAN bundle. Wait the remaining skew time before > | proceeding to step 9.4. > | > | 9.4 Assume the election result's role (DF or NDF) for the > | local PE concerning the VLAN or VLAN bundle and > | transition to the DF_DONE state. > > > Luc André, > Thank you for providing the updated XML. > > Re: "Service Carving Time" >> IANA should be updated > > > IANA has completed the update on > https://www.iana.org/assignments/bgp-extended-communities. > > > Additional changes were: > - capitalized 'field' in the title of Figure 4. > - added 'the' to 'the Time Synchronization capability' (2 instances) to match > usage of the definite article later in this document. > > > The revised files are here (please refresh): > https://www.rfc-editor.org/authors/rfc9722.html > https://www.rfc-editor.org/authors/rfc9722.txt > https://www.rfc-editor.org/authors/rfc9722.pdf > https://www.rfc-editor.org/authors/rfc9722.xml > > This diff file shows all changes from the approved I-D: > https://www.rfc-editor.org/authors/rfc9722-diff.html > https://www.rfc-editor.org/authors/rfc9722-rfcdiff.html (side by side) > > This diff file shows only the changes made during AUTH48 thus far: > https://www.rfc-editor.org/authors/rfc9722-auth48diff.html > https://www.rfc-editor.org/authors/rfc9722-auth48rfcdiff.html (side by side) > > We will wait to hear from you again and from your coauthors > before continuing the publication process. This page shows > the AUTH48 status of your document: > https://www.rfc-editor.org/auth48/rfc9722 > > Thank you. > RFC Editor/ar > >> On May 8, 2025, at 2:35 PM, Luc Andre Burdet (lburdet) <lbur...@cisco.com> >> wrote: >> >> Hi, >> >> • I did a review of the changes from -12 to 9722 (using the diff you >> linked to) and see appreciate all the editing effort that went into it. >> Looks good to me! >> >> • Additional corrections between Draft9722 and Draft9722-1 are >> included in the XML file attached and I have included also the side-by-side >> diff. >> >> • For the figures I have adopted format/language similar to the >> following document also in your edit queue – they are both updating the same >> Extended community‘s bitmap field: >> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-13#name-evpn-bgp-attributes-extensi >> Figure 2: Bitmap field in the DF Election Extended Community >> >> • Question 4 is correct, it is not missing ‘not’ but is indeed not the >> clearest. >> The point here VLANs transitioning to DF wait an extra skew additional to >> those transitioning to NDF which wait only SCT minus skew. >> Reworded the section: does this help? @Gunter Van De Velde (Nokia - >> BE/Antwerp) does this still reflect the change you asked for originally? >> >> • The document normalised terminology onto “Service Carving Time“ a >> few versions back – IANA should be updated and I did a sweep in the XML for >> “Service Carving Timestamp” to remove all instances I previously missed. >> >> • This document is OK with the 8584 errata, the update is to the state >> machine part not the HRW algo. >> >> • I could not find any “DF Election” so I believe you have fixed this >> one, and I normalized ‘fraction’ to just actually use RFC5905 capitalisation >> and terminology. >> >> • Extended Community vs. extended community: I found RFC7432 just as >> confusing and it *appears** the theme is to capitalize when referred to as a >> noun, i.e. “this Extended Community” but when it is a noun’s complement it >> is not capitalized? “the MAC Mobility extended community”. >> >> I have no strong position on this one (nor has reading RFC7432 lifted much >> confusion...) >> >> Thanks Alice ! >> >> Regards, >> Luc André >> >> Luc André Burdet | lbur...@cisco.com | Tel: +1 613 254 4814 >>
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
