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
