Hi Rebecca
Many Thanks for all your proposed changes to improve the document.
I agree with all of your comments and Greg & Donald’s responses and leaving
the dummy address unchanged and replacing “range” with “address block”.
Thank you
Gyan
On Sat, May 17, 2025 at 6:27 PM Greg Mirsky <gregimir...@gmail.com> wrote:
> Hi Rebecca,
> Thank you for your careful updates, which significantly improved the
> document. My follow-up note below is tagged GIM2>>.
>
> Best regards,
> Greg
>
> On Fri, May 16, 2025 at 8:50 PM Rebecca VanRheenen <
> rvanrhee...@staff.rfc-editor.org> wrote:
>
>> Hi Greg and Donald,
>>
>> Thank you for the replies! We have updated the document per Greg’s reply.
>> Donald, thank you for confirming your agreement with Greg's responses.
>>
>> We believe all questions have been addressed except for the followup
>> question below. The other followup comments sent 2025-05-15 were addressed
>> in Greg’s email (i.e., inclusive language and the sentence in Section 3).
>> Are any further changes needed per the following?
>>
>> >>> 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?
>>
> GIM2>> I agree with you, please update s/range/address block/ throughout
> the document to make it consistent.
>
>>
>>
>> — FILES (please refresh) —
>>
>> Updated XML file:
>> https://www.rfc-editor.org/authors/rfc9780.xml
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.xml&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=KIb-hsBwGz_7QAS7d97I72dpiQS72rR68K5YyAwA41E&e=>
>>
>> Updated output files:
>> https://www.rfc-editor.org/authors/rfc9780.txt
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=7Cyi9-_5UIPvqGLnhtt1IIsqFzp4UFp_uJkZ8Q9kAdg&e=>
>> https://www.rfc-editor.org/authors/rfc9780.pdf
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.pdf&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=hNaBfoZaCL4j0IbWA2GrEOKQMDLAdIKrUsp1qsLWUlU&e=>
>> https://www.rfc-editor.org/authors/rfc9780.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=uTw84xUrouhxQD1ENV2bfzFW4OhL5TtYZv2BPJB5wS8&e=>
>>
>> Diff file showing all changes made during AUTH48:
>> https://www.rfc-editor.org/authors/rfc9780-auth48diff.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Dauth48diff.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=0s4gyNLIXovTzttbHJOn62icvSi4z-NxZquicLIXBNU&e=>
>> https://www.rfc-editor.org/authors/rfc9780-auth48rfcdiff.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Dauth48rfcdiff.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=g0QM6n6TmwilFxiH2sjJMrOChOfaocnWXn0d-esmZyI&e=>
>> (side by side)
>>
>> Diff files showing all changes:
>> https://www.rfc-editor.org/authors/rfc9780-diff.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Ddiff.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=O96OyydAn5x38Utt8OpUPyPZtWC0YElDP7FfcVMxUhg&e=>
>> https://www.rfc-editor.org/authors/rfc9780-rfcdiff.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Drfcdiff.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=tve-UfmDMa0KPO2nPufVX7r3JtUuUtHn6ibd8Mkrz5Y&e=>
>> (side by side)
>> https://www.rfc-editor.org/authors/rfc9780-alt-diff.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Dalt-2Ddiff.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=Ej-1Gz3BhDXp4rTed5L45liL1FNn7D6nfxrNGHRnpjY&e=>
>> (diff showing changes where text is moved or deleted)
>>
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9780
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9780&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=JbR6tr-_gNSu9v9QwR7FRLge6wRNgAfEL2v58G48Bww&e=>
>>
>> Thank you,
>>
>> RFC Editor/rv
>>
>>
>>
>> > On May 15, 2025, at 5:19 PM, Donald Eastlake <d3e...@gmail.com> wrote:
>> >
>> > Hi Rebecca,
>> >
>> > I agree with all of Greg's answers below including leaving "dummy"
>> > unchanged and replacing the occurrences of "range" with "address
>> > block".
>> >
>> > Thanks,
>> > Donald
>> > ===============================
>> > Donald E. Eastlake 3rd +1-508-333-2270 (cell)
>> > 2386 Panoramic Circle, Apopka, FL 32703 USA
>> <https://www.google.com/maps/search/2386+Panoramic+Circle,+Apopka,+FL+32703+USA?entry=gmail&source=g>
>> > d3e...@gmail.com
>> >
>> > On Thu, May 15, 2025 at 6:19 PM Greg Mirsky <gregimir...@gmail.com>
>> wrote:
>> >>
>> >> Rebecca,
>> >> thank you for your thoughtful proposals helping in improving this
>> document.
>> >> Please find my responses to your questions below tagged GIM>>.
>> >>
>> >> Regards,
>> >> Greg
>> >>
>> >> On Wed, 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.
>> >>
>> >> GIM>> Agree with the updated version
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> We didn't elaborate on SR-MPLS because there are no differences
>> between it and IP/MPLS in the applicability of p2mp BFD. The MPLS and
>> SPRING WGs acknowledged that. Thus, I believe that there's no need to add
>> any informational text in this regard.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> I agree with the proposed update; thank you
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> I concur with Donald.
>> >>>
>> >>>
>> >>>>> 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
>> >>
>> >> GIM>> I agree with your suggestion adding reference to the use of LSP
>> Ping as in-band bootstrapping mechanism. It could be helpful to a reader if
>> the update also notes that LSP Ping serves as an in-band mechanism. Perhaps
>> update can be as follows:
>> >> NEW TEXT:
>> >> The document also describes the applicability of LSP Ping, as
>> in-band, 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.
>> >>
>> >> GIM>> I agree with that update and expansion of the OAM acronym on the
>> first use.
>> >>>
>> >>>>> -->
>> >>>
>> >>> 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1_128&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=8nGXpUPuuvOReUMPIsl_i1uXjPOLDz8EiJWrDp0QQGg&e=>
>> >>>>> ::ffff:127.0.0.1/128
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1_128&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=8nGXpUPuuvOReUMPIsl_i1uXjPOLDz8EiJWrDp0QQGg&e=>
>> >>>>>
>> >>>>> Should "address::ffff:127.0.0.1/128
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1_128&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=8nGXpUPuuvOReUMPIsl_i1uXjPOLDz8EiJWrDp0QQGg&e=>"
>> be updated as follows?
>> >>>>>
>> >>>>> Current:
>> >>>>> Historically, an IPv6-mapped IPv4 loopback range
>> >>>>> address::ffff:127.0.0.1/128
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1_128&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=8nGXpUPuuvOReUMPIsl_i1uXjPOLDz8EiJWrDp0QQGg&e=>
>> 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1_128&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=8nGXpUPuuvOReUMPIsl_i1uXjPOLDz8EiJWrDp0QQGg&e=>
>> was mandated, although functionally, an
>> >>>>> IPv6 address from that range is not analogous to its IPv4
>> >>>>> counterpart.
>> >>>
>> >>>>> -->
>> >>>
>> >>> I think that is a good change.
>> >>
>> >> GIM>> I agree, thank you
>> >>>
>> >>>
>> >>>>> 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1_128&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=8nGXpUPuuvOReUMPIsl_i1uXjPOLDz8EiJWrDp0QQGg&e=>
>> 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1_128&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=8nGXpUPuuvOReUMPIsl_i1uXjPOLDz8EiJWrDp0QQGg&e=>
>> 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1_128&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=8nGXpUPuuvOReUMPIsl_i1uXjPOLDz8EiJWrDp0QQGg&e=>
>> 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1_128&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=8nGXpUPuuvOReUMPIsl_i1uXjPOLDz8EiJWrDp0QQGg&e=>
>> range
>> >>>>> might be used by existing implementations. This document
>> discourages
>> >>>>> the use of an address from the ::ffff:127.0.0.1/128
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1_128&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=8nGXpUPuuvOReUMPIsl_i1uXjPOLDz8EiJWrDp0QQGg&e=>
>> range.
>> >>>>> -->
>> >>>
>> >>> I think your current text is best.
>> >>
>> >> GIM>> I think that we can keep the current version of the text.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> I agree with Donald that there is no apparent need to update
>> Section 3.1 of this draft. Instead, we should update the reference to point
>> to Section 5.7 of RFC 8562. Hence, the text reads as follows:
>> >> NEW TEXT:
>> >> 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 5.7 of [RFC8562].
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> I think that the update improves readability. I support the
>> proposed version.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> I agree with removing the second paragraph.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> I agree with Donald, this terminology is accepted in computing.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> A very good question, thank you. As Donald noted, "BFD Control
>> packet" and "BFD Control message" are used interchangeably in documents and
>> discussions. One solution could be to add a note to that in the Terminology
>> section or replace all four occurrences of "BFD Control message" with "BFD
>> Control packet". I can live with any solution, but the latter might be
>> easier to apply. WDYT?
>> >>>
>> >>>
>> >>>>> 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].
>> >>
>> >> GIM>> I agree with the text proposed by Donald.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> I concur with Donald and support the updated text.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> I agree with your proposal, it improves the readability.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> I concur with Donald and agree with the proposed update.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> Thank you for the proposed update, I agree with you.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> Thank you, agreed.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> Great suggestion, thanks.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> I agree with Donald.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> Lowercase is consistent with RFC 8029:
>> >> It defines a probe message called an "MPLS
>> >> echo request" and a response message called an "MPLS echo reply" for
>> >> returning the result of the probe.
>> >>>
>> >>>
>> >>>>> c) We have updated "out-band" to "out-of-band" (two instances). Let
>> us know any
>> >>>>> objections.
>> >>>
>> >>> That seems good.
>> >>
>> >> GIM>> I agree with the update.
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> As Donald said, I support the first option.
>> >>>
>> >>>
>> >>>>> -->
>> >>>>
>> >>>>> 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.
>> >>
>> >> GIM>>> Accepted
>> >>>
>> >>>
>> >>>>> 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.
>> >>
>> >> GIM>> Agree
>> >>>
>> >>>
>> >>>>> -->
>> >>>>>
>> >>>>> 23) <!-- [rfced] Please review the "Inclusive Language" portion of
>> the online
>> >>>>> Style Guide <
>> https://www.rfc-editor.org/styleguide/part2/#inclusive_language
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_styleguide_part2_-23inclusive-5Flanguage&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=90iJKmAez3-Z3XpootHVTBJoIQjD_uvYbXsdE0G_d34&e=>
>> >
>> >>>>> 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.
>> >>
>> >> GIM>> IANA registries of Special addresses already list address blocks
>> that include Dummy in the title. IESG agreed to that name.
>> >>>
>> >>>
>> >>>>> -->
>> >>>>>
>> >>>>> 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://www.rfc-editor.org/faq/
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_faq_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=Nb-le5YbTotUJ2HSxtwfecFWSQwYEONH8Vl0R8TnhD4&e=>
>> ).
>> >>>>>
>> >>>>> 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
>> <https://www.google.com/maps/search/2386+Panoramic+Circle,+Apopka,+FL+32703+USA?entry=gmail&source=g>
>> >>> 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://trustee.ietf.org/license-info
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__trustee.ietf.org_license-2Dinfo&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=q7WHjwvSm_9b6IT0JasOVvRmftRx7aBQvzm59nMtBGw&e=>
>> ).
>> >>>>>
>> >>>>> * Semantic markup
>> >>>>>
>> >>>>> Please review the markup in the XML file to ensure that elements of
>> >>>>> content are correctly tagged. For example, ensure that <sourcecode>
>> >>>>> and <artwork> are set correctly. See details at
>> >>>>> <https://authors.ietf.org/rfcxml-vocabulary
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__authors.ietf.org_rfcxml-2Dvocabulary&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=mNAzcSsqDv4itdqQoukcPO3R8ets1qORPNkYTeWbS98&e=>
>> >.
>> >>>>>
>> >>>>> * Formatted output
>> >>>>>
>> >>>>> Please review the PDF, HTML, and TXT files to ensure that the
>> >>>>> formatted output, as generated from the markup in the XML file, is
>> >>>>> reasonable. Please note that the TXT will have formatting
>> >>>>> limitations compared to the PDF and HTML.
>> >>>>>
>> >>>>>
>> >>>>> Submitting changes
>> >>>>> ------------------
>> >>>>>
>> >>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as
>> all
>> >>>>> the parties CCed on this message need to see your changes. The
>> parties
>> >>>>> include:
>> >>>>>
>> >>>>> * your coauthors
>> >>>>>
>> >>>>> * rfc-edi...@rfc-editor.org (the RPC team)
>> >>>>>
>> >>>>> * other document participants, depending on the stream (e.g.,
>> >>>>> IETF Stream participants are your working group chairs, the
>> >>>>> responsible ADs, and the document shepherd).
>> >>>>>
>> >>>>> * auth48archive@rfc-editor.org, which is a new archival mailing
>> list
>> >>>>> to preserve AUTH48 conversations; it is not an active discussion
>> >>>>> list:
>> >>>>>
>> >>>>> * More info:
>> >>>>>
>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_ietf-2Dannounce_yb6lpIGh-2D4Q9l2USxIAe6P8O4Zc&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=Qp4DiS_G6J-Qkl1uYkW_P72c_jaPwL07Hey8ALldhLU&e=>
>> >>>>>
>> >>>>> * The archive itself:
>> >>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_auth48archive_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=-3TxPo1ycKMizJuACxNGGxcc4mvYt8GeJ5WGbQCLAbk&e=>
>> >>>>>
>> >>>>> * Note: If only absolutely necessary, you may temporarily opt out
>> >>>>> of the archiving of messages (e.g., to discuss a sensitive
>> matter).
>> >>>>> If needed, please add a note at the top of the message that you
>> >>>>> have dropped the address. When the discussion is concluded,
>> >>>>> auth48archive@rfc-editor.org will be re-added to the CC list
>> and
>> >>>>> its addition will be noted at the top of the message.
>> >>>>>
>> >>>>> You may submit your changes in one of two ways:
>> >>>>>
>> >>>>> An update to the provided XML file
>> >>>>> — OR —
>> >>>>> An explicit list of changes in this format
>> >>>>>
>> >>>>> Section # (or indicate Global)
>> >>>>>
>> >>>>> OLD:
>> >>>>> old text
>> >>>>>
>> >>>>> NEW:
>> >>>>> new text
>> >>>>>
>> >>>>> You do not need to reply with both an updated XML file and an
>> explicit
>> >>>>> list of changes, as either form is sufficient.
>> >>>>>
>> >>>>> We will ask a stream manager to review and approve any changes that
>> seem
>> >>>>> beyond editorial in nature, e.g., addition of new text, deletion of
>> text,
>> >>>>> and technical changes. Information about stream managers can be
>> found in
>> >>>>> the FAQ. Editorial changes do not require approval from a stream
>> manager.
>> >>>>>
>> >>>>>
>> >>>>> Approving for publication
>> >>>>> --------------------------
>> >>>>>
>> >>>>> To approve your RFC for publication, please reply to this email
>> stating
>> >>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’,
>> >>>>> as all the parties CCed on this message need to see your approval.
>> >>>>>
>> >>>>>
>> >>>>> Files
>> >>>>> -----
>> >>>>>
>> >>>>> The files are available here:
>> >>>>> https://www.rfc-editor.org/authors/rfc9780.xml
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.xml&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=KIb-hsBwGz_7QAS7d97I72dpiQS72rR68K5YyAwA41E&e=>
>> >>>>> https://www.rfc-editor.org/authors/rfc9780.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=uTw84xUrouhxQD1ENV2bfzFW4OhL5TtYZv2BPJB5wS8&e=>
>> >>>>> https://www.rfc-editor.org/authors/rfc9780.pdf
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.pdf&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=hNaBfoZaCL4j0IbWA2GrEOKQMDLAdIKrUsp1qsLWUlU&e=>
>> >>>>> https://www.rfc-editor.org/authors/rfc9780.txt
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=7Cyi9-_5UIPvqGLnhtt1IIsqFzp4UFp_uJkZ8Q9kAdg&e=>
>> >>>>>
>> >>>>> Diff file of the text:
>> >>>>> https://www.rfc-editor.org/authors/rfc9780-diff.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Ddiff.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=O96OyydAn5x38Utt8OpUPyPZtWC0YElDP7FfcVMxUhg&e=>
>> >>>>> https://www.rfc-editor.org/authors/rfc9780-rfcdiff.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Drfcdiff.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=tve-UfmDMa0KPO2nPufVX7r3JtUuUtHn6ibd8Mkrz5Y&e=>
>> (side by side)
>> >>>>>
>> >>>>> Alt-diff of the text (allows you to more easily view changes
>> >>>>> where text has been deleted or moved):
>> >>>>> https://www.rfc-editor.org/authors/rfc9780-alt-diff.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Dalt-2Ddiff.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=Ej-1Gz3BhDXp4rTed5L45liL1FNn7D6nfxrNGHRnpjY&e=>
>> >>>>>
>> >>>>> Diff of the XML:
>> >>>>> https://www.rfc-editor.org/authors/rfc9780-xmldiff1.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Dxmldiff1.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=TZiJpkzUFgntwHLgF1RdoveEZSvvtNTnimoYz1DmoNQ&e=>
>> >>>>>
>> >>>>>
>> >>>>> Tracking progress
>> >>>>> -----------------
>> >>>>>
>> >>>>> The details of the AUTH48 status of your document are here:
>> >>>>> https://www.rfc-editor.org/auth48/rfc9780
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9780&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4s46POZZSbj-mQ4AyjcRs4hhV9O23A4PgcvIqjxlIfLqFmZ35spTbfyHGfFOtSdS&s=JbR6tr-_gNSu9v9QwR7FRLge6wRNgAfEL2v58G48Bww&e=>
>> >>>>>
>> >>>>> 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
