Hi Rebecca,
As the responsible AD, I agree with the authors that a change in the inclusive
language is not necessary in this case.
Jim
From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org>
Date: Thursday, May 15, 2025 at 4:05 PM
To: Donald Eastlake <d3e...@gmail.com>, gregimir...@gmail.com
<gregimir...@gmail.com>, gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>,
James Guichard <james.n.guich...@futurewei.com>
Cc: RFC Editor <rfc-edi...@rfc-editor.org>, mpls-...@ietf.org
<mpls-...@ietf.org>, mpls-cha...@ietf.org <mpls-cha...@ietf.org>,
n.leym...@telekom.de <n.leym...@telekom.de>, auth48archive@rfc-editor.org
<auth48archive@rfc-editor.org>
Subject: Re: AUTH48: RFC-to-be 9780 <draft-ietf-mpls-p2mp-bfd-11> for your
review
Hi Donald,
Thank you for addressing our questions. We have updated the document
accordingly (see list of files below). We also have a few followup
questions/comments.
1)
>>> d) Would either of the following read more clearly? Or is the current okay?
>>>
>>> Current:
>>> the Dummy IPv6 Prefix range 100:0:0:1::/64
>>>
>>> Perhaps ("address block" instead of "range"):
>>> the Dummy IPv6 Prefix address block 100:0:0:1::/64
>>>
>>> Or ("address block" and parentheses):
>>> the Dummy IPv6 Prefix address block (100:0:0:1::/64)
>
> I don't think parenthesis are needed but "address block" is good.
“range” is used a few other times in the document aside from the context of
"Dummy IPv6 Prefix range 100:0:0:1::/64”. Should those instances of “range”
also be updated to “address block”? Or are these okay?
2)
>>> 9) <!-- [rfced] We do not see "demultiplex" in Section 3.1. Please review
>>> and let
>>> us know if any updates are needed.
>>>
>>> Original:
>>> If the BFD Control packet is encapsulated in IP/UDP, then
>>> the source IP address MUST be used to demultiplex the received BFD
>>> Control packet as described in Section 3.1.
>>> -->
>
> I do not think Section 3.1 needs any further change. It is about
> encapsulation while demultiplexing is about handling on receipt.
Because Section 3.1 is about encapsulation, would moving the section pointer to
earlier in the sentence (i.e., after "encapsulated in IP/UDP”) be better? Or is
the current okay?
Perhaps:
If the BFD Control packet is encapsulated in IP/UDP as described in Section
3.1, then
the source IP address MUST be used to demultiplex the received BFD
Control packet.
3)
>>> 23) <!-- [rfced] Please review the "Inclusive Language" portion of the
>>> online
>>> Style Guide
>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363503887708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=m9VrlRN4ksu3tWcNh31cuLq3P2Po6iPRRWnOeYvtGZU%3D&reserved=0<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:
>>>
>>> Dummy
>
> I understand the problems with Dummy but it is hard to find another
> word with the right connotations. The best I can do is suggest
> replacing Dummy with Marker.
Understood. We will wait for other authors and AD to offer input on this before
making any changes.
— FILES (please refresh) —
Updated XML file:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780.xml&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363503920949%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=cgwmvgfW3yeYBhcqbEEVXOZCdrrPjjqcA4JlxNmmbts%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780.xml>
Updated output files:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780.txt&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363503935546%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Hu8C6uwYmHmEthgr98kKFmQ7alovTMJm6anwzfy1KZU%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780.txt>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780.pdf&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363503950083%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=%2BR2oEPxQSqctbBuLaqYfaLIQHsY8NyFVRAzLdxZocBo%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780.pdf>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363503964570%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=KLTiIK5e2%2FcR4UFkeOs0kMkqxELVzZzt5BYucS1FVA0%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780.html>
Diff file showing all changes made during AUTH48:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780-auth48diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363503978004%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=ISFc5jECpyAjsfi3hdhwIpBf8yhx9A7o0sOKzyR3k98%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780-auth48diff.html>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780-auth48rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363503989498%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=QnReJFM0DyR2AcQ0Ixagn8leOjja3wZiAm5Vy42Ls2M%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780-auth48rfcdiff.html>
(side by side)
Diff files showing all changes:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504002564%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=ii8rc3jCYi4br%2B%2BMtmkNfbQdv%2BmVFJIvq2n1FMPoGac%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780-diff.html>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780-rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504015232%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=xvMk5mp69UHbc5RgSOQTta0wg2PHYyVbq7i17SISEaE%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780-rfcdiff.html>
(side by side)
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780-alt-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504029082%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=%2F13LUt4XqRC8eVKtHVYKYxe6%2BysRQuOsct4ErQAmdjs%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780-alt-diff.html>
(diff showing changes where text is moved or deleted)
For the AUTH48 status of this document, please see:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9780&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504041705%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=37zj%2F%2FW1HO1X05Fv4kG0dfy%2Fm3Qqy1w3VGdm3ogiQVg%3D&reserved=0<https://www.rfc-editor.org/auth48/rfc9780>
Thank you,
RFC Editor/rv
> On May 14, 2025, at 7:48 PM, Donald Eastlake <d3e...@gmail.com> wrote:
>
> Hi Rebecca,
>
> Sorry for the delayed response.
>
> On Wed, May 14, 2025 at 12:48 AM Rebecca VanRheenen
> <rvanrhee...@staff.rfc-editor.org> wrote:
>>
>> Hello authors,
>>
>> This is a friendly reminder ...
>>
>> Thank you,
>> RFC Editor/rv
>>
>>> On May 5, 2025, at 3:06 PM, rfc-edi...@rfc-editor.org wrote:
>>>
>>> Authors,
>>>
>>> While reviewing this document during AUTH48, please resolve (as necessary)
>>> the following questions, which are also in the XML file.
>>>
>>> 1) <!-- [rfced] We made the following changes to the document title: 1)
>>> updated
>>> "Multi-Point" to "Multipoint" and 2) updated "Label Switched Path (LSP)"
>>> to "Label Switched Paths (LSPs)" (plural). Let us know any concerns.
>>>
>>> Original:
>>> Bidirectional Forwarding Detection (BFD) for Multipoint Networks over
>>> Point-to-Multi-Point MPLS Label Switched Path (LSP)
>>>
>>> Current:
>>> Bidirectional Forwarding Detection (BFD) for Multipoint Networks over
>>> Point-to-Multipoint MPLS Label Switched Paths (LSPs)
>>> -->
>
> OK.
>
>>> 2) <!-- [rfced] Please review the following sentences in the abstract and
>>> introduction to ensure that they align with the document title and the
>>> rest of the document. These similar sentences mention SR P2MP policies
>>> with an SR-MPLS data plane, which are not mentioned in the document
>>> title. In addition, we only see SR and SR-MPLS mentioned in one sentence
>>> in Section 4.1 (and in the Terminology section). Are any updates needed?
>>>
>>> Document Title:
>>> Bidirectional Forwarding Detection (BFD) for Multipoint Networks over
>>> Point-to-Multipoint MPLS Label Switched Paths (LSPs)
>
> I think that title is OK.
>
>>> Abstract:
>>> This document describes procedures for using Bidirectional Forwarding
>>> Detection (BFD) for multipoint networks to detect data plane failures
>>> in MPLS point-to-multipoint Label Switched Paths (LSPs) and Segment
>>> Routing (SR) point-to-multipoint policies with an SR over MPLS (SR-
>>> MPLS) data plane.
>>>
>>> Introduction:
>>> This document describes procedures for using such modes of the BFD
>>> protocol to detect data plane failures in Multiprotocol Label
>>> Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths
>>> (LSPs) and Segment Routing (SR) point-to-multipoint policies with an
>>> SR over MPLS (SR-MPLS) data plane.
>>> -->
>>>
>>>
>>> 3) <!-- [rfced] FYI - We updated "and recommends...and discourages" to "by
>>> recommending...and discouraging" (we also made a similar change in the
>>> introduction). Please review and let us know any concerns.
>>>
>>> Original:
>>> Furthermore, this document also updates RFC 8562 and recommends the
>>> use of an IPv6 address from the Dummy IPv6 range TBA2/64
>>> (Section 7.1) and discourages the use of an IPv4 loopback address
>>> mapped to IPv6.
>>>
>>> Updated:
>>> Furthermore, this document updates RFC 8562 by recommending the
>>> use of an IPv6 address from the Dummy IPv6 Prefix range 100:0:0:1::/64
>>> and discouraging the use of an IPv4 loopback address
>>> mapped to IPv6.
>>> -->
>
> OK.
>
>>> 4) <!-- [rfced] How may we update this sentence to improve readability?
>>>
>>> Original:
>>> It also describes the applicability of LSP Ping, as in-band, and the
>>> control plane, as out-band, solutions to bootstrap a BFD session.
>>>
>>> Perhaps:
>>> This document also describes the applicability of LSP Ping (as an in-band
>>> solution) and the control plane (as an out-of-band solution) to bootstrap
>>> a BFD session.
>>> -->
>
> I think your rewording is good.
>
>>> 5) <!-- [rfced] Please review the following sentences. The first sentence
>>> (from
>>> the abstract) mentions both in-band and out-of-band solutions, but the
>>> sentence (from the introduction) only mentions out-of-band
>>> solutions. Should these be aligned?
>>>
>>> Original:
>>> It also describes the applicability of LSP Ping, as in-band, and the
>>> control plane, as out-band, solutions to bootstrap a BFD session.
>>> ...
>>> The document also describes the applicability of out-band solutions
>>> to bootstrap a BFD session in this environment.
>>> -->
>
> Seems like a good idea to add a few words to the introduction sentence
> so
>
> The document also describes the applicability of LSP Ping and
> out-band solutions to bootstrap a BFD session in this environment
>
>>> 6) <!-- [rfced] Please review "to select destination IPv6 addresses for"
>>> here. Would updating as follows make this text more clear?
>>>
>>> Original:
>>> Hence, IANA is requested
>>> to allocate TBA2/64 as a new Dummy IPv6 Prefix (Section 7.1) to
>>> select destination IPv6 addresses for IP/UDP encapsulation of
>>> management, control, and OAM packets.
>>>
>>> Perhaps:
>>> Hence, IANA has
>>> allocated 100:0:0:1::/64 as a new Dummy IPv6 Prefix (Section 7.1) for
>>> destination IPv6 addresses used for IP/UDP encapsulation of
>>> management, control, and Operations, Administration, and Maintenance
>>> (OAM) packets.
>>> -->
>
> I really don't like that "a, b, and c, d, and e" construct. It's
> confusing. Regardless of whatever the general rule is about spelling
> out acronyms on first occurrence and then giving the acronym in
> parenthesis, this would read better as below. Otherwise fine.
>
> management, control, and OAM (Operations, Administration, and
> Maintenance) packets.
>
>>> 7) <!-- [rfced] We see both of the following in Section 1:
>>>
>>> address::ffff:127.0.0.1/128
>>> ::ffff:127.0.0.1/128
>>>
>>> Should "address::ffff:127.0.0.1/128" be updated as follows?
>>>
>>> Current:
>>> Historically, an IPv6-mapped IPv4 loopback range
>>> address::ffff:127.0.0.1/128 was mandated, although functionally, an
>>> IPv6 address from that range is not analogous to its IPv4
>>> counterpart.
>>>
>>> Perhaps:
>>> Historically, an address in the IPv6-mapped IPv4 loopback range
>>> ::ffff:127.0.0.1/128 was mandated, although functionally, an
>>> IPv6 address from that range is not analogous to its IPv4
>>> counterpart.
>>> -->
>
> I think that is a good change.
>
>>> 8) <!-- [rfced] To improve readability, we split this long sentence into two
>>> sentences. Would it be helpful to further update to use
>>> "::ffff:127.0.0.1/128 range" instead of "IPv6-mapped IPv4 loopback range
>>> address" in the second sentence?
>>>
>>> Original:
>>> Thus, this
>>> document also updates [RFC8562] and recommends the use of an IPv6
>>> address from the Dummy IPv6 Prefix range TBA2/64 (Section 7.1) while
>>> acknowledging that an address from ::ffff:127.0.0.1/128 range might
>>> be used by existing implementations, discourages the use of the
>>> IPv6-mapped IPv4 loopback range address.
>>>
>>> Current:
>>> Thus, this
>>> document updates [RFC8562] by recommending the use of an IPv6 address
>>> from the Dummy IPv6 Prefix range 100:0:0:1::/64 (Section 7.1) while
>>> acknowledging that an address from the ::ffff:127.0.0.1/128 range
>>> might be used by existing implementations. This document discourages
>>> the use of an address in the IPv6-mapped IPv4 loopback range.
>>>
>>> Perhaps:
>>> Thus, this
>>> document updates [RFC8562] by recommending the use of an IPv6 address
>>> from the Dummy IPv6 Prefix range 100:0:0:1::/64 (Section 7.1) while
>>> acknowledging that an address from the ::ffff:127.0.0.1/128 range
>>> might be used by existing implementations. This document discourages
>>> the use of an address from the ::ffff:127.0.0.1/128 range.
>>> -->
>
> I think your current text is best.
>
>>> 9) <!-- [rfced] We do not see "demultiplex" in Section 3.1. Please review
>>> and let
>>> us know if any updates are needed.
>>>
>>> Original:
>>> If the BFD Control packet is encapsulated in IP/UDP, then
>>> the source IP address MUST be used to demultiplex the received BFD
>>> Control packet as described in Section 3.1.
>>> -->
>
> I do not think Section 3.1 needs any further change. It is about
> encapsulation while demultiplexing is about handling on receipt.
>
>>> 10) <!-- [rfced] Should the introductory text include the first part of the
>>> indented text here?
>>>
>>> Original:
>>> Thus, this
>>> specification further clarifies that:
>>>
>>> if multiple alternative paths for the given p2mp LSP Forwarding
>>> Equivalence Class (FEC) exist, the MultipointHead SHOULD use the
>>> Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise
>>> those particular alternative paths;
>>>
>>> or the MultipointHead MAY use the UDP port number to possibly
>>> exercise those particular alternate paths.
>>>
>>> Perhaps:
>>> This
>>> specification further clarifies the following if multiple alternative paths
>>> for the given P2MP LSP Forwarding Equivalence Class (FEC) exist:
>>>
>>> * The MultipointHead SHOULD use the Entropy Label [RFC6790] used for LSP
>>> Ping [RFC8029] to exercise those particular alternative paths; or
>>>
>>> * The MultipointHead MAY use the UDP port number to possibly exercise
>>> those
>>> particular alternate paths.
>>> -->
>
> I don't think any material needs to be added to the Introduction.
>
>>> 11) <!-- [rfced] The following sentences appear twice in Section 3.2 (as the
>>> second paragraph and in the third paragraph). Which should be removed?
>>>
>>> Original:
>>> If a BFD Control packet in PW-ACH encapsulation (without IP/UDP
>>> Headers) is to be used in ACH, an implementation would not be able to
>>> verify the identity of the MultipointHead and, as a result, will not
>>> properly demultiplex BFD packets. Hence, a new channel type value is
>>> needed.
>>> -->
>
> I think the 2nd paragraph should be deleted.
>
>>> 12) <!-- [rfced] Would it be helpful to clarify "the top three four-octet
>>> words"
>>> here? Will readers understand what is defined in RFC 5586?
>>>
>>> Original:
>>> * the top three four-octet words as defined in [RFC5586];
>>> -->
>
> I think it is OK as is.
>
>>> 13) <!-- [rfced] We do not see mention of "BFD Control Message" in
>>> [RFC5880].
>>> Please review.
>>>
>>> Original:
>>> * the BFD Control Message field is as defined in [RFC5880];
>>> -->
>
> I believe the problem is that RFC 5880 refers to it as a BFD Control
> Packet rather than a BFD Control Message. Since it isn't really
> referring to the entire packet on the wire, it seems to me that
> Message is more correct.
>
> Perhaps the explanation below the figure should be:
>
> * The BFD Control Message field is as defined in [RFC5880] where it
> is referred to as the BFD Control Packet.
>
>>> 14) <!-- [rfced] Should the two instances of "Target FEC TLV" here be
>>> "Target FEC
>>> Stack TLV"? We see "Target FEC Stack TLV" in RFC 6425.
>>>
>>> Original:
>>> LSP Ping, as defined in [RFC6425], MAY be used to bootstrap
>>> MultipointTail. If LSP Ping is used, it MUST include the Target FEC
>>> TLV and the BFD Discriminator TLV defined in [RFC5884]. For the case
>>> of p2mp MPLS LSP, the Target FEC TLV MUST use sub-TLVs defined in
>>> Section 3.1 [RFC6425].
>>> -->
>
> I believe "Target FEC TLV" is just short for "Target FEC Stack TLV"
> which is specified in RFC 8029 which is already a Normative
> reference. I suggest:
>
> LSP Ping, as defined in [RFC6425], MAY be used to bootstrap
> MultipointTail. If LSP Ping is used, it MUST include the Target FEC
> Stack TLV [RFC8029] and the BFD Discriminator TLV [RFC5884]. For
> the case of p2mp MPLS LSP, the Target FEC Stack TLV MUST use
> sub-TLVs defined in Section 3.1 [RFC6425].
>
>>> 15) <!-- [rfced] May we update the introductory text to use "MUST" and
>>> remove
>>> "MUST" from each bullet? Or do you prefer the current?
>>>
>>> Original:
>>> A MultipointTail that receives an LSP Ping that includes the BFD
>>> Discriminator TLV:
>>>
>>> * MUST validate the LSP Ping;
>>>
>>> * MUST associate the received BFD Discriminator value with the p2mp
>>> LSP;
>>>
>>> * MUST create a p2mp BFD session and set bfd.SessionType =
>>> MultipointTail as described in [RFC8562];
>>>
>>> * MUST use the source IP address of LSP Ping, the value of BFD
>>> Discriminator from the BFD Discriminator TLV, and the identity of
>>> the p2mp LSP to properly demultiplex BFD sessions.
>>>
>>> Perhaps:
>>> A MultipointTail that receives an LSP Ping that includes the BFD
>>> Discriminator TLV MUST do the following:
>>>
>>> * validate the LSP Ping;
>>>
>>> * associate the received BFD Discriminator value with the P2MP
>>> LSP;
>>>
>>> * create a P2MP BFD session and set bfd.SessionType =
>>> MultipointTail as described in [RFC8562]; and
>>>
>>> * use the source IP address of the LSP Ping, the value of BFD
>>> Discriminator from the BFD Discriminator TLV, and the identity of
>>> the P2MP LSP to properly demultiplex BFD sessions.
>>> -->
>
> OK with your change.
>
>>> 16) <!-- [rfced] The second bulleted list in Section 5 is prefaced with the
>>> following text. However, it looks like only the first four bullets detail
>>> settings. Should the last two bullets be regular paragraphs rather than
>>> part of the list? Or should this introductory text be updated?
>>>
>>> Original:
>>> Upon detecting the failure of the p2mp MPLS LSP, an egress LSR sends
>>> BFD Control packet with the following settings:
>>> -->
>
> I think the last two bullet items can be regular paragraphs.
>
>>> 17) <!-- [rfced] What does "it" refer to here?
>>>
>>> Original:
>>> * these BFD Control packets are transmitted at the rate of one per
>>> second until either it receives a control packet valid for this
>>> BFD session with the Final (F) bit set from the ingress LSR or the
>>> defect condition clears.
>>>
>>> Perhaps:
>>> * These BFD Control packets are transmitted at the rate of one per
>>> second until either 1) the egress LSA receives a control packet from
>>> the ingress LSR
>>> that is valid for this BFD session and has the Final (F) bit set or 2)
>>> the
>>> defect condition clears.
>>> -->
>
> I agree with your suggested change.
>
>>> 18) <!-- [rfced] Please clarify "defined above" here. Is the intent "as
>>> defined
>>> above" (with "as"), "with the settings described above", or something
>>> else?
>>>
>>> Original:
>>> However, to improve the likelihood of
>>> notifying the ingress LSR of the failure of the p2mp MPLS LSP, the
>>> egress LSR SHOULD initially transmit three BFD Control packets
>>> defined above in short succession.
>>>
>>> Perhaps:
>>> However, to improve the likelihood of
>>> notifying the ingress LSR of the failure of the p2mp MPLS LSP, the
>>> egress LSR SHOULD initially transmit three BFD Control packets
>>> (as defined above) in short succession.
>>> -->
>
> OK with your change.
>
>>> 19) <!-- [rfced] FYI - We updated Table 2 to <dl> as the table was too wide
>>> for
>>> the txt output. Note that <dl> was used in other RFCs that have made
>>> allocations in the "IANA IPv6 Special-Purpose Address Registry" (e.g.,
>>> RFCs 9637, 9602, and 9374).
>>> -->
>
> OK.
>
>>> 20) <!-- [rfced] An informative reference is listed for the "IANA IPv6
>>> Special
>>> Purpose Address Registry" in Section 7.1. Would you like to also add an
>>> informative reference for the "MPLS Generalized Associated Channel
>>> (G-ACh) Types" registry in Section 7.2?
>>> -->
>
> I think that is a good idea.
>
>>> 21) <!-- [rfced] Terminology
>>>
>>> a) We see the following forms used in this document. Should "P2MP" or "MPLS"
>>> come first in this phrase?
>>>
>>> p2mp MPLS LSP
>>> MPLS p2mp LSP
>>> Point-to-Multipoint MPLS Label Switched Path (LSP)
>>> MPLS point-to-multipoint Label Switched Paths (LSPs)
>
> I believe P2MP or Point-to-Multipoint should come first.
>
>>> b) Please review the instances of "echo" in the document and let us know if
>>> they should be capitalized or lowercased.
>>>
>>> MPLS echo reply
>>> MPLS echo request
>>> LSP Ping Echo request message
>
> Generally, echo should be the same case as "reply' or "request", that
> is, in the above cases, lower case.
>
>>> c) We have updated "out-band" to "out-of-band" (two instances). Let us know
>>> any
>>> objections.
>
> That seems good.
>
>>> d) Would either of the following read more clearly? Or is the current okay?
>>>
>>> Current:
>>> the Dummy IPv6 Prefix range 100:0:0:1::/64
>>>
>>> Perhaps ("address block" instead of "range"):
>>> the Dummy IPv6 Prefix address block 100:0:0:1::/64
>>>
>>> Or ("address block" and parentheses):
>>> the Dummy IPv6 Prefix address block (100:0:0:1::/64)
>
> I don't think parenthesis are needed but "address block" is good.
>
>>> -->
>>
>>> 22) <!-- [rfced] Abbreviations
>>>
>>> a) We updated "p2mp" (lowercase) to "P2MP" (caps). The capitalized form is
>>> much
>>> more common in published RFCs, including in RFCs 9026 and 6425, which are
>>> normatively referenced by this document.
>
> OK.
>
>>> b) 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.
>>>
>>> Operations, Administration, and Maintenance (OAM)
>>> Pseudowire (PW)
>
> OK.
>
>>> -->
>>>
>>> 23) <!-- [rfced] Please review the "Inclusive Language" portion of the
>>> online
>>> Style Guide
>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504054117%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=qnIvJLNh30UWRCIbbdDknhJl9AQzJOsriD7nEnOW9NA%3D&reserved=0<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:
>>>
>>> Dummy
>
> I understand the problems with Dummy but it is hard to find another
> word with the right connotations. The best I can do is suggest
> replacing Dummy with Marker.
>
>>> -->
>>>
>>> Thank you.
>>> RFC Editor/rv
>>>
>>> On May 5, 2025, at 3:01 PM, rfc-edi...@rfc-editor.org wrote:
>>>
>>> *****IMPORTANT*****
>>>
>>> Updated 2025/05/05
>>>
>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504068845%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=8wggMfopOuft46tbjPH23YhXgMZu4H1swL5gEI53spU%3D&reserved=0<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
>
> See above.
>
> Thanks,
> Donald
> ===============================
> Donald E. Eastlake 3rd +1-508-333-2270 (cell)
> 2386 Panoramic Circle, Apopka, FL 32703 USA
> d3e...@gmail.com
>
>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504082775%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=rs4ucFDbyYzapSTPPssyOuzSswPFR9FUWsN3ZRc90aA%3D&reserved=0)<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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504096355%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=bzAib5c%2BA1sOwVbDh0PVzrN8Rwh85HDQC4c8JxjTIKk%3D&reserved=0>.
>>>
>>> * 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504106945%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Wg4bwtTOl%2BGTxxg4%2FKTL8JUP%2Bsu4x9D4w8l9Qqoinck%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>
>>>
>>> * The archive itself:
>>>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504120976%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=2g1mrm467ZgtkKydqb2lK0nHjDhmHJhV9SgQScotITA%3D&reserved=0<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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780.xml&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504133198%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=lkPPsHoFf6ExDlf2im89i3KERMa1aWIzeFl%2BrV69HBM%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780.xml>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504144069%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=4gHP4r%2FtsVsGBpdTMK3oHpkKnVBl2xzlkxg24dCa76U%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780.html>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780.pdf&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504156722%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=zIcFuluBv9K%2FaX7zfVUmFYyTCruxd%2FzIdWpLcGVZMZk%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780.pdf>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780.txt&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504170747%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=f7wy6Pu94WXR5znmVQ%2BnbCcdiIrdeGyJxK8IzMzYFMc%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780.txt>
>>>
>>> Diff file of the text:
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504184720%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=aB9qHSPVneE%2B9dkiz0la92xjQ9usY%2BtX0N4lDNsEXZQ%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780-diff.html>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780-rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504198111%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=bkJvlii8uEwbecXTSbjmGNQbW1Yu9ClYIgOZwdi2Vq0%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780-rfcdiff.html>
>>> (side by side)
>>>
>>> Alt-diff of the text (allows you to more easily view changes
>>> where text has been deleted or moved):
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780-alt-diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504212628%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=KT7zwDDwNMHtnAP7oS8Tt%2Fllhgr2GMYTkV5mRVHqHXw%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780-alt-diff.html>
>>>
>>> Diff of the XML:
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9780-xmldiff1.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504227084%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=KeCI8BMqGsl%2B8zT8Ipo5AYEDD6aTBLkYTjN4nvHdqk4%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9780-xmldiff1.html>
>>>
>>>
>>> Tracking progress
>>> -----------------
>>>
>>> The details of the AUTH48 status of your document are here:
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9780&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7Cd3244f5cd05440c19d3e08dd93ebe0a5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638829363504241311%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=BwlU7iRVYQv%2Bf0ynOYb%2BqFZ%2Bog5YZxEOgEfeVGsqUHU%3D&reserved=0<https://www.rfc-editor.org/auth48/rfc9780>
>>>
>>> Please let us know if you have any questions.
>>>
>>> Thank you for your cooperation,
>>>
>>> RFC Editor
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
