Il 02/05/2025 22:31, Sandy Ginoza ha scritto:
Hi Rakesh,Thank you for your reviews! We have noted your approval on the AUTH48 page <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9779__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv10Vvc4cF$ >. We will wait to hear from your coauthors as well before continuing with the publication process.
Hi Sandy, thank you for your work! Approved. Stefano
Thank you, RFC Editor/sgOn May 2, 2025, at 11:40 AM, Rakesh Gandhi (rgandhi) <rgan...@cisco.com> wrote: Thank you, Sandy, for the excellent work.Approved. Regards,RakeshFrom: Sandy Ginoza <sgin...@staff.rfc-editor.org>Date: Friday, May 2, 2025 at 1:46 PM To: Stefano Salsano <stefano.sals...@uniroma2.it> Cc: Rakesh Gandhi (rgandhi) <rgan...@cisco.com>, RFC Editor <rfc-edi...@rfc-editor.org>, Clarence Filsfils (cfilsfil) <cfils...@cisco.com>, mach.c...@huawei.com <mach.c...@huawei.com>, danvoyerw...@gmail.com <danvoyerw...@gmail.com>, Dan Voyer (davoyer) <davo...@cisco.com>, mpls-...@ietf.org <mpls-...@ietf.org>, mpls-cha...@ietf.org <mpls-cha...@ietf.org>, tony...@tony.li <tony...@tony.li>, james.n.guich...@futurewei.com <james.n.guich...@futurewei.com>, auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: [AD] Re: AUTH48: RFC-to-be 9779 <draft-ietf-mpls-rfc6374-sr-17> for your review Hi Rakesh and Stefano, Jim* (as AD), *Jim, please review the change in Section 4.2.1 and let us know if you approve. The changes are most easily viewed in one these diff files: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-lastdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1wkcvZy3$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-lastrfcdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1-R1oq07$ (side by side) Rakesh and Stefano, thank you for your help to clarify the text! We have updated the document as described below. The current files are available at the following URLs: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.xml__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17tgn4MR$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.txt__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv18l91UNz$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.pdf__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv13HM80Mg$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17rIb9v7$ Diffs of the last two rounds of updates: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-lastdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1wkcvZy3$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-lastrfcdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1-R1oq07$ (side by side) AUTH48 diffs: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-auth48diff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv16WYplRl$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-auth48rfcdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1xfkiCXU$ (side by side) Comprehensive diffs: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-diff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv164h1asG$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-rfcdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1186Fgii$ (side by side) Please review and let us know if any additional updates are needed or if you approve the RFC for publication. Thank you, RFC Editor/sgOn Apr 29, 2025, at 12:58 PM, Stefano Salsano <stefano.sals...@uniroma2.it> wrote: Il 28/04/2025 21:34, Rakesh Gandhi (rgandhi) ha scritto:Thanks, Sandy, for the updates. Regarding your question below, I think it may be easier to read if we split it into two sentences. Old text in the draft: In one-way measurement mode defined in Section 2.4 of [RFC6374], the querier can receive "out-of-band" response messages with an IP/UDP header by properly setting the UDP Return Object (URO) TLV in the query message. New text: In one-way measurement mode, as defined in Section 2.4 of [RFC6374], the querier can properly set the UDP Return Object (URO) TLV in the query message. This allows the response message, containing an IP/UDP header for that query message, to be received out-of-band by the querier.Dear Sandy and Rakesh, I agree with the text proposed by Rakesh, I only propose to improve and clarify the second sentence. We can change it from passive to active mode and we can further clarify that the IP/UDP header encapsulates the message rather than being contained into the message: In one-way measurement mode, as defined in Section 2.4 of [RFC 6374], the querier can set the UDP Return Object (URO) TLV in the query message. This enables the querier to receive the out-of-band response message encapsulated in an IP/UDP header sent to the IP address and UDP port specified in the URO TLV. ciao StefanoDoes that work? Thanks, Rakesh *From: *Sandy Ginoza <sgin...@staff.rfc-editor.org> *Date: *Monday, April 28, 2025 at 1:43 PM *To: *Rakesh Gandhi (rgandhi) <rgan...@cisco.com> *Cc: *RFC Editor <rfc-edi...@rfc-editor.org>, Clarence Filsfils (cfilsfil) <cfils...@cisco.com>, daniel.vo...@bell.ca <daniel.vo...@bell.ca>, stefano.sals...@uniroma2.it <stefano.sals...@uniroma2.it>, mach.c...@huawei.com <mach.c...@huawei.com>, danvoyerw...@gmail.com <danvoyerw...@gmail.com>, Dan Voyer (davoyer) <davo...@cisco.com>, mpls-...@ietf.org <mpls- a...@ietf.org>, mpls-cha...@ietf.org <mpls-cha...@ietf.org>, tony...@tony.li <tony...@tony.li>, james.n.guich...@futurewei.com <james.n.guich...@futurewei.com>, auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> *Subject: *Re: AUTH48: RFC-to-be 9779 <draft-ietf-mpls-rfc6374-sr-17> for your review Greetings, Rakesh, thank you for your reply. We have updated the document as noted below. Looking at the change in the diff, we would appreciate you or one of your coauthors confirming that this update is as intended. Specifically, please confirm whether: … response messages with an IP/UDP header “out-of-band” … is the same as or was intended to be … a response to an Out-of-band Response Requested message … The current files are available her: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.xml__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17tgn4MR$ <https://urldefense.com/ v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.xml__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv10Vbd1lg$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMuEFXQow$> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.txt__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv18l91UNz$ <https://urldefense.com/ v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.txt__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1xUPzdok$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMIQ6ck5s$> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.pdf__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv13HM80Mg$ <https://urldefense.com/ v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.pdf__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1zg21jNC$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERM3kGkC9Y$> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17rIb9v7$ <https://urldefense.com/ v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.html__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv10ajpfpx$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMgOwlxTo$> Diffs highlighting the most recent updates: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-lastdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1wkcvZy3$ <https:// urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-lastdiff.html__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1-vgKzpa$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMjY0rDUM$> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-lastrfcdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1-R1oq07$ <https:// urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17q3jAEd$ lastrfcdiff.html__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMxz9y4bU$> (side by side) AUTH48 diffs: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-auth48diff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv16WYplRl$ <https:// urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17q3jAEd$ auth48diff.html__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERM8To5wjU$> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-auth48rfcdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1xfkiCXU$ <https:// urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17q3jAEd$ auth48rfcdiff.html__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMA6pJ9Pw$> (side by side) Comprehensive diffs: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-diff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv164h1asG$ <https:// urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-diff.html__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1_Q0X8rP$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMX4LfIks$> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-rfcdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1186Fgii$ <https:// urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-rfcdiff.html__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1_O-GnuE$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMLrG-ZUg$> (side by side) Thank you, RFC Editor/sgOn Apr 21, 2025, at 3:43 PM, Rakesh Gandhi (rgandhi) <rgan...@cisco.com> wrote: Hello Sandy, Thanks for the great updates. They all look good to me. Please see inline with one comment <RG>.. From: Sandy Ginoza <sgin...@staff.rfc-editor.org> Date: Monday, April 21, 2025 at 5:19 PM To: Rakesh Gandhi (rgandhi) <rgan...@cisco.com> Cc: RFC Editor <rfc-edi...@rfc-editor.org>, Clarence Filsfils (cfilsfil) <cfils...@cisco.com>, daniel.vo...@bell.ca<daniel.vo...@bell.ca>, stefano.sals...@uniroma2.it <stefano.sals...@uniroma2.it>, mach.c...@huawei.com <mach.c...@huawei.com>, danvoyerw...@gmail.com<danvoyerw...@gmail.com>, Dan Voyer (davoyer) <davo...@cisco.com>, mpls-...@ietf.org <mpls-a...@ietf.org>, mpls-cha...@ietf.org <mpls-cha...@ietf.org>, tony...@tony.li <tony...@tony.li>, james.n.guich...@futurewei.com<james.n.guich...@futurewei.com>, auth48archive@rfc- editor.org<auth48archive@rfc-editor.org>Subject: Re: AUTH48: RFC-to-be 9779 <draft-ietf-mpls-rfc6374-sr-17> for your review Hi Rakesh, Thank you for your review and reply. We have updated the document based on your replies below. For item 9, we are having trouble parsing the text:<RG> How about following?In one-way measurement mode defined in Section 2.4 of [RFC6374], thequerier can receive response messages with an IP/UDP header “out-of-band” by properly setting the UDP Return Object (URO) TLV in the query message. We wonder if the following correctly conveys the intended meaning? In one-way measurement mode defined in Section 2.4 of [RFC6374], thequerier can receive a response to an Out-of-band Response Requested message by properly setting the UDP Return Object (URO) TLV in the IP/UDP header. <RG> Looks good. Thanks, Rakesh Please review the updated files here: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.xml__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17tgn4MR$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.xml__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv10Vbd1lg$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMuEFXQow$>https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.txt__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv18l91UNz$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.txt__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1xUPzdok$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMIQ6ck5s$>https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.pdf__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv13HM80Mg$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.pdf__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1zg21jNC$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERM3kGkC9Y$>https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17rIb9v7$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.html__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv10ajpfpx$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMgOwlxTo$>AUTH48 diffs (highlight only the changes noted below): https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-auth48diff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv16WYplRl$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17q3jAEd$ auth48diff.html__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERM8To5wjU$>https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-auth48rfcdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1xfkiCXU$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17q3jAEd$ auth48rfcdiff.html__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMA6pJ9Pw$> (side by side)Comprehensive diffs: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-diff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv164h1asG$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17q3jAEd$ diff.html__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMX4LfIks$>https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-rfcdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1186Fgii$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17q3jAEd$ rfcdiff.html__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMLrG-ZUg$> (side by side)Please review and let us know if additional updates are needed or if you approve the RFC for publication. Thank you, RFC Editor/sgOn Apr 16, 2025, at 8:01 PM, Rakesh Gandhi (rgandhi) <rgandhi=40cisco....@dmarc.ietf.org> wrote:Hello Editor,> Thank you for the great updates to the document. > Note: I am adding new email IDs for Dan Voyer. Dan, please reply with your preference on how you would like to update your information in the RFC-to-be. > Please see replies inline with <RG>… > > From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> Date: Wednesday, April 16, 2025 at 7:00 PM To: Rakesh Gandhi (rgandhi) <rgan...@cisco.com>, Clarence Filsfils (cfilsfil) <cfils...@cisco.com>, daniel.vo...@bell.ca<daniel.vo...@bell.ca>, stefano.sals...@uniroma2.it <stefano.sals...@uniroma2.it>, mach.c...@huawei.com <mach.c...@huawei.com> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, mpls-...@ietf.org <mpls-...@ietf.org>, mpls-cha...@ietf.org <mpls-cha...@ietf.org>, tony...@tony.li<tony...@tony.li>, james.n.guich...@futurewei.com <james.n.guich...@futurewei.com>, auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9779 <draft-ietf-mpls-rfc6374-sr-17> for your reviewAuthors, While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. 1) <!-- [rfced] May we update the document title as shown below for > clarity? > > Original:Performance Measurement for Segment Routing Networks with MPLS Data PlanePerhaps:Performance Measurement for Segment Routing Networks over the MPLS Data Plane--> <RG> We could use following example as a guidance? RFC 8660 uses term: Segment Routing with the MPLS Data Plane https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8660__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1y9LTyY0$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8660__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv18Al8PE2$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMKktbgAA$><RG> Performance Measurement for Segment Routing Networks with the MPLS Data Plane2) <!-- [rfced] Please insert any keywords (beyond those that appear inthe title) for use on https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv18JaW9ok$ <https://urldefense.com/v3/__https://https://urldefense.com/v3/__http://www.rfc-editor.org/search__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv16lh4RY1$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMN9Y_re0$>. --><RG> Delay Measurement, Loss Measurement, Link Measurement, SR-MPLS Policy Measurement 3) <!-- [rfced] We have updated the text below for readability and to > clarify the relationship between SR-MPLS and its expansion. Please review > and let us know any objections.Original:This document specifies the application of the MPLS loss and delay measurement techniques, originally defined in RFC 6374, RFC 7876, and RFC 9341 within Segment Routing (SR) networks that utilize the MPLS data plane (SR-MPLS). > > Current: This document specifies the application of the MPLS loss and delay measurement techniques (originally defined in RFCs 6374, 7876, and 9341) within Segment Routing (SR) networks that utilize the MPLS data plane, > also referred to as Segment Routing over MPLS (SR-MPLS).--> <RG> Ok.4) <!-- [rfced] We have updated the text below to demonstrate a 1:1relationship between abbreviation and expansion. Please review.Original: Segment Routing (SR), as specified in [RFC8402], leverages the sourcerouting paradigm and applies to both the Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. > > Current:Segment Routing (SR), as specified in [RFC8402], leverages the sourcerouting paradigm and applies to both the Multiprotocol Label Switching (MPLS) and Internet Protocol version 6 (IPv6) data planes. These are referred to as Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6), respectively.--><RG> Ok.5) <!-- [rfced] For clarity, please consider whether the following > suggested update conveys the intended meaning. > > Original:This document defines Return Path and Block Number TLV extensions for [RFC6374], in Section 6, for delay and loss measurement in SR-MPLS networks.Current:This document extends [RFC6374] by defining Return Path and Block > Number TLVs (see Section 6) for delay and loss measurement in > SR-MPLS networks. --> <RG> Ok.6) <!-- [rfced] Does "also apply" mean "can also be used"? > > Original:These TLV extensions also apply to MPLS Label Switched Paths (LSPs) [RFC3031].Perhaps:These TLVs can also be used in MPLS Label Switched Paths (LSPs) [RFC3031]. --> <RG> Ok7) <!-- [rfced] Seemingly, Success (0x1) is a Control Code. If this is > correct, may we udpate the text as follows? > > Original:The responder that supports this TLV MUST return Success in "Control Code" [RFC6374] if it is the intended destination for the query.Perhaps:The responder that supports this TLV MUST return Control Code 0x1 (Success) [RFC6374] if it is the intended destination for the query. --><RG> Ok8) <!-- [rfced] Could the text below be adjusted for clarity? Specifically, > what is being sent as "the destination address"?Original:When the querier sets an IP address and a UDP port in the URO TLV, the response message MUST be sent to that IP address as the destination address and UDP port as the destination port.Perhaps:When the querier sets an IP address and a UDP port in the URO TLV, the response message MUST be sent to that IP address, with that IP address as the destination address and the UDP port as the destination port. --> <RG> Ok9) <!-- [rfced] May we update "out-of-band response messages" to > "Out-of-Band Response Requested messages..."? It is unclear whether the > text refers to the Response Requested messages or res ponses to Out-of-Band > Response Requested messages. > > Original:In one-way measurement mode defined in Section 2.4 of [RFC6374], the querier can receive "out-of-band" response messages with an IP/UDP header by properly setting the UDP Return Object (URO) TLV in the query message. > --> <RG> How about following?In one-way measurement mode defined in Section 2.4 of [RFC6374], thequerier can receive response messages with an IP/UDP header “out-of-band” by properly setting the UDP Return Object (URO) TLV in the query message. > > > 10) <!-- [rfced] How may we update the text below for clarity and > readability?Original:In two-way measurement mode defined in Section 2.4 of [RFC6374], the response messages SHOULD be sent back in-band on the same link or the same end-to-end SR-MPLS path (same set of links and nodes) in the reverse direction to the querier, in order to perform accurate two- way delay measurement.Perhaps:In the two-way measurement mode defined in Section 2.4 of [RFC6374], > the response messages SHOULD be sent back one of two ways: either > they are sent back in-band on the same link, or they are sent back > on the same end-to-end SR-MPLS path (i.e., the same set of links and > nodes) in the reverse direction to the querier. This is done in order > to perform accurate two-way delay measurement.--><RG> Ok.11) <!-- [rfced] For readability, we suggest the update below. Please > review to ensure it does not impact the intended meaning. > > Original:The querier can request in the query message for the responder to send the response message back on a given return path using the MPLS Label Stack sub-TLV in the Return Path TLV defined in this document.Perhaps:In the query message, the querier can request that the responder send > the response message back on a given return path using the MPLS Label > Stack Sub-TLV in the Return Path TLV defined in this document. --> <RG> Ok.12) <!-- [rfced] Please review these similar sentences and let us know if > we may update them for readability. > > More specifically, what does "which" refer to in the examples below? Does > it refer to the ACH or the different values in parentheses?<RG> Value as in the suggested text. In addition, we were unable to find "Combined DM+LM" in RFC 6374 as seen inthe third example. Should this be updated to "combined LM/DM message" as > used in RFC 6374?<RG> Yes.Original:As defined in [RFC6374], MPLS Delay Measurement (DM) query and response messages use the Associated Channel Header (ACH) (value 0x000C for delay measurement) [RFC6374], which identifies the message type and the message payload as defined in Section 3.2 [RFC6374] following the ACH. > > As defined in [RFC6374], MPLS LM query and response messages use the Associated Channel Header (ACH) (value 0x000A for direct loss measurement or value 0x000B for inferred loss measurement), which identifies the message type and the message payload defined in Section 3.1 [RFC6374] following the ACH. > > As defined in [RFC6374], Combined DM+LM query and response messages use the Associated Channel Header (ACH) (value 0x000D for direct loss and delay measurement or value 0x000E for inferred loss and delay measurement), which identifies the message type and the message payload defined in Section 3.3 [RFC6374] following the ACH. > > Perhaps: As defined in [RFC6374], MPLS Delay Measurement (DM) query and response messages use the Associated Channel Header (ACH) (with the value 0x000C > for delay measurement). This value identifies the message type and the message payload that follow the ACH, as defined in Section 3.2 of > [RFC6374].As defined in [RFC6374], MPLS LM query and response messages use the ACH(with the value 0x000A for direct loss measurement or the value 0x000B > for inferred loss measurement). This value identifies the message type > and the message payload that follow the ACH, as defined in Section 3.1 > of [RFC6374].As defined in [RFC6374], combined DM+LM query and response messages use > the ACH (with the value 0x000D for direct loss and delay measurement or > the value 0x000E for inferred loss and delay measurement). This valueidentifies the message type and the message payload that follows the > ACH, as defined in Section 3.3 of [RFC6374].--><RG> Ok. Except DM+LM to be changed to LM/DM as suggested.13) <!-- [rfced] In the instances below, we have adjusted "for accounting > received traffic". Please review to ensure these changes do not alter your > meaning.Original:The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the received data packet for the traffic flow under measurement for > accounting received traffic on the egress node of the SR-MPLS Policy.Different values of PSID can be used per Candidate-Path for accountingreceived traffic to measure packet loss at the Candidate- Path level.Current:The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the received data packet for the traffic flow under measurement, in order to account for received traffic on the egress node of the SR-MPLS Policy.Different values of the PSID can be used per Candidate-Path to account > for received traffic and to measure packet loss at the Candidate-Path > level.--> <RG> Ok14) <!-- [rfced] In the text below, does "while" mean "at the same time", > or does it represent a contrast (like "whereas" or "on the other hand")?Original:The LM query and response messages defined in [RFC6374] are used to measure packet loss for the block of data packets transmitted with the previous marking while data packets carry alternate marking.Perhaps:The LM query and response messages defined in [RFC6374] are used to > measure packet loss for the block of data packets transmitted with the > previous marking, whereas data packets carry alternate marking. --> <RG> Ok15) <!-- [rfced] FYI - The quoted text below appears differently in RFC > 9341. We have updated to match RFC 9341.Original:"The assumption of the block number mechanism is that the measurement nodes are time synchronized" as specified in Section 4.3 of [RFC9341] is not necessary, as the block number on the responder can be synchronized based on the received LM query messages.Current:Section 4.3 of [RFC9341] specifies: "The assumption of this BN mechanism is that the measurement nodes are time synchronized." However, > this is not necessary, as the block number on the responder can be > synchronized based on the received LM query messages.--> <RG> Ok16) <!-- [rfced] Is "LSE" singular or plural in the text below?Original:The MPLS Label Stack contains a list of 32-bit LSE that includes a 20-bit label value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS (S) field. > > Perhaps (LSE is plural): The MPLS Label Stack contains a list of 32-bit LSEs that each include a 20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit > EOS (S) field.--><RG> Ok17) <!-- [rfced] We have removed "TLV" from the Descriptions to align with > the IANA registries <https://urldefense.com/v3/__https://www.iana.org/assignments/g-ach-parameters__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1zsXAUn-$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.iana.org/assignments/g-ach-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1_PM8ZCJ$ parameters__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMke3dELU$>>.Please let us know any corrections. > > Original: | TBA1 | Return Path TLV | This document | | TBA2 | Block Number TLV | This document |Current:| 5 | Return Path | RFC 9779 | | 6 | Block Number | RFC 9779 | --> <RG> Ok18) <!-- [rfced] Should the registry name be plural? Note that we will ask > IANA to update their registry if this change is accepted. > > Current: Return Path Sub-TLV TypePerhaps: Return Path Sub-TLV Types > --> <RG> Yes19) <!-- [rfced] Much of this text duplicates what appears in the table. > Perhaps the text should just indicate that the code points are assigned as > defined in Table 2? > > Section 12: > All code points in the range 0 through 175 in this registryshall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 176 through 239 in this registry shall be allocated according to the "First Come, First Served" procedure as specified in [RFC8126]. Remaining code points are allocated according to Table 2:Table 2: > | Value | Description | Reference |+===========+=========================+===============+ | 1 - 175 | IETF Review | This document | | 176 - 239 | First Come First Served | This document | | 240 - 251 | Experimental Use | This document | | 252 - 254 | Private Use | This document | --> <RG> Agree to change to:The code points are allocated according to Table 2:20) <!-- [rfced] Would it make sense to refer to the MPLS Review Team > (assuming that is correct), as we are unsure what MPLS-RT refers to and we > are unable to find information about it. > > Original:Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for MPLS-RT expert review, ... --> <RG> PerhapsThanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for MPLS expertreview, ...21) <!-- [rfced] [IEEE802.1AX] references the 2008 version of this IEEE > Standard. May we update this reference to use the current standard from > 2020 as seen in the following URL: <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/9105034__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1475KWZ_$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/9105034__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1xu2lkth$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMBPhYNs0$>>?--><RG> Yes22) <!-- [rfced] We removed the quotes around Control Code throughout to > align with use in RFC 6374. We have also removed the quotes and > capitalized "in-band response requested" and "out-of-band response > requested" to match what appears in RFC 6374 and the IANA registry. Please > review and let us know if corrections are needed. > --><RG> Ok23) <!-- [rfced] Please review the following changes and questions > regarding the terms used in this document: a) RFC 8402 uses "node-SID" and "Anycast-SID" rather than "node SID" and"Anycast SID". May we update these to match the usage from RFC 8402?<RG> Yes. b) We note different capitalization of label stack vs. Label Stack. We believe the lowercase "label stack" is used in general text, but "Label Stack" is capitalized when it refers to the the TLV. Please confirm that MPLS Label Stack is capitalized correctly in the following: Original: > The MPLS Label Stack contains a list of 32-bit LSE that includes a20-bit label value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS (S) field. An MPLS Label Stack Sub-TLV may carry a stack of labels or a Binding SID label [RFC8402] of the Return SR-MPLS Policy. --> <RG> PerhapsThe MPLS label stack contains a list of 32-bit LSE that includes a20-bit label value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS (S) field. An MPLS Label Stack Sub-TLV may carry a stack of labels or a Binding SID label [RFC8402] of the Return SR-MPLS Policy.24) <!-- [rfced] Please review the following questions and changes > regarding the abbreviations used in this document.a) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should beexpanded upon first use. Is "EOS" in the text below an abbreviation? If so, how may it be expanded?1-bit EOS (S) field <RG> Perhaps: 1-bit End of Stack (S) field b) FYI - We have expanded the abbreviation below. Please review toensure correctness.Border Gateway Protocol - Link State (BGP-LS) --><RG> Ok25) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1_jqp8hY$<https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/ part2/*inclusive_language__;Iw!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMlemNz60$>>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. > > --> <RG> Believe the document is ok. Thanks, RakeshThank you.RFC EditorOn Apr 16, 2025, at 3:52 PM, rfc-edi...@rfc-editor.org wrote:*****IMPORTANT***** Updated 2025/04/16 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1_TmOE29$ <https://urldefense.com/v3/__https://https://urldefense.com/v3/__http://www.rfc-editor.org/faq/__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv12aM0s5e$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMV3Xtv9o$>).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 inRFC 5378 and the Trust Legal Provisions > (TLP – https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1_TuBTdu$ ) <https://urldefense.com/v3/__https://urldefense.com/v3/__https://trustee.ietf.org/license-info)__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1-Kh9XzB$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMbfuxA7Y$>.* 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1-TFBW65$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv12TYuR_T$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMsWB6zMw$>>.* 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv160DcooX$yb6lpIGh-4Q9l2USxIAe6P8O4Zc <https://urldefense.com/v3/__https:// mailarchive.ietf.org/arch/msg/ietf-announce/ yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERM_aSn8mc$>> * The archive itself: https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv16zFx0pM$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1-0Bzt1d$ auth48archive/__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERM7UtK5pM$>* 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 formatSection # (or indicate Global) OLD:old textNEW:new textYou 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 seembeyond 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 statingthat 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.xml__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17tgn4MR$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.xml__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv10Vbd1lg$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMuEFXQow$>https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17rIb9v7$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.html__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv10ajpfpx$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMgOwlxTo$>https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.pdf__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv13HM80Mg$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.pdf__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1zg21jNC$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERM3kGkC9Y$>https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.txt__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv18l91UNz$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779.txt__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1xUPzdok$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMIQ6ck5s$>Diff file of the text:https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-diff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv164h1asG$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17q3jAEd$ diff.html__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMX4LfIks$>https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-rfcdiff.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv1186Fgii$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17q3jAEd$ rfcdiff.html__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMLrG-ZUg$> (side by side)Diff of the XML: > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-xmldiff1.html__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv11LtBxgY$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9779-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv17q3jAEd$ xmldiff1.html__;!!O5Bi4QcV!EG- oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMYnmj910$>Tracking progress-----------------The details of the AUTH48 status of your document are here:https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9779__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv10Vvc4cF$ <https://urldefense.com/v3/__https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9779__;!!O5Bi4QcV!EG-__;!!O5Bi4QcV!EzDrCITmjHFNd_BnJMv-kO8h7MZM-W2PT5WygvBbNMKjTel_9h8mncIqjmYm_M-7mH4bzB3yq13VNdQ8nFaanTDv13ax6qCQ$ oLa0qgnQ0emFCiJzjgHJSzzwSJ10Ou71y77R_sHz1DkJwaUUyaxegy0n-YFDnSJQ7cQ3VR- aXfERMOhIB-ns$>Please let us know if you have any questions. > > Thank you for your cooperation, RFC Editor --------------------------------------RFC9779 (draft-ietf-mpls-rfc6374-sr-17)Title : Performance Measurement for Segment Routing Networks with MPLS Data PlaneAuthor(s) : R. Gandhi, C. Filsfils, D. Voyer, S. Salsano, M. Chen WG Chair(s) : Nicolai Leymann, Tarek Saad, Tony LiArea Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde-- ******************************************************************* Prof. Stefano Salsano Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.sals...@uniroma2.it Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 *******************************************************************
-- ******************************************************************* Prof. Stefano Salsano Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.sals...@uniroma2.it Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 ******************************************************************* -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
