Hi Jim,
Thank you for the input.
Thank you,
RFC Editor/rv
> On May 16, 2025, at 4:51 AM, James Guichard <james.n.guich...@futurewei.com>
> wrote:
>
> 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>
> >>> 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
>
> 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://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://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
>
> 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://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
> (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://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
> (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
> (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
>
> 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>
> >>> 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).
> >>>
> >>> 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).
> >>>
> >>> * 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
> >>>
> >>> * 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
> >>>
> >>> * 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://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://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://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
> >>>
> >>> 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://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
> >>> (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
> >>>
> >>> 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
> >>>
> >>>
> >>> 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
> >>>
> >>> 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
