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
>
> Updated output files:
> https://www.rfc-editor.org/authors/rfc9780.txt
> https://www.rfc-editor.org/authors/rfc9780.pdf
> https://www.rfc-editor.org/authors/rfc9780.html
>
> Diff file showing all changes made during AUTH48:
> https://www.rfc-editor.org/authors/rfc9780-auth48diff.html
> https://www.rfc-editor.org/authors/rfc9780-auth48rfcdiff.html (side by
> side)
>
> Diff files showing all changes:
> https://www.rfc-editor.org/authors/rfc9780-diff.html
> https://www.rfc-editor.org/authors/rfc9780-rfcdiff.html (side by side)
> 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://www.rfc-editor.org/auth48/rfc9780
>
> 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
> > 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
> >>>>> ::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.
> >>
> >> 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 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.
> >>
> >> 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>
> >>>>> 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/).
> >>>>>
> >>>>> 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://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://authors.ietf.org/rfcxml-vocabulary>.
> >>>>>
> >>>>> * 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
> >>>>>
> >>>>> * The archive itself:
> >>>>> 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://www.rfc-editor.org/authors/rfc9780.xml
> >>>>> https://www.rfc-editor.org/authors/rfc9780.html
> >>>>> https://www.rfc-editor.org/authors/rfc9780.pdf
> >>>>> https://www.rfc-editor.org/authors/rfc9780.txt
> >>>>>
> >>>>> Diff file of the text:
> >>>>> https://www.rfc-editor.org/authors/rfc9780-diff.html
> >>>>> 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://www.rfc-editor.org/authors/rfc9780-alt-diff.html
> >>>>>
> >>>>> Diff of the XML:
> >>>>> https://www.rfc-editor.org/authors/rfc9780-xmldiff1.html
> >>>>>
> >>>>>
> >>>>> Tracking progress
> >>>>> -----------------
> >>>>>
> >>>>> The details of the AUTH48 status of your document are here:
> >>>>> 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
