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

[Alanna Paloma <[e-mail]>]

Hi Albert,

Thank you for your reply. We have noted your approval on the AUTH48 status page:
https://www.rfc-editor.org/auth48/rfc9300

Best regards,
RFC Editor/ap

> On Sep 13, 2022, at 5:10 AM, Albert Cabellos <[e-mail]> wrote:
> 
> Approve
> 
> Thanks!
> 
> Albert
> 
>> On 13 Sept 2022, at 02:14, Dino Farinacci <[e-mail]> wrote:
>> 
>> All looks good. You have my approval. 
>> 
>> Dino
>> 
>>> On Sep 12, 2022, at 4:47 PM, Alanna Paloma <[e-mail]> wrote:
>>> 
>>> Hi Dino and Darrel,
>>> 
>>> We have noted Darrel’s approval on the AUTH48 status page:
>>> https://www.rfc-editor.org/auth48/rfc9300
>>> 
>>> Dino - We have updated two instances of "echo-nonce-request state” to "echo-nonce state”; thank you for the clarification. Please review and let us know if this update is now correct. Additionally, we will give the remaining authors some time to review and approve the document before we escalate their absence to the AD.
>>> 
>>> The files have been posted here (please refresh):
>>> https://www.rfc-editor.org/authors/rfc9300.txt
>>> https://www.rfc-editor.org/authors/rfc9300.pdf
>>> https://www.rfc-editor.org/authors/rfc9300.html
>>> https://www.rfc-editor.org/authors/rfc9300.xml
>>> 
>>> The relevant diff files are posted here:
>>> https://www.rfc-editor.org/authors/rfc9300-diff.html (comprehensive diff)
>>> https://www.rfc-editor.org/authors/rfc9300-auth48diff.html (all AUTH48 changes)
>>> https://www.rfc-editor.org/authors/rfc9300-lastdiff.html (htmlwdiff diff between last version and this)
>>> https://www.rfc-editor.org/authors/rfc9300-lastrfcdiff.html (rfcdiff between last version and this)
>>> 
>>> Thank you,
>>> RFC Editor/ap
>>> 
>>>> On Sep 12, 2022, at 2:27 PM, Darrel Lewis (darlewis) <darlewis=[e-mail]> wrote:
>>>> 
>>>> 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
>>>>> 
>>>>> 
>>>> 
>>> 
>