Re: [auth48] [C381] AUTH48: RFC-to-be 9300 <draft-ietf-lisp-rfc6830bis-38> for your review

["Darrel Lewis (darlewis)" <[e-mail]>]

All,

Thanks to the dedication of the entire WG (and especially Dino) for driving this.  I very much approve of its publication as an RFC.

-Darrel

Darrel Lewis
[e-mail]



> On Sep 7, 2022, at 5:00 PM, [e-mail] wrote:
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] *AD:  Quite a few updates were made in Section 13.2 of
> the most recent version (-38) of this document.  Please review, and
> let us know if you approve. 
> 
> You can easily view the diff here:  
> https://www.ietf.org//rfcdiff?url1=draft-ietf-lisp-rfc6830bis-36&url2=draft-ietf-lisp-rfc6830bis-38
> -->
> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in 
> the title) for use on <https://www.rfc-editor.org/search>. -->
> 
> 
> 3) <!-- [rfced] Section 1:  This sentence reads oddly, especially as
> compared to "separates control from data" in the Abstract.  Will
> "separates control from the data plane" (as edited) be clear to
> readers?
> 
> Original:
> LISP is an overlay protocol that separates control from Data-Plane,
> this document specifies the Data-Plane as well as how LISP-capable
> routers (Tunnel Routers) exchange packets by encapsulating them to
> the appropriate location.
> 
> Currently:
> LISP is an overlay protocol that separates control from the data
> plane; this document specifies the data plane as well as how LISP-
> capable routers (Tunnel Routers) exchange packets by encapsulating
> them to the appropriate location.
> 
> Possibly:
> LISP is an overlay protocol that separates control from data; this
> document specifies the data plane as well as how LISP-capable
> routers (Tunnel Routers) exchange packets by encapsulating them to
> the appropriate location. -->
> 
> 
> 4) <!-- [rfced] Section 1.1:  "LISP uses have been found and are being
> used" reads oddly.  May we update as suggested?
> 
> Original ("as been" has been fixed):
> While there are a number of approaches of
> interest for that problem, as LISP as been developed and refined, a
> large number of other LISP uses have been found and are being used.
> 
> Suggested:
> While there are a number of approaches of
> interest for that problem, as LISP has been developed and refined, a
> large number of other ways to use LISP have been found and are being
> implemented. -->
> 
> 
> 5) <!-- [rfced] Section 3:  Please let us know how the following text
> should be updated.
> 
> a) "An address family that pertains to addresses found in Data-Plane
> headers" is a fragment.  Please provide corrected text.
> 
> b) RFC 3232 ("Assigned Numbers: RFC 1700 is Replaced by an On-line
> Database") does not directly mention "Address Family Identifier",
> "AFI", or "address"; it seems unlikely that readers would consult the
> obsoleted RFC 1700 to find the relevant information, unless they are
> directed to it.  Is there a current AFI-related RFC that would be
> more helpful?
> 
> Original:
> An address family that pertains to
> addresses found in Data-Plane headers.  See [AFN] and [RFC3232]
> for details. -->
> 
> 
> 6) <!-- [rfced] Section 3:  Please clarify the following:
> 
> a) As this sentence is written in the present tense, "the same way it
> obtains a destination address today" is confusing.  Are some words
> missing?
> 
> Original:
> The host obtains a destination
> EID the same way it obtains a destination address today, for
> example, through a Domain Name System (DNS) [RFC1034] lookup or
> Session Initiation Protocol (SIP) [RFC3261] exchange.
> 
> Possibly:
> At the time of this writing, the host obtains a destination
> EID the same way that many implementations obtain destination
> addresses - for example, through a Domain Name System (DNS) lookup
> [RFC1034] or Session Initiation Protocol (SIP) exchange [RFC3261].
> 
> b) The first sentence here indicates that discussions take place
> with other proposals.  If the suggested text is not correct, please
> clarify.
> 
> Original:
> When used in discussions with other Locator/ID
> separation proposals, a LISP EID will be called an "LEID".
> Throughout this document, any references to "EID" refer to an
> LEID.
> 
> Suggested*:
> When discussing other Locator/ID separation proposals, any
> references to an EID in this document will refer to a LISP EID.
> 
> * We also suggest removing "LEID", because it is only used twice
> in published RFCs to date:  one sentence each in RFCs 6830 and
> 8112.  Also, "LEID" is not used anywhere else in the group of
> RFCs-to-be related to this document (Cluster 381 /
> <https://www.rfc-editor.org/cluster_info.php?cid=C381>): -->
> 
> 
> 7) <!-- [rfced] Section 3:  This sentence is difficult to follow.
> Should "LISP-specific 8-octet header that follow" be
> "LISP-specific 8-octet header that follows", or does "follow" refer
> to the outer IPv4 or IPv6 header, a UDP header, and a LISP-specific
> 8-octet header?  Please clarify what the LISP header is composed of
> and what an ITR prepends or an ETR strips.
> 
> Original:
> LISP Header:   LISP header is a term used in this document to refer
>    to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
>    specific 8-octet header that follow the UDP header and that an ITR
>    prepends or an ETR strips.
> 
> Possibly:
> LISP Header:  "LISP header" is a term used in this document to refer
>    to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
>    specific 8-octet header, all of which follow the UDP header.  An
>    ITR prepends LISP headers on packets, and an ETR strips them. -->
> 
> 
> 8) <!-- [rfced] Section 4:  As this sentence is written in the present
> tense, "end-systems operate the same way they do today" is confusing.
> Are some words missing?
> 
> Original:
> One key concept of LISP is that end-systems operate the same way they
> do today.
> 
> Possibly:
> One key concept of LISP is that, at the time of this writing, LISP
> end-systems operate the same way as end-systems do in other current
> implementations. -->
> 
> 
> 9) <!-- [rfced] Sections 4 and subsequent:  Since "Routing Locator" was
> already defined as "RLOC" several times prior to this point, would
> you like to change "Routing Locator", when used in running text, to
> "RLOC" from this point onward?
> 
> Original:
> o  LISP routers mostly deal with Routing Locator addresses.
> ...
> Section 10 for Routing Locator Reachability
> ...
> Routing Locator reachability algorithms
> etc. -->
> 
> 
> 10) <!-- [rfced] Section 4:  This sentence reads oddly.  We updated as
> follows.  Please let us know any objections.
> 
> Original (the previous sentence is included for context):
> o  LISP routers mostly deal with Routing Locator addresses.  See
>    details in Section 4.2 to clarify what is meant by "mostly".
> 
> Currently:
> For
> details and clarifications regarding this topic, see Section 4.2. -->
> 
> 
> 11) <!-- [rfced] Sections 4, 4.2, 5, and 7.1:  We note that this document
> includes "RECOMMENDS" and "OPTIONALLY"; these are not considered
> official key words as listed in RFCs 2119 and 8174.  May these
> instances be rephrased to use "RECOMMENDED" and "OPTIONAL"?
> 
> Original:
> In order to avoid excessive packet overhead as well as possible
> encapsulation loops, this document RECOMMENDS that a maximum of two
> LISP headers can be prepended to a packet.
> ...
> 8.  In order to defer the need for a mapping lookup in the reverse
>     direction, an ETR can OPTIONALLY create a cache entry that maps
>     the source EID (inner-header source IP address) to the source
>     RLOC (outer-header source IP address) in a received LISP packet.
> ...
> In the case when fragmentation is needed, this specification
> RECOMMENDS that implementations provide support for one of the
> proposed fragmentation and reassembly schemes.
> ...
> This specification RECOMMENDS that L be defined as 1500.
> 
> Possibly:
> In order to avoid excessive packet overhead as well as possible
> encapsulation loops, it is RECOMMENDED that a maximum of two
> LISP headers can be prepended to a packet.
> ...
> 8.  In order to defer the need for a mapping lookup in the reverse
>     direction, it is OPTIONAL for an ETR to create a cache entry
>     that maps the source EID (inner-header source IP address) to the
>     source RLOC (outer-header source IP address) in a received LISP
>     packet.
> ...
> In the case when fragmentation is needed, it is RECOMMENDED that
> implementations provide support for one of the proposed
> fragmentation and reassembly schemes.
> ...
> It is RECOMMENDED that L be defined as 1500. -->
> 
> 
> 12) <!-- [rfced] Section 4.1:  Should "Instead relying solely on" in this
> bullet item be "Instead, they MUST rely solely on", per the bullet
> item just before this one?
> 
> Original:
> o  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
>    as described in Section 13 to update the EID-to-RLOC Mappings.
>    Instead relying solely on control-plane methods. -->
> 
> 
> 13) <!-- [rfced] Section 5.3:  The punctuation in these sentences made
> the text difficult to follow.  We updated per the first bullet item
> under "When doing ITR/PITR encapsulation:" (i.e., using parenthetical
> phrases).  Please let us know any objections.
> 
> Original:
> When doing ITR/PITR encapsulation:
> 
> o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in
>    the case of IPv6) SHOULD be copied from the inner-header 'Time to
>    Live' field.
> 
> o  The outer-header IPv4 'Differentiated Services Code Point' (DSCP)
>    field or the 'Traffic Class' field, in the case of IPv6, SHOULD be
>    copied from the inner-header IPv4 DSCP field or 'Traffic Class'
>    field in the case of IPv6, to the outer-header.  Guidelines for
>    this can be found at [RFC2983].
> ...
> When doing ETR/PETR decapsulation:
> 
> o  The inner-header IPv4 'Time to Live' field or 'Hop Limit' field in
>    the case of IPv6, MUST be copied from the outer-header 'Time to
>    Live'/'Hop Limit' field, when the 'Time to Live'/'Hop Limit' value
>    of the outer header is less than the 'Time to Live'/'Hop Limit'
>    value of the inner header.  Failing to perform this check can
>    cause the 'Time to Live'/'Hop Limit' of the inner header to
>    increment across encapsulation/decapsulation cycles.  This check
>    is also performed when doing initial encapsulation, when a packet
>    comes to an ITR or PITR destined for a LISP site.
> 
> o  The outer-header IPv4 'Differentiated Services Code Point' (DSCP)
>    field or the 'Traffic Class' field in the case of IPv6, SHOULD be
>    copied from the outer-header IPv4 DSCP field or 'Traffic Class'
>    field in the case of IPv6, to the inner-header.  Guidelines for
>    this can be found at [RFC2983].
> 
> Currently:
> When doing ITR/PITR encapsulation:
> 
> *  The outer-header 'Time to Live' field (or 'Hop Limit' field, in
>    the case of IPv6) SHOULD be copied from the inner-header 'Time to
>    Live' field.
> 
> *  The outer-header IPv4 'Differentiated Services Code Point (DSCP)'
>    field (or 'Traffic Class' field, in the case of IPv6) SHOULD be
>    copied from the inner-header IPv4 'DSCP' field (or 'Traffic Class'
>    field, in the case of IPv6) to the outer header.  Guidelines for
>    this can be found in [RFC2983].
> ...
> When doing ETR/PETR decapsulation:
> 
> *  The inner-header IPv4 'Time to Live' field (or 'Hop Limit' field,
>    in the case of IPv6) MUST be copied from the outer-header 'Time to
>    Live'/'Hop Limit' field when the Time to Live / Hop Limit value of
>    the outer header is less than the Time to Live / Hop Limit value
>    of the inner header.  Failing to perform this check can cause the
>    Time to Live / Hop Limit of the inner header to increment across
>    encapsulation/decapsulation cycles.  This check is also performed
>    when doing initial encapsulation, when a packet comes to an ITR or
>    PITR destined for a LISP site.
> 
> *  The outer-header IPv4 'Differentiated Services Code Point (DSCP)'
>    field (or 'Traffic Class' field, in the case of IPv6) SHOULD be
>    copied from the outer-header 'IPv4 DSCP' field (or 'Traffic Class'
>    field, in the case of IPv6) to the inner header.  Guidelines for
>    this can be found in [RFC2983]. -->
> 
> 
> 14) <!-- [rfced] Section 5.3:  We don't see "PxTR" or "PxTRs" used
> anywhere else in this document or in the group of RFCs-to-be related
> to this document (Cluster 381; see 
> <https://www.rfc-editor.org/cluster_info.php?cid=C381>).  Does "PxTRs"
> mean "PETRs and PITRs"?
> 
> Original (the subject-verb disagreement has been fixed):
> Some xTRs and PxTRs performs re-encapsulation operations and need to
> treat the 'Explicit Congestion Notification' (ECN) in a special way.
> 
> Suggested (since "PxTRs" isn't used anywhere else)*:
> Some xTRs, PETRs, and PITRs perform re-encapsulation operations and
> need to treat ECN functions in a special way.
> -->
> 
> 
> 15) <!-- [rfced] Section 7.2: RFC 1981 has been obsoleted by RFC 8201.
> Because the citation is general, we updated the RFC number here and
> in the Informative References section.
> 
> However, this sentence seems to say that the RFCs themselves can
> behave suboptimally.  If the suggested text is not correct, please
> clarify what can behave suboptimally.
> 
> Original:
> Please note that [RFC1191] and [RFC1981], which describe the use of
> ICMP packets for PMTU discovery, can behave suboptimally in the
> presence of ICMP black holes or off-path attackers that spoof ICMP.
> 
> Currently:
> Please note that [RFC1191] and [RFC8201], which describe the use of
> ICMP packets for PMTU discovery, can behave suboptimally in the
> presence of ICMP black holes or off-path attackers that spoof ICMP.
> 
> Suggested:
> Please note that using ICMP packets for PMTU discovery, as described
> in [RFC1191] and [RFC8201], can result in suboptimal behavior in the
> presence of ICMP black holes or off-path attackers that spoof ICMP. -->
> 
> 
> 16) <!-- [rfced] Section 9:  These sentences are difficult to parse.
> In the first sentence here, it appears that the client-side ITR
> gives itself responsibility for bidirectional RLOC reachability and
> preferability.  Is the server-side ETR the responsible entity?
> 
> In the second sentence, it appears that either (1) one or more words
> are missing after "alternate" or (2) a word other than "alternate"
> should be used.  If the suggested text is not correct, please
> clarify.
> 
> Original:
> For example, if the server-side ETR gleans RLOCs, then
> the client-side ITR gives the client-side ITR responsibility for
> bidirectional RLOC reachability and preferability.
> ...
> The client-side ITR controls how traffic is
> returned and can alternate using an outer-header source RLOC,
> which then can be added to the list the server-side ETR uses to
> return traffic.
> 
> Suggested:
> For example, if the server-side ETR gleans RLOCs, then
> the client-side ITR gives the server-side ETR responsibility for
> bidirectional RLOC reachability and preferability.
> ...
> The client-side ITR controls how traffic is
> returned and can, as an alternative, use an outer-header source
> RLOC, which then can be added to the list the server-side ETR uses
> to return traffic. -->
> 
> 
> 17) <!-- [rfced] Section 9:  Should "'TTL' field" here be "'Time to Live'
> field" as used elsewhere in this document?  If yes, may we remove
> the "TTL" in the "Copying the Time to Live (TTL)" sentence in
> Section 5.3, as "TTL" isn't used anywhere else?
> 
> Original:
> A reply to this "verifying Map-Request" is
> used to fully populate the Map-Cache entry for the "gleaned" EID
> and is stored and used for the time indicated from the 'TTL' field
> of a received Map-Reply. -->
> 
> 
> 18) <!-- [rfced] Section 10:  Because "PE" is used only once in this
> document, for ease of the reader we changed it to "Provider Edge" as
> used in draft-ietf-lisp-introduction.  Please let us know if any corrections are needed. 
> 
> Original:
> o  If an ITR fails or if the upstream link to its PE fails, its
>    default route will either time out or be withdrawn.
> 
> Currently:
> *  If an ITR fails or if the upstream link to its Provider Edge
>    fails, its default route will either time out or be withdrawn. -->
> 
> 
> 19) <!-- [rfced] Section 10.1:  We updated this run-on sentence as
> follows.  If this is incorrect, please provide clarifying text
> (e.g., does the packet include the nonce, and not the ETR?).
> 
> Original:
> When the ETR is an xTR (co-located as an ITR),
> it then sends a data packet to the ITR (when it is an xTR co-located
> as an ETR), it includes the nonce received earlier with the N-bit set
> and E-bit cleared.
> 
> Currently:
> When the ETR is an xTR (co-located as an ITR),
> it then sends a data packet to the ITR (when it is an xTR co-located
> as an ETR) and includes the nonce received earlier with the N-bit set
> and E-bit cleared. -->
> 
> 
> 20) <!-- [rfced] Section 10.1:  Should "echo nonce requests" be
> "echo-nonce-request packets" as used in the next sentence?
> 
> Original (the next sentence is included for context):
> The number of packets sent or the time during which echo
> nonce requests are sent is an implementation-specific setting.  In
> this case, an xTR receiving the echo-nonce-request packets will
> suspend the echo-nonce-request state and setup a 'echo-nonce-request-
> state' timer. -->
> 
> 
> 21) <!-- [rfced] Section 12:  Should "then" be "and" in this sentence?
> If not, please clarify the text.
> 
> Original:
> When the inner header is IPv6 then the flow label is not
> zero, it MAY be used to compute the hash. -->
> 
> 
> 22) <!-- [rfced] Section 13:  As it appears that "which ITRs requested
> its mappings" means "which ITRs requested their mappings" and
> "but need to provide" means "but implementors need to provide",
> we updated these sentences accordingly.  If these changes are
> incorrect, please provide clarifying text.
> 
> Original:
> However, the ITRs do not
> know when the mappings change, and the ETRs do not keep track of
> which ITRs requested its mappings.  For scalability reasons, it is
> desirable to maintain this approach but need to provide a way for
> ETRs to change their mappings and inform the sites that are currently
> communicating with the ETR site using such mappings.
> 
> Currently:
> However, the ITRs do not
> know when the mappings change, and the ETRs do not keep track of
> which ITRs requested their mappings.  For scalability reasons, it is
> desirable to maintain this approach, but implementors need to provide
> a way for ETRs to change their mappings and inform the sites that are
> currently communicating with the ETR site using such mappings. -->
> 
> 
> 23) <!-- [rfced] Section 13.1:  Please confirm that "setting" and not
> "sending" is correct here.  We ask because of the word "receiving"
> in the same sentence.
> 
> Original:
> In this section the term "source xTR" is used
> to refer to the xTR setting the LSB and "destination xTR" is used to
> refer to the xTR receiving the LSB. -->
> 
> 
> 24) <!-- [rfced] Section 13.1:  Does "use LSB (L-bit = 0)" mean "use the
> LSB if the L-bit is set to 0", or something else?  Please clarify.
> 
> Original ("will setup" has been fixed):
> At this point the source xTR MUST NOT use LSB
> (L-bit = 0) since the destination xTR site has outdated information.
> The source xTR will setup a 'use-LSB' timer. -->
> 
> 
> 25) <!-- [rfced] Section 15:  We expanded "MAC" as "Message
> Authentication Code" here.  If this is incorrect, please provide
> the correct definition.
> 
> Original:
> o  On an ITR, prepending a new IP header consists of adding more
>    octets to a MAC rewrite string and prepending the string as part
>    of the outgoing encapsulation procedure.
> 
> Currently:
> *  On an ITR, prepending a new IP header consists of adding more
>    octets to a Message Authentication Code (MAC) rewrite string and
>    prepending the string as part of the outgoing encapsulation
>    procedure. -->
> 
> 
> 26) <!-- [rfced] Section 16:  As we only see the concept of the
> gleaning mechanism discussed in the singular, we updated this
> sentence accordingly.  If this update is incorrect, please provide
> clarifying text.
> 
> Original:
> The optional mechanisms of gleaning is offered to directly obtain a
> mapping from the LISP encapsulated packets.
> 
> Currently:
> The optional gleaning mechanism is offered to directly obtain a
> mapping from the LISP-encapsulated packets. -->
> 
> 
> 27) <!-- [rfced] Section 16:
> 
> a) This sentence was difficult to follow.  We updated it as listed
> below.  If this is incorrect, please provide clarifying text.
> 
> Original:
> Note the attacker must guess a
> valid nonce the ITR is requesting to be echoed within a small window
> of time.
> 
> Currently:
> Note that the attacker only
> has a small window of time within which to guess a valid nonce that
> the ITR is requesting to be echoed.
> 
> b) We did not see "uRPF", "RPF", "reverse path forwarding", or "path
> forwarding" in RFC 2827 - only "reverse tunnels" and "reverse
> tunneling".  Will this citation be clear to readers, or should a
> different RFC be cited here?
> 
> Original:
> This specific attack can be
> mitigated by preventing RLOC spoofing in the network by deploying
> uRPF BCP 38 [RFC2827]. -->
> 
> 
> 28) <!-- [rfced] Section 16:  Should "outer header fragments" be
> "outer-header fragments", per "outer-header source IP address",
> "outer-header 'Time to Live' field", "outer-header encapsulation",
> etc.?
> 
> Original:
> LISP implementations and deployments which permit outer header
> fragments of IPv6 LISP encapsulated packets as a means of dealing
> with MTU issues should also use implementation techniques in ETRs to
> prevent this from being a DoS attack vector. -->
> 
> 
> 29) <!-- [rfced] Should "help" be "helped" (past tense) here?  
> 
> Original: 
>   The current authors would like to give a sincere thank you to the
>   people who help put LISP on standards track in the IETF.
> -->
> 
> 
> 30) <!-- [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.  For example, please consider
> whether the following should be updated: black hole and native. 
> 
> In addition, consider whether "traditional" should be updated. It may be 
> ambiguous as it is subjective. 
> -->
> 
> 
> 31) <!-- [rfced] Please let us know if any changes are needed for the
> following:
> 
> a) The following term was used inconsistently in this document.
> We chose to use the latter form.  Please let us know any objections.
> 
> Reserved and unassigned bit / reserved and unassigned bit
>   (per "documented as reserved and unassigned" in Section 18
>   and per draft-ietf-lisp-rfc6833bis)
> 
> b) The following terms appear to be used inconsistently in this
> document.  Please let us know which form is preferred.
> 
> a Nonce / a nonce (e.g., "a nonce", "a Nonce value")
> 
> ICMP Unreachable / ICMPv4 ICMP Unreachable / ICMPv4 Unreachable -->
> 
> 
> Thank you.
> 
> RFC Editor
> 
> 
> On Sep 7, 2022, at 4:56 PM, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2022/09/07
> 
> 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
> 
>   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
> 
>   *  [e-mail] (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).
> 
>   *  [e-mail], 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, 
>        [e-mail] 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/rfc9300.xml
>   https://www.rfc-editor.org/authors/rfc9300.html
>   https://www.rfc-editor.org/authors/rfc9300.pdf
>   https://www.rfc-editor.org/authors/rfc9300.txt
> 
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9300-diff.html
>   https://www.rfc-editor.org/authors/rfc9300-rfcdiff.html (side by side)
> 
> Diff of the XML: 
>   https://www.rfc-editor.org/authors/rfc9300-xmldiff1.html
> 
> The following files are provided to facilitate creation of your own 
> diff files of the XML.  
> 
> Initial XMLv3 created using XMLv2 as input:
>   https://www.rfc-editor.org/authors/rfc9300.original.v2v3.xml 
> 
> XMLv3 file that is a best effort to capture v3-related format updates 
> only: 
>   https://www.rfc-editor.org/authors/rfc9300.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9300
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9300 (draft-ietf-lisp-rfc6830bis-38)
> 
> Title            : The Locator/ID Separation Protocol (LISP)
> Author(s)        : D. Farinacci, V. Fuller, D. Meyer, D. Lewis, A. Cabellos (Ed.)
> WG Chair(s)      : Joel M. Halpern, Luigi Iannone
> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> 
>