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

[[e-mail]]

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