Re: [auth48] [C381] AUTH48: RFC-to-be 9301 <draft-ietf-lisp-rfc6833bis-31> 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] We have updated the document title as follows.  Please
let us know any concerns.

Original:
 Locator/ID Separation Protocol (LISP) Control-Plane

Currently:
 Locator/ID Separation Protocol (LISP) Control Plane -->


2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on <https://www.rfc-editor.org/search>. -->


3) <!-- [rfced] Abstract and Section 1:  Which form is correct -
"control plane and Mapping Service" (which appears to refer to two
concepts) or "control plane Mapping Service" (which appears to refer
to one concept)?

Original:
 This document describes the Control-Plane and Mapping Service for the
 Locator/ID Separation Protocol (LISP), implemented by two types of
 LISP-speaking devices - the LISP Map-Resolver and LISP Map-Server -
 that provides a simplified "front end" for one or more Endpoint ID to
 Routing Locator mapping databases.
...
 This LISP Control-Plane Mapping Service can be used by many different
 encapsulation-based or translation-based Data-Planes which include
 but are not limited to the ones defined in LISP RFC 6830bis
 [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN
 [RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GRE [RFC2890], GTP
 [GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6)
 [RFC8402]. -->


4) <!-- [rfced] Abstract:  Please review the following:

a) As it appears that "facilitates" refers to the behavior of the
ITRs and ETRs, we updated this sentence accordingly.  If this is
incorrect, please provide clarifying text.

Original:
 By using this Control-Plane service interface and communicating with
 Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
 Egress Tunnel Routers (ETRs) are not dependent on the details of
 mapping database systems, which facilitates modularity with different
 database designs.

Currently:
 By using this control plane service interface and communicating with
 Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
 Egress Tunnel Routers (ETRs) are not dependent on the details of
 mapping database systems; this behavior facilitates modularity with
 different database designs.

b) Should "reduced" be used in this sentence, to parallel similar
text from RFC 6833?

Original:
 Since these devices implement the "edge" of the
 LISP Control-Plane infrastructure, connecting EID addressable nodes
 of a LISP site, it the implementation and operational complexity of
 the overall cost and effort of deploying LISP.

>From RFC 6833:
 Since these devices implement the "edge" of the LISP infrastructure,
 connect directly to LISP-capable Internet end sites, and comprise the
 bulk of LISP-speaking devices, reducing their implementation and
 operational complexity should also reduce the overall cost and effort
 of deploying LISP.

Perhaps ("it the" has been fixed, and "EID" is expanded a few lines
  earlier):
 Since these devices implement the "edge" of the
 LISP control plane infrastructure, connecting EID addressable nodes
 of a LISP site, the implementation and operational complexity of the
 overall cost and effort of deploying LISP is reduced. -->


5) <!-- [rfced] Section 1:  This sentence was difficult to parse.  As it
appears that some but not all data planes can or will use the LISP
control plane Mapping Service, we updated the text.  Please review;
if anything is incorrect, please provide clarifying text that
explains what can or will use the LISP control plane Mapping Service.

Original:
 This LISP Control-Plane Mapping Service can be used by many different
 encapsulation-based or translation-based Data-Planes which include
 but are not limited to the ones defined in LISP RFC 6830bis
 [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN
 [RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GRE [RFC2890], GTP
 [GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6)
 [RFC8402].

Currently:
 This LISP control plane Mapping Service can be used by many different
 encapsulation-based or translation-based data planes, including but
 not limited to those defined in LISP [RFC9300], the LISP Generic
 Protocol Extension (LISP-GPE) [RFC9305], Virtual eXtensible Local
 Area Networks (VXLANs) [RFC7348], VXLAN-GPE [NVO3-VXLAN-GPE], GRE
 [RFC2890], the GPRS Tunneling Protocol (GTP) [GTP-3GPP], Identifier-
 Locator Addressing (ILA) [INTAREA-ILA], and Segment Routing (SRv6)
 [RFC8402]. -->


6) <!-- [rfced] Section 1.1:  "LISP uses have been found and are being
used" read oddly.  We updated this sentence per author feedback
(email of 7 Sept. 2022) regarding the same sentence in companion
document RFC-to-be 9300.  Please let us know any concerns.

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.

Currently:
 While there are a number of approaches of
 interest for that problem, as LISP has been developed and refined, a
 large number of other uses for LISP have been found and are being
 implemented. -->


7) <!-- [rfced] Section 3:  To what does "which has an additional LISP
header prepended" refer - the Map-Request or the ECM?

Original:
 Encapsulated Map-Request:   A LISP Map-Request carried within an
    Encapsulated Control Message (ECM), which has an additional LISP
    header prepended. -->


8) <!-- [rfced] Section 3:  This sentence is a bit confusing as written.
Should "LISP Encapsulated (ECM) Map-Requests" be "LISP Encapsulated
Control Message (ECM) Map-Requests" per the definition of "ECM" in
Section 5.8?  We ask because we do not see the initial-capitalized
"LISP Encapsulated" used generally anywhere else in this document.

Original:
  Map-Resolver:   A network infrastructure component that accepts LISP
    Encapsulated (ECM) Map-Requests, typically from an ITR, and
    determines whether or not the destination IP address is part of
    the EID namespace; if it is not, a Negative Map-Reply is returned. -->


9) <!-- [rfced] Section 5:  Per all subsequent figures in this
document, we realigned the "ruler" numbers over the dashes ("-")
instead of the "plus" signs ("+").  Please let us know any
objections.

Original:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Version|  IHL  |Type of Service|          Total Length         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...

Currently:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Version|  IHL  |Type of Service|          Total Length         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
... -->


10) <!-- [rfced] The packet diagrams in Sections 5.2 and subsequent,
and Tables 1 through 3, do not have titles.  Please review, and
provide titles if desired. -->


11) <!-- [rfced] Section 5.1: We believe there may be a discrepancy in the 
Message name for code 6.  Specifically, should "DDT" be part of the Message?  
Please review and let us know if an update is needed. 

Current (document):
   | LISP Map-Referral                 | 6    | b'0110'          |

IANA:
6 	LISP DDT Map-Referral (TEMPORARY - registered 2017-04-19, extension registered 2022-04-13, expires 2023-04-19) 	[RFC8111]


IANA registry: https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-packet-types
-->


12) <!-- [rfced] Sections 5.4 and 5.5:  It appears that "more-specifics"
refers to more-specific entries or more-specific prefixes, depending
on context.  If the suggested text is not correct, please clarify
"more-specifics".

Original:
 Note that the reply count can be larger than the requested
 count, for instance when more-specifics are present.
...
 A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a
 record count of 3 to be returned with mapping records for EID-
 Prefixes 2001:db8:1::/48, 2001:db8:1:1::/64, 2001:db8:1:2::/64,
 filling out the /48 with more-specifics that exist in the mapping
 system.

Suggested:
 Note that the reply count can be larger than the requested
 count - for instance, when more-specific entries are present.
...
 A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a
 record count of 3 to be returned with mapping records for EID-
 Prefixes 2001:db8:1::/48, 2001:db8:1:1::/64, and 2001:db8:1:2::/64,
 filling out the /48 with more-specific prefixes that exist in the
 mapping system. -->


13) <!-- [rfced] Section 5.4:  We had trouble following this sentence.
Please clarify the meaning of "flagged that"; perhaps it means
"flagged so that"?

Original:
 (2) Send-Map-Request:  The Map-Cache entry is created and flagged
        that any packet matching this entry invokes sending a Map-
        Request. -->


14) <!-- [rfced] Section 5.4:  

[AD] Version 30 was approved; we were notified that version 31 was available 
earlier this year.  Please review and let us know if you approve the new text.
The update can easily be seen here: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-31.txt

Authors, we could not locate the indicated procedures in draft-ietf-lisp-6834bis.
Please clarify for readers where in draft-ietf-lisp-6834bis (perhaps a section 
number) this information can be found.

Original:
 Map-Version Number:  When this 12-bit value in an EID-record of a
    Map-Reply message is non-zero, follow the procedures in
    [I-D.ietf-lisp-6834bis] for details. -->


15) <!-- [rfced] Section 5.5:  We had trouble following this sentence.
Does "have" refer to the actions (in which case perhaps we could
update as suggested below) or to the ITR or PITR (in which case
"have" should be "has")?

Original:
 Negative Map-Replies
 convey special actions by the sender to the ITR or PITR that have
 solicited the Map-Reply.

Suggested (assuming that "have" refers to the actions):
 Negative Map-Replies
 convey to the ITR or PITR special actions by the sender that have
 solicited the Map-Reply. -->


16) <!-- [rfced] Section 5.5:  Please confirm that the comma after
"IP addresses chosen" is as intended; we see in RFC 6830 that there
wasn't a comma after this phrase.

Original:
 The source address of the Map-Reply is one of
 the local IP addresses chosen, to allow Unicast Reverse Path
 Forwarding (uRPF) checks to succeed in the upstream service provider.

If the comma is intentional, perhaps rephrasing would help:
 The source address of the Map-Reply is one of
 the chosen local IP addresses; this allows Unicast Reverse Path
 Forwarding (uRPF) checks to succeed in the upstream service provider. -->


17) <!-- [rfced] Section 5.6:  As it appears that a first-hop router will
sometimes, but not always, discover a dynamic EID, we updated this
sentence accordingly.  If this update is incorrect, please provide
clarifying text.

Original (the previous sentence is included for context):
 E: This is the Map-Register EID-notify bit.  This is used by a First-
    Hop-Router (FHR) which discovers a dynamic-EID.

Currently:
 This is used by a
    First-Hop Router (FHR) that discovers a dynamic EID. -->


18) <!-- [rfced] Section 5.7:  As it appears that "Map-Register section"
refers to Section 5.6 and "Map-Reply section" refers to Section 5.4,
we updated this sentence accordingly for ease of the reader (and to
provide helpful hyperlinks in the .html and .pdf output files).
If the updated citations are incorrect, please provide the correct
information.

Original:
 See the Map-Register section for field descriptions and the
 Map-Reply section for EID-record and RLOC-record descriptions.

Currently:
 See "Map-Register Message Format" (Section 5.6) for field
 descriptions and "Map-Reply Message Format" (Section 5.4) for EID-
 record and RLOC-record descriptions. -->


19) <!-- [rfced] Section 5.7:  This sentence was difficult to follow.
We updated it as noted below.  If this is incorrect, please clarify
"used, outside the scope of this specification".

Original ("can also used" has been fixed):
 The Map-Notify message can also used, outside the
 scope of this specification, in an unsolicited manner, such as is
 specified in [I-D.ietf-lisp-pubsub].

Currently:
 The Map-Notify message can also be used in an
 unsolicited manner.  This topic is out of scope for this document.
 See [LISP-PUBSUB] for details. -->


20) <!-- [rfced] Section 5.7:  We had trouble parsing this sentence; is
some punctuation missing?  If the suggested text is not correct,
please clarify "with the same nonce and the authentication data
validates".

Original ("the the" has been fixed):
 It is used to acknowledge the receipt of an unsolicited
 Map-Notify and, once the the authentication data is validated, allows
 for the sender to stop retransmitting a Map-Notify with the same
 nonce and the authentication data validates.

Suggested:
 It is used to acknowledge the receipt of an unsolicited
 Map-Notify and, once the authentication data is validated, allows 
 the sender to stop retransmitting a Map-Notify with the same nonce
 and (validated) authentication data. -->


21) <!-- [rfced] Section 5.8:  This sentence is difficult to follow, as
we only see one instance of the word "procedure" (used in the
singular) in draft-ietf-lisp-sec and could not find the relevant
information.  Please clarify for readers where in draft-ietf-lisp-sec
(perhaps a section number) this information can be found.

Original:
 S:    This is the Security bit.  When set to 1, the field following
       the 'Reserved' field will have the following Authentication
       Data format and follow the procedures from [I-D.ietf-lisp-sec]. -->


22) <!-- [rfced] Section 6.1:  Are the instances of "As a result"
necessary in both of these sentences?  Would either suggestion
below convey your intended meaning more concisely?

Original:
 As a result, an ETR will solicit Map-Requests to
 those sites to which it has been sending LISP encapsulated data
 packets for the last minute.  As a result, when an ETR is also acting
 as ITR, it will send an SMR to an ITR to which it has recently sent
 encapsulated data.

Suggestion #1:
 As a result, (1) an ETR will solicit Map-Requests to
 those sites to which it has been sending LISP-encapsulated data
 packets for the last minute and (2) when an ETR is also acting as an
 ITR, it will send an SMR to an ITR to which it has recently sent
 encapsulated data.

Suggestion #2:
 As a result, an ETR will solicit Map-Requests to
 those sites to which it has been sending LISP-encapsulated data
 packets for the last minute, and when an ETR is also acting as an
 ITR, it will send an SMR to an ITR to which it has recently sent
 encapsulated data. -->


23) <!-- [rfced] Section 8.4:  As Section 3 defines the Negative
Map-Reply as "A LISP Map-Reply that contains an empty Locator-Set"
and we see comparable wording in Section 8.3 ("the Map-Server returns
a Negative Map-Reply"), we changed the lone instance of "negative
LISP Map-Reply" to "Negative Map-Reply" here.  Please let us know any
concerns.

Original:
 If the Map-Resolver does not have the mapping entry and if it can
 determine that the EID is not in the mapping database (for example,
 if LISP-ALT is used, the Map-Resolver will have an ALT forwarding
 table that covers the full EID space), it immediately returns a
 negative LISP Map-Reply, with action code "Natively-Forward" and a
 15-minute TTL.

Currently:
 If the Map-Resolver does not have the mapping entry and if it can
 determine that the EID is not in the mapping database (for example,
 if LISP-ALT is used, the Map-Resolver will have an ALT forwarding
 table that covers the full EID space), it immediately returns a
 Negative Map-Reply with action code "Natively-Forward" and a
 15-minute TTL. -->


24) <!-- [rfced] Section 8.4.1:  As it appears that anycast RLOC
addresses will sometimes, but not always, be registered as part of
their RLOC-set to the mapping system, we updated this sentence
accordingly.  If this update is incorrect, please provide clarifying
text.

Original:
 ETRs MAY have anycast RLOC addresses which are registered as part of
 their RLOC-set to the mapping system.

Currently:
 ETRs MAY have anycast RLOC addresses that are registered as part of
 their RLOC-set to the mapping system. -->


25) <!-- [rfced] Section 9:  Does "which includes some form of shared
secret" refer to the configuration, the trust relationship, or the
mapping system?  If the suggested text is not correct, please clarify
the text.

Original:
 2.  The ETRs have a pre-configured trust relationship with the
     Mapping System, which includes some form of shared secret, and
     the Mapping System is aware of which EIDs an ETR can advertise.

Suggested:
 2.  The ETRs have a preconfigured trust relationship with the mapping
     system, including some form of shared secret.  The mapping
     system is aware of which EIDs an ETR can advertise. -->


26) <!-- [rfced] Section 9:  We changed "protection for" to "protection
against" in this sentence.  If this is incorrect, please clarify the
text.

Original:
 The Map-Register message includes
 protection for replay attacks by a man-in-the-middle.

Currently:
 The Map-Register message includes
 protection against replay attacks by a man-in-the-middle attacker. -->


27) <!-- [rfced] Section 9:  RFC 6347 has been obsoleted by RFC 9147.
Because this citation is general in nature and only the DTLS version
number has changed, we updated the RFC number.  Please let us know
any concerns.

Original:
 Examples of this are DTLS [RFC6347] or LISP-crypto
 [RFC8061].
...
 [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
            Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
            January 2012, <https://www.rfc-editor.org/info/rfc6347>.

Currently (We also used the lowercase "lisp-crypto" per RFC 8061):
 Examples of this are DTLS [RFC9147] or
 "lisp-crypto" [RFC8061].
...
 [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
            Datagram Transport Layer Security (DTLS) Protocol Version
            1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
            <https://www.rfc-editor.org/info/rfc9147>. -->


28) <!-- [rfced] Section 10:  To what does "which represents ..." refer
in this sentence - the RLOCs, the nodes, or the concept of the
identifiers binding to the RLOCs?  Please provide clarifying text.

Original:
 Such identifiers bind to the RLOCs of the nodes, which
 represents the topological location with respect to the specific LISP
 deployments. -->


29) <!-- [rfced] Section 11:  Please note that we updated the section
title and contents to account for RFC 6830.  For example, what is now
the first bullet item applies to RFC 6830 but not to RFC 6833.

Please review our updates carefully, and let us know if anything is
incorrect. -->


30) <!-- [rfced] Section 11:  We do not see 'Key-ID' or 'Key ID' in
RFC 6833, and we see 'Key ID' but not 'Key-ID' in RFC 6830.
We have changed 'Key-ID' and 'Algorithm-ID' to 'Key ID' and
'Algorithm ID', respectively.  Please let us know any concerns.

Original:
 o  The 16-bit Key-ID field of the Map-Register message has been split
    into a 8-bit Key-ID field and a 8-bit Algorithm-ID field.

Currently:
 *  The 16-bit 'Key ID' field of the Map-Register and Map-Notify
    messages as defined in [RFC6830] has been split into an 8-bit 'Key
    ID' field and an 8-bit 'Algorithm ID' field.  Note that this
    change also applies to the Map-Notify-Ack message defined by this
    document.  See Sections 5.6 and 5.7. -->


31) <!-- [rfced] Section 11:  Does "a different behavior" mean that the
nonce and the authentication data each behave differently?  If the
"Perhaps" text below is not correct, please clarify.

Original:
 o  The nonce and the authentication data in the Map-Register message
    have a different behaviour, see Section 5.6 for details.

Perhaps:
 *  The nonce and the authentication data in the Map-Register message
    each behave differently; see Section 5.6 for details. -->


32) <!-- [rfced] Section 11:  Does "that appear" refer to the EID-record
(in which case it should say "that appears") or the new action
values (although we couldn't find text that explains how these
action values appear in the four listed message types)?

Original:
 o  This document adds two new Action values that are in an EID-record
    that appear in Map-Reply, Map-Register, Map-Notify, and Map-
    Notify-Ack messages. -->


33) <!-- [rfced] Section 12:  We could not determine what the three
namespaces are and which sub-sections list them.  Will this
information be clear to readers?

Original:
 There are three namespaces (listed in the sub-sections below) in LISP
 that have been registered. -->


34) <!-- [rfced] This document says the the references to 6830 should be 
updated to point to this document and RFC 6830.  However, the IANA registry 
seems to only refer this document.  Please review and let us know if this 
document or the IANA site needs to be updated. 

Original: 
   IANA is                               
   requested to replace the [RFC6830] reference for this registry with                          
   the RFC number assigned to this document and [RFC6830].

IANA registry: https://www.iana.org/assignments/lisp-parameters
-->


35) <!-- [rfced] Section 12.3: The text describing the additions to the 
ACT values refers to both "Drop/Authentication-Failure" and "Drop/Auth-Failure".  
We see occurrences of both outside of the IANA Considerations as well.  Please 
review and let us know which is correct.  Note that IANA has registered value 5 
as "Drop/Authentication-Failure".  We will request that IANA update their 
registry as needed. 

See https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-act-value

Original: 
   This                                
   specification changes the name of ACT type 3 value from "Drop" to                            
   "Drop/No-Reason" as well as adding two new ACT values, the "Drop/
   Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5).  

   ... 

   | 5     | Drop/Auth-Failure  | Packet matching the     | RFC6833bis |                        
   |       |                    | Map-Cache entry is      |            |                        
   |       |                    | dropped beacuse the     |            |                        
   |       |                    | Map-Request for the     |            |                        
   |       |                    | target EID fails an     |            |                        
   |       |                    | authentication check    |            |                        
   |       |                    | by the xTR or the       |            |                        
   |       |                    | mapping system.         |            |      


In addition, note that we changed "target EWID" to "target-EID" for values 
4 and 5 in the table.  If this is incorrect, please define "EWID".
-->


36) <!-- [rfced] Section 12.3:  Does "LISP header flags field" mean
"LISP header 'Flags' field" as shown in the "OH" and "IH" portions
of the figure in Section 5.1 of draft-ietf-lisp-rfc6830bis (now
RFC-to-be 9300), or something else?  Please clarify.

Original:
 In addition, LISP has a number of flag fields and reserved fields,
 such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. -->


37) <!-- [rfced] Secton 12.4: It is not clear to us what "LISP Canonical 
Address Format (LCAF) is an 8-bit field" means. Please review and let us 
know if updates are needed. 

Original: 
   LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that                        
   defines LISP-specific encodings for AFI value 16387.
-->


38) <!-- [rfced] Section 12.4: Note that the IANA provided the following note 
regarding the "LISP Address Type Codes" registry:

   Closed the the LISP Address Type Codes Registry. We prefer to show this 
   registry as closed rather than completely remove it. That way if someone 
   does look up RFC6830, the registry shows that it used to be there.  Please
   let us know if this is acceptable to you.

We have updated the document accordingly.  Please let us know if any 
corrections are needed. 
-->


39) <!-- [rfced] Section 12.5: the text now indciates that the registry
reference has been updated to refer to this document to reflect what we 
see in the IANA registry.  Please let us know any concerns.

See https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-algorithm-id-numbers

Current text: 
   Per this document, IANA has renamed the registry to "LISP
   Algorithm ID Numbers" and listed this document as the registry
   reference.
-->


40) <!-- [rfced] Section 12.6: Did you intend for there to be a new 
registry group called "LISP Control Plane Header Bits" that included 
the defined the individual registries (i.e., should this registry appear 
on its own IANA page?)?  Currently, Map-Request messages, Map-Reply 
messages, Map-Register messages, Encapsulated Control Messages, 
EID-Records, and RLOC-Records each have a registry within "Locator/ID 
Separation Protocol (LISP) Parameters" registry.  Has this been set 
up correctly on https://www.iana.org/assignments/lisp-parameters? 

Original:
   The registry created should be named "LISP Control
   Plane Header Bits".  A sub-registry needs to be created per each                             
   message and EID-record.  The name of each sub-registry is indicated                          
   below, along with its format and allocation of bits defined in this                          
   document.
-->


41) <!-- [rfced] Section 12.6: Because these are all bits, does "Bit" 
need to be part of the description?  For example, should "Authoritative Bit" 
be just be "Authoritative".  If keeping "Bit" as part of the description, we 
will ask IANA to update the description for bit 17 from "Local xTR" to 
"Local xTR Bit".

Note that this question applies to all of the LISP Control Plane Header 
Bits registries. 
-->


42) <!-- [rfced] Should the description for value 6 include Bit? 

Current:
   | I         | map-register-I | 6            | xTR-ID present flag  |

IANA registry: 
https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-parameters-lisp-control-plane-header-bits-map-register
-->


43) <!-- [rfced] Section 12.6: Please confirm that bit placement 19 is 
correct for both p and R:

Current:

    | p         | rloc-record-p | 19           | RLOC-Probe Reply Bit |
    | R         | rloc-record-R | 19           | RLOC Reachable Bit   |


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Unused Flags     |L|p|R|           Loc-AFI             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IANA registry:
https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-parameters-lisp-control-plane-header-bits-rloc-record
-->


44) <!-- [rfced] The following references are not cited in the text. 
Please let us know where they should be cited or if these
references should be deleted from the References section.

 [RFC2104]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

 [RFC6234]    Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. -->


45) <!-- [rfced] We have updated the IANA "Address Family ..." listing
per the IANA page and per their guidelines for IANA URLs.  Please let
us know any concerns.

Original:
 [AFI]      "Address Family Identifier (AFIs)", ADDRESS FAMILY
            NUMBERS http://www.iana.org/assignments/address-family-
            numbers/address-family-numbers.xhtml?, February 2007.

Currently:
 [AFN]      IANA, "Address Family Numbers",
            <http://www.iana.org/assignments/address-family-numbers/>. -->


46) <!-- [rfced] Informative References:  It appears that newer versions
of [GTP-3GPP] might be available, per the "Versions" tab on
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=1699>.  Please let us know
if this listing should be updated.

Original:
 [GTP-3GPP]
            "General Packet Radio System (GPRS) Tunnelling Protocol
            User Plane (GTPv1-U)", TS.29.281
            https://portal.3gpp.org/desktopmodules/Specifications/
            SpecificationDetails.aspx?specificationId=1699, January
            2015. -->


47) <!-- [rfced] Acknowledgments:  Since Fabio Maino is an author of this
document, should Fabio also be listed twice in this section?  We
don't see any of the other current authors listed.

Original:
 The original authors would like to thank Greg Schudel, Darrel Lewis,
 John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper
 Skriver, Fabio Maino, and members of the [e-mail] mailing list
 for their feedback and helpful suggestions.
...
 The current authors would like to give a sincere thank you to the
 people who help put LISP on standards track in the IETF.  They
 include Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino,
... -->


48) <!-- [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 "natively" should be updated. -->


49) <!-- [rfced] Please let us know if any changes are needed for the
following:

a) The following terms were used inconsistently in this document.
We chose to use the latter forms.  Please let us know any objections.

 target EID (1 instance in Section 12.3) /
   target-EID (2 instances)

 policy-denied (1 instance in Section 12.3) /
   policy denied (2 instances)

b) The following terms appear to be used inconsistently in this
document.  Please let us know which form is preferred.

 Drop/Authentication-Failure / Drop/Auth-Failure

 "first-hop" ALT-Router (Section 4) / First-Hop Router (FHR)
    (Please note that (1) we also see '"last-hop" ALT-Router' in
     Section 4 and (2) the "E: " definition in Section 5.6 is the
     only place in this document, and in this cluster of documents,
     where the abbreviation "FHR" is used.)

 ITR-RLOC-Address / ITR-RLOC Address
   We see
     2 instances of the former and 6 instances of the latter in this
       document
     2 instances of the former and 5 instances of the latter in RFC 6830
   and so cannot determine which form is correct. -->


Thank you.

RFC Editor



On Sep 15, 2022, at 10:33 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2022/09/15

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/rfc9301.xml
   https://www.rfc-editor.org/authors/rfc9301.html
   https://www.rfc-editor.org/authors/rfc9301.pdf
   https://www.rfc-editor.org/authors/rfc9301.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9301-diff.html
   https://www.rfc-editor.org/authors/rfc9301-rfcdiff.html (side by side)

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9301-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/rfc9301.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates 
only: 
   https://www.rfc-editor.org/authors/rfc9301.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9301

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9301 (draft-ietf-lisp-rfc6833bis-31)

Title            : Locator/ID Separation Protocol (LISP) Control-Plane
Author(s)        : D. Farinacci, F. Maino, V. Fuller, A. Cabellos (Ed.)
WG Chair(s)      : Joel M. Halpern, Luigi Iannone
Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston