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
