Re: [lisp] AD Review of draft-ietf-lisp-nexagon-19

[Joel Halpern <[e-mail]>]

THere are a number of points, not all of which I am prepared to comment 
on at this time.

It is clear that this document is on the edge of the charter for the 
LISP WG.  It does not change LISP, but rather explains how to use LISP 
to achieve a goal.  Of course, if it were in some other WG it would 
still need LISP review, so keeping it here makes snse.  Particular since 
it is not really about ipwave stuff.

The other important note is that way back when Sharon first brought this 
work forward, I went to various AD, chairs, and influential participants 
and tried to get a review on the geoloc / geopriv dimensions so that we 
could properly consider them.  I could one review, which brought up only 
a few points (which Sharon then clarified in the draft.)  It was very 
clear that there was no interest from that community in looking closely 
and engaging on this work.

Yours,

Joel

On 6/3/2022 11:08 AM, Alvaro Retana wrote:
> Dear authors/shepherd/chairs:
>
> First of all, this is an exciting application! Thank you for the work
> you've put into it so far!
>
>
> However, I am concerned about this document as a product of the WG and
> potential IETF RFC. To summarize, it goes beyond describing how LISP
> can be used to *trying* to specify a complete system, but it falls
> short in attempting to do too many things at once. As a result, the
> descriptions are confusing, the specifications are incomplete, the
> text is inconsistent, etc.
>
> I put detailed comments inline (see below), but I first want to list
> high-level issues:
>
> (1) The operation of LISP in the Nexagon system is straightforward; the most
>      "complex" part is using the RTRs, but even that is as specified in
>      rfc6830bis. However, the document combines the use of LISP with H3-related
>      concepts and even application-layer operations. The result is a confusing
>      description where the reader has to make a lot of assumptions because the
>      terminology is not adequately referenced or used inconsistently. There is
>      no Normative reference to the H3 work, and new terms and assumptions are
>      constantly introduced. The straightforward LISP-related description is
>      unnecessarily made complex by trying to explain the domain-specific
>      operation at the same time.
>
>      It caught my attention that only rfc6830bis is used as a reference. It is
>      clear that only the LISP data plane (and not the control plane) is used
>      between the MobilityClients and the EdgeRTRs, but it looks like the control
>      plane is used elsewhere. The point of which parts of LISP are used has to
>      be explicit.
>
>
> (2) The document attempts to document/specify the operation of the whole system
>      (beyond the use of LISP). As a result, the document includes assumptions
>      and incomplete technology specifications outside the WG's control: H3-
>      related deployment assumptions, use of DNS/AAA (with unspecified
>      extensions), sharing of reputation information between components, etc.
>      Also, LISP-related assumptions are made without proper specification,
>      including the encryption of the data plane, the use of MLDv2 in rfc8378,
>      etc.
>
>      As mentioned in the detailed comments below, I find all these topics
>      underspecified.
>
>
> (3) Was this work discussed in the ipwave (IP Wireless Access in Vehicular
>      Environments) WG? They are chartered for "use-cases where IP is well-
>      suited...to establish direct and secure connectivity between a vehicle and
>      other vehicles or stationary systems."  The fit may not be exact but
>      related. I saw the discussion on the list [1] and agree that the goals are
>      different; nonetheless, it would have been good to share.
>
>      ipwave's Problem Statement and Use Cases document [2] may be a good
>      reference for some use cases and other references -- leaving this document
>      to highlight the differences. Note that LISP is mentioned as a possibility,
>      and the H3-LISP solution may generally fit the "Vehicular Network
>      Architecture for V2I and V2V" from Figure 1.
>
>      [1] https://mailarchive.ietf.org/arch/msg/its/WXt2d-FefiZ_iOcBsLgATKLDvVw
>      [2] https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking
>
>
> (4) [For the Chairs.] How does this work fit into the WG's charter? Even if the
>      WG is not chartered to produce use-case-type documents, we may be able to
>      convince the IESG that this is a draft worth publishing as an IETF RFC (if
>      the topic comes up). However, as mentioned before, the document goes
>      significantly beyond a LISP use case.
>
>
> (5) [For the Shepherd/Chairs.]  There are 8 authors listed on the front page.
>      The recommended number is 5 (rfc7322). Please work with the authors to
>      reduce this number - others can be mentioned as Contributors or in the
>      acknowledgment section. Otherwise, please provide a strong justification.
>
>
>
> If this document progresses as the product of the WG, its scope will
> need to be significantly narrower. So, I'm inclined to return the
> document to the WG.
>
> I suspect we might need to talk live about my comments and
> expectations. Feel free to find some time in my calendar:
> https://doodle.com/mm/alvaroretana/book-a-time
>
> Thanks!
>
> Alvaro.
>
>
>
>
>
> [Line numbers from idnits.]
>
> 1	LISP Working Group                                             S. Barkai
> 2	Internet-Draft                                         B. Fernandez-Ruiz
> 3	Intended status: Informational                                  R. Tamir
> 4	Expires: January 1, 2022                                      Nexar Inc.
> 5	                                                      A. Rodriguez-Natal
> 6	                                                                F. Maino
> 7	                                                           Cisco Systems
> 8	                                                    A. Cabellos-Aparicio
> 9	                                                   J. Paillisse Vilanova
> 10	                                       Technical University of Catalonia
> 11	                                                            D. Farinacci
> 12	                                                             lispers.net
>
> [major] The recommended number of authors in the front page is 5.
> Please work with the Shepherd/Chairs to reduce the current list.
>
>
>
> ...
> 15	        Network-Hexagons: H3-LISP GeoState & Mobility Network
> 16	                    draft-ietf-lisp-nexagon-19
>
> [minor] Some places use "H3LISP" (instead of "H3-LISP").  Please be consistent.
>
>
>
> 18	Abstract
>
> 20	   This document specifies the use of H3 and LISP for Geolocation
> 21	   Services. Geolocation Services utilize geospatial data for:
> 22	   Fresh HDMaps, Intelligent Driving, Cruise and Parking assists.
> 23	   Geospatial utilization is delivered using in-network compute for
> 24	   brokered verification, curation, and localization of data, using:
>
> 26	   - EID addressable geospatial-tiles abstraction of road-segments.
> 27	   - EID Interface for detections and uploads to the tile-contexts.
> 28	   - EID Routing-Sharing hazards, blockages, parking, road-inventory.
> 29	   - EID themed multicast channels per tile to subscribed clients.
>
> [minor] Please expand terms on first use: H3, LISP, HDMaps, ...
>
>
> [minor] s/specifies/describes
> This is intended to be an Informational document.
>
>
> [major] H3 is mentioned here and concepts are used throughout the
> document.  However, there is no Normative reference offered for the
> reader to understand the background.
>
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
>
>
> [major] "...LISP for Geolocation Services"
>
> The information carried between the clients/servers is independent of
> LISP.  And how the EIDs are assigned to the clients are also not in
> scope of LISP.  IOW, the system uses geolocation, but LISP itself
> doesn't.  I'm making this comment because the use/transmission of
> geolocation is going to require significant justification and privacy
> considerations.  See rfc6973.
>
>
> [major] The Abstract should provide a glimpse into what this document is about.
>
> None of the services listed are even mentioned later in the document.
> The use of "in-network compute for brokered verification..." is also
> not covered anywhere.
>
>
> [minor] Expand EID on first use.
>
>
> [major] EID is an Endpoint ID.  I can imagine something that is "EID
> addressable", but I'm having a very hard time associating the other
> descriptions.  The list sounds like great marketing... <sigh>
>
>
>
> ...
> 76	1.  Introduction
>
> [] This section starts with a summary of LISP, but quickly goes into
> an application-specific description that may not be needed...and may
> raise more questions than it answers.  Some of the text I would even
> label as "great for marketing"... :-(
>
>
>
> 78	  The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6830bis]
> 79	  splits IP addresses in two different namespaces, Endpoint Identifiers
> 80	  (EIDs) and Routing Locators (RLOCs). LISP uses map-and-encap approach
> 81	  (1) a Mapping System (distributed database) that stores and resolves
> 82	  EID-RLOC mappings and on (2) LISP tunnel routers (xTRs) encapsulating
> 83	   and decapsulating data packets based on content of those mappings.
>
> [minor] s/uses map-and-encap approach (1)/uses a map-and-encap
> approach that relies on (1)
>
>
>
> 85	  H3 (https://h3geo.org)is a geospatial indexing system using hexagonal
> 86	  grid that can be subdivided into finer and finer hexagonal grids,
> 87	  combining the benefits of a hexagonal grid with hierarchy.
> 88	  H3 supports sixteen resolutions. Each finer resolution has cells with
> 89	  1/7 the area of the coarser resolution. Hexagons cannot be perfectly
> 90	  subdivided into seven hexagons, so the finer cells are approximately
> 91	  contained within a parent cell. Each cell is identified by 64bit HID.
>
> [major] Pointing to the H3 website is not enough.  A stable reference
> to where the technology is defined is needed.  References should be in
> the References section.
>
>
> [nit] s/(https://h3geo.org)is/(https://h3geo.org) is
>
>
> [nit] s/by 64bit/by a 64-bit
>
> Please be consistent on how 64-bit is written.  Besides 64bit and
> 64-bit, the document also uses "64 bit".
>
>
> [minor] Expand HID.
>
>
>
> 93	  The Berkeley Deep Drive (BDD) (https://bdd-data.berkeley.edu) Industry
> 94	  Consortium investigates computer vision technologies for automotive
> 95	  applications and for taxonomy of published automotive classification.
>
> [major] The next paragraph mentions that "these standards are
> combined".  Does that include BDD standards?  If so, then we'll need a
> stable reference to where that is specified.
>
>
> [major] There's a reference later to a "BDD state"...which I guess is
> related to the registries defined in the IANA section.  Am I guessing
> correctly?  A quick scan of the BDD site didn't give me an indication
> of how they would use the information in the registries.   ??
>
>
>
> 97	  These standards are combined to create an in-network state reflecting
> 98	  condition of each hexagonal tile (~1sqm) in every road. The mobility
> 99	  H3-LISP network maps & encapsulates traffic between client endpoint
> 100	  identifiers (EID) and addressable geospatial contexts (H3-HID=>EID).
>
> [nit] s/condition/the condition
>
>
> [nit] s/mobility H3-LISP network/H3-LISP mobility network
>
>
> [minor] Figure 2 uses "H3-LISP Mobility Network" to identify the
> network between the EdgeRTRs.  The description above seems to cover
> much more, from the MobilityClients to the H3Services.   Please use
> terminology consistently.
>
>
> [?] I'm not sure what "H3-HID=>EID" means.
>
>
>
> 102	  The H3-LISP mobility network bridges timing and location gaps between
> 103	  production and consumption of information by clients of mobility data:
> 104	   o information producers: vision, sensory, LIADR, AI applications
> 105	   o information consumers: driving-apps, map-apps, command & control
>
> [] "bridges timing and location gaps"
>
> Wow!  Great marketing!
>
> Please focus on the technical description.  Note that the "H3-LISP
> mobility network" transports data -- this reference seems to be
> talking about the overall system.  Again, please define terms and use
> them consistently.  This is one of the cases where the LISP-specific
> use (transport data) and the domain-specific applicaiton (H3) are
> combined into an inconsistent application.
>
>
>
> 107	  This is achieved by putting the physical world on a shared addressable
> 108	  geospatial context-grid of road-segments represented at the edge.
> 109	  Geospatial state sharing is done using this brokered-network of tile
> 110	  representation, an indirection which solves key issues in v2v
> 111	  information sharing. For example multiple vision perspectives, geo
> 112	  privacy, cyber security. These challenges arise when clients are
> 113	  asked to communicate directly when they do not really need to.
> 114	  A communication pattern which causes complexity and exposures.
>
> [-] "putting the physical world"
>
> I'm sure this can be made more specific.  Perhaps by pointing at the
> H3 specifications.
>
>
> [minor] Expand v2v on first use.  In most literature I see this as "V2V".
>
>
> [major] "solves key issues...geo privacy, cyber security."
>
> This is a bold claim and wide claim -- I hope the Security
> Considerations back it up.  Perhaps, instead of making blanket claims,
> focus on the advantages of this solution -- not with respect to others
> (because you'll need to back that up too).
>
>
>
> 116	  In non brokered v2v models, for a situation observable by some end
> 117	  points, it is unclear if the need-to-know end-points will receive:
> 118	  i. consistent, ii. conflicting, iii. multiple, or iv. no indications.
> 119	  As an example, when a vehicle experiences a sudden highway slow-down,
> 120	  sees brake lights or senses an accelerometer slowdown, there is no
> 121	  clear way for it to share this data with vehicles 20-30sec away.
> 122	  Or, when a vehicle crosses an intersection, observing opposite-lane
> 123	  obstruction such as: construction, double-park, commercial loading,
> 124	  garbage truck, or stopped school-bus.. there is no clear way for it
> 125	  to alert approachers from another direction as it drives away.
>
> [nit] s/or stopped school-bus../or a stopped school-bus,
>
>
> [major] "unclear if the need-to-know end-points will receive"
>
> I didn't see any text about how this system, or LISP, can guarantee
> that either.  Specifically, beyond general mapping, there's no
> indication in LISP of the characteristics (need-to-know, or not) of
> the receivers.
>
>
>
> 127	  Geospatial context indirection helps communicate advanced vision and
> 128	  radar annotations. As these are evolving technologies, relaying road
> 129	  enumerations using peer-to-peer poses interoperability challenges.
>
> [-] Again, focus on this solution, not others.  "communicate advanced
> vision and radar annotations"
>
>
>
> 131	  These peer-to-peer limitations are inherent yet unnecessary, in most
> 132	  situations vehicles are not really proper peers. They happen to be in
> 133	  the same place at the same time. H3-LISP mobility network solves the
> 134	  limitations of direct vehicle-to-vehicle communication by brokering
> 135	  exchanges using addressable geospatial context. Bridging timing,
> 136	  security, privacy, and interoperability gaps between endpoints.
> 137	  Brokering is achieved by clients communicating via context,
> 138	  addressable tiles which aggregated and relay data using H3 EIDs.
>
> [-] "peer-to-peer limitations"
>
> Again, focus on this solution, not others.
>
>
> [-] "Bridging timing, security, privacy, and interoperability gaps
> between endpoints."   ...
>
>
> [major] From a LISP point-of-view, are "H3 EIDs" different than EIDs?
> This was used above: "H3-HID=>EID" -- what is the relationship?  The
> use of the terminology is not consistent.
>
>
>
> ...
> 146	  To summarize the H3-LISP mobility solution principles are:
>
> 148	  (1) Problem Partition: 64bit H3.r15 ID road-tiles for detections
>
> [major] "H3.r15 ID" -- what is this?  We need a Normative reference.
>
>
> [minor] For "detections" of what?
>
>
>
> 149	  (2) Enumerated State: 64bit values of tile condition representation
>
> [major] "tile condition" is not mentioned anywhere else.  What is it?
> If it is a "solution principle" it must be important.
>
>
>
> 150	  (3) Grouping: EID per H3.r9 geo-context for its H3.r15 road-tiles
>
> [major] "H3.r9 geo-context for its H3.r15 road-tiles"
>
> The H3-related terminology needs to be defined/explained somewhere.  A
> Normative reference would be ideal.
>
>
>
> 151	  (4) Group Channels: H3.r9 EIDs mcast address for geo-state updates
>
> [minor] Please use "multicast", or expand the abbreviation on first use.
>
>
> [minor] I'm not sure about this phrase: "H3.r9 EIDs mcast address".
> It sounds as if the EIDs send multicast, but the EID is just an ID and
> then there's the "address" part.   Please reword.
>
>
>
> 152	  (5) Scale: EID addressable contexts distributed on edge servers
> 153	  (6) Overlay: tunneled-network routes the mobility-network traffic
>
> [nit] "mobility-network" is used here, but in other parts "Mobility
> Network" is used instead, both capitalized and not.  Please be
> consistent.
>
>
>
> 154	  (7) Signal-free: overlay is used to map-register for mcast channels
>
> [major] "Signal-free"
>
> If there is a registration, it doesn't sound like "signal free".
> Also, are you referring to a Map-Register message or something else?
> It seems a little strange that "map-register" is used as a verb.
>
>
>
> 155	  (8) Layering: overlay tunnels used between clients and geo-contexts
>
> [nit] "Overlay" and "Layering" sound redundant.
>
>
> [minor] "between clients and geo-contexts"
>
> Terminology.  "geo-contexts" is used above as "H3.r9 geo-context".
> Are these the "edge servers" mentioned above?  There are multiple ways
> to apparently refer to the same things. :-(
>
>
>
> 156	  (9) Access: client/server XTRs tunnel traffic to-from the LISP RTRs
>
> [minor] Do these two last bullets (8 and 9) talk about the same
> tunnels?  Are the clients the xTRs?  There seems to be some
> terminology overlap/overloading of terminology.
>
>
>
> 157	  (10) Control: RTRs register-resolve H3 EIDs and mcast subscriptions
>
> [minor] "register-resolve" is used as a verb, but I'm guessing that
> you're implying the use of Map-Register/MapRequest messages.
>
>
>
> 159	  |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
> 160	  |                        H3 Hexagon ID Key                      |
> 161	  |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
> 162	  |                      H3 Hexagon State-Value                   |
> 163	  |---------------------------------------------------------------|
>
> 165	  Figure 1: 64 bit H3 ID, 64 bit compiled state value
>
> [major] Where is this specified?  The packet formats in §5 are different.
>
>
>
> 167	  Each H3.r9 hexagon is an EID context with corresponding H3 hexagon ID.
> 168	  Bound to that context is a LISP xTR specified to encapsulate packets
> 169	  to and from EID context and LISP Edge. Edge RTRs are used to re
> 170	  -tunnel packets from clients to services. Each service is also a
> 171	  multicast source for updating clients on the state of the H3.r15
> 172	  tiles, aggregated by the EID addressable geospatial context.
>
> [major] What is an "EID context"?  It is used here twice, but not defined.
>
>
> [-] Peeking ahead to Figure 2, I am able to guess what you mean in the
> descriptions...but the reader shouldn't be expected to guess.
>
>
>
> 174	2. Definition of Terms
>
> 176	  H3ServiceEID: Is an addressable aggregation of H3.r15 tiles.
> 177	     It functions as geospatial data association context for filtering,
> 178	     verifying, localizing, and propagating vehicles data uploads.
> 179	     It is a designated destination for physical world annotations,
> 180	     and an (s,g) source of multicast themed update channels.
> 181	     H3ServiceEID is itself an H3 hexagon, large enough to provide
> 182	     geo-spatial compute context, but not too large as to over-burden
> 183	     subscribers with too much information. For Mobility Network it is
> 184	     H3.r9. It has a light-weight LISP protocol stack to tunnel packets
> 185	     aka ServerXTR. The EID is an IPv6 EID that contains the H3 64-bit
> 186	     address numbering scheme.
>
> [major] "addressable aggregation of H3.r15 tiles"
>
> But "H3.r15 tiles" are not defined anywhere.
>
>
> [?] "designated destination for physical world annotations"   No idea
> what this means in the context of lisp. :-(
>
>
> [nit] s/(s,g)/(S,G)/g
>
>
> [major] "(s,g) source of multicast themed update channels"
>
> I guess you mean that the EID serves as the source for group-specific
> multicast traffic.  The use of "(s,g) source" and "multicast themed"
> doesn't make that guess straight forward.  BTW, "updates" of what/to
> what?
>
>
> [major] "H3.r9" are not defined.
>
>
> [major] "H3 hexagon" is not defined anywhere.
>
>
> [major] I started reading this definition (and making comments --
> above) thinking that the "H3ServiceEID" is an EID.  But the text takes
> me through "an addressable aggregation of H3.r15 tiles", "an H3
> hexagon" (of just the right size), "H3.r9"...to something with a
> "light-weight LISP protocol stack"...and finally back to "IPv6 EID".
> Needless to say, this definition is confusing.
>
>
> [major] "IPv6 EID that contains the H3 64-bit address numbering scheme"
>
> How?  I guess the lower 64 bits...but that is just a guess.
>
>
>
> 188	  ServerXTR: Is a data-plane only LISP protocol stack implementation, it
> 189	     co-exists with H3ServiceEID process. When the server roams, the xTR
> 190	     is with it. ServerXTR encaps & decaps packets to/from EdgeRTRs.
>
> [major] "data-plane only LISP protocol stack implementation"
>
> How are mappings learned by the servers?
>
>
> [major] Now the H3ServiceEID is a "process"...
>
>
> [?] If I understand correctly, the ServerXTR is an xTR on a server...right?
>
>
> [major] "When the server roams, the xTR is with it."
>
> So...there's no xTR function if the server is not roaming?  I assume
> that that the services in this tile need the xTR functionality all the
> time.  Why isn't that the case?  Or am I reading too much into the
> statement and it is being used just to make the point that the xTR
> function is attached to the server?
>
>
> [minor] I realize that "encaps & decaps" are common terms, but please
> expand on firs use.  BTW, "encaps & decaps" is also used later as
> "encaps/decaps" -- please use only one form.
>
>
>
> 192	  MobilityClient: Is a roaming application that may be a part of an
> 193	     automobile, part of a navigation application, part of municipal,
> 194	     state or federal government command and control application, or a
> 195	     street view consumer application. It has a light-weight LISP
> 196	     data-plane stack to tunnel packets, aka ClientXTR.
>
> [major] "MobilityClient...aka ClientXTR."
>
> Is a MobilityClient an xTR?
>
> Maybe describe in general lisp terms: xTR, EID, and then introduce the
> function (server, client) by illustrating in a figure...  Is this a
> use case or a specification??
>
> Also confusing...  Can there be more than one MobilityClient in a
> vehicle?  For example, in the navigation app and maybe a different
> system on the car?  If so, will each MobileClient have a separate xTR
> function?
>
>
>
> 198	  MobilityClient EID: Is the IPv6 EID used by the Mobility Clients
> 199	     to source packets. The destination of such packets are only
> 200	     H3ServiceEIDs. The EID format is opaque and is assigned as
> 201	     part of the MobilityClient mobility-network authorization.
>
> [minor] Just an observation that "Mobility Client", "MobilityClient"
> (without "EID" attached to it), and even "Mobility-Client" are used
> throughout the document.  Please take a look to assure consistency.
>
>
> [minor] Also, "MobilityClient EID" and "MobilityClientEID" are used.
>
>
> [?] "EID format is opaque"
>
> It's an IPv6 address, right?  Is there anything relevant to lisp about
> the format?
>
>
> [major] "EID...is assigned as part of the MobilityClient
> mobility-network authorization."
>
> Where is the "mobility-network authorization" specified?  I later read
> about the AAA mechanism...maybe put a forward reference to that and be
> consistent in the names -- this is the only time in the document that
> this name is used.
>
>
> [?] rfc6830bis uses terms like client-side and server-side to refer to
> specific things.  Are those terms related to the terminology used
> here?
>
>
>
> 203	  ClientXTR: Is a data-plane only LISP protocol stack implementation
> 204	     co-located with the Mobility Client application. It encaps/
> 205	     decaps packets from/to applications to/from EdgeRTRs.
>
> [minor] "encaps/decaps" is written above as "encaps & decaps" --
> please use only one form.
>
>
>
> 207	  EdgeRTR: Is the core scale and structure of the LISP mobility network.
> 208	     EdgeRTRs proxy H3ServiceEIDs and MobilityClient H3ServiceEID mcast
> 209	     registration. EdgeRTRs aggregate MobilityClients/H3Services using
> 210	     tunnels to facilitate hosting-providers and mobile-providers for
> 211	     accessing the mobility network.  EdgeRTRs decapsulate packets
> 212	     from ClientXTRs, ServerXTRs and re-encaps packets to the clients
> 213	     and servers tunnels. EdgeRTRs glean H3ServiceEIDs/MobilityClient
> 214	     EIDs when they decapsulates packets. EdgeRTRs store H3ServiceEIDs
> 215	     and RLOCs of where the H3ServiceEID is currently reachable from
> 216	     the map-cache. These mappings are registered to the LISP mapping.
> 217	     These mappings may be provisioned when H3Services are assigned
> 218	     EdgeRTRs. EdgeRTRs do not register MobilityClients' EIDs.
> 219	     Enterprises may provide their own EdgeRTRs to protect geo-privacy.
>
> [minor] "Is the core scale and structure of the LISP mobility network."
>
> As part of a definition that doesn't tell me much...
>
>
> [minor] "EdgeRTRs proxy H3ServiceEIDs and MobilityClient H3ServiceEID"
>
> Did you mean "MobilityClient EID"?  Or maybe "MobilityClientEID"...
>
>
> [major] "proxy...mcast registration"
>
> I found something about registration (as related to multicast) in
> rfc8378.  Is that what you mean?  Please add a reference.
>
> But I found nothing about RTRs acting as a proxy.  ??
>
>
> [major] I'm assuming that the "LISP mapping" is a reference to
> rfc6833bis, right?  Please add a Normative reference.
>
>
> [-]
>
>     EdgeRTRs decapsulate packets from ClientXTRs, ServerXTRs and
>     re-encaps packets to the clients and servers tunnels. EdgeRTRs
>     glean H3ServiceEIDs/MobilityClient EIDs when they decapsulates
>     packets. EdgeRTRs store H3ServiceEIDs and RLOCs of where the
>     H3ServiceEID is currently reachable from the map-cache. These
>     mappings are registered to the LISP mapping.
>
> This description is a paraphrasing of what an RTR does, but it sounds
> inaccurate and loose...
>
>
> [major] "Enterprises may provide their own EdgeRTRs to protect geo-privacy."
>
> I put some comments about security and privacy in the Security
> Considerations section below.  In general, most of the related
> concerns should have been addressed in the base specs.
>
> In this case, EdgeRTRs are present on both sides of the mobility
> network.  Are you referring to enterprises providing EdgeRTRs for both
> sides?  What are the effects of a partial deployment?
>
>
>
> 221	                          ___                                  ___
> 222	   H3ServiceEIDs   ___  /     \           H3ServiceEIDs ___  /     \
> 223	            ___  /     | H3.r9 |                 ___  /     | H3.r9 |
> 224	          /     | H3.r9 \ ___ /                /     | H3.r9 \ ___ /
> 225	         | H3.r9 \ ___ /  sXTR                | H3.r9 \ ___ /  sXTR
> 226	          \ ___ /  sXTR    |                   \ ___ /  sXTR     |
> 227	            sXTR    |      |                     sXTR     |      |
> 228	             |      |      |                      |       |      |
> 229	             |      |      |                      |       |      |
> 230	             + -  - + - - EdgeRTR           EdgeRTR - + - + - -  +
> 231	                             ||  (   (   ((  ||
> 232	                          (                        )
> 233	                        (      Network Hexagons      )
> 234	                      (            H3-LISP              )
> 235	                        (      Mobility Network       )
> 236	                          ((                        )
> 237	                            ||  ((   (())   ()  ||
> 238	                            ||                  ||
> 239	                = = = = = = =                     = = = = = = =
> 240	               ||                                             ||
> 241	            EdgeRTR                                         EdgeRTR
> 242	           ..    ..                                      ..      ..
> 243	          ..       ..                                  ..          ..
> 244	  ((((|))))    ((((|))))                         ((((|))))    ((((|))))
> 245	     /|\    RAN   /|\                               /|\    RAN   /|\
> 246	      ..                                                          ..
> 247	      ..                                                          ..
> 248	      ..          Road tiled by 1 sqm H3.r15 ID-Ed Geo-States     ..
> 249	      ..                                                          ..
> 250	      ..                  ___    ___    ___                       ..
> 251	      ..  ............. /     \/     \/     \ << cXTR::MobilityClientB
> 252	      .. - - - - - - -  H3.r15  H3.r15 H3.r15 - - - - - - - - - - - -
> 253	      MobilityClientA::cXTR >> \ ___ /\ ___ / .......................
>
> 255	  Figure 2: H3.r15 state representation, H3.r9 state aggregation
>
> [major] H3.r15 and H3.r9 are not properly defined in this document to
> be able to interpret what the state may mean.
>
>
>
> 257	Figure 2 above describes the following entities:
> 258	  - MobilityClientA sees MobilityClientB future, and, vice versa
>
> [major] They see the future?  I'm sure there's a different
> interpretation, but I'm not sure what.
>
> Looking at the figure for a long time I finally saw the arrows (">>"
> and "<<"), which I guess indicate directional movement.  The one line
> description is not enough for the reader to decipher what you mean.
> This is one place where more context on H3 would be useful.
>
>
>
> 259	  - Clients: share information using addressable state routed by LISP
>
> [nit] s/Clients/MobilityClients (?)
> I know that this doesn't make the phrase fit in one line, but please
> use consistent terminology.
>
>
> [major] "addressable state routed by LISP"
>
> LISP doesn't route.  In this part of the network just the LISP data
> plane is used.
>
>
>
> 260	  - ClientXTR (cXTR): encapsulates over access network to EdgeRTR
>
> [major] It also decapsulates traffic in the opposite direction.
> Consider describing the "life of a packet" in each direction.
>
>
>
> 261	  - ServerXTR (sXTR): encapsulates over cloud network to EdgeRTR
>
> [major] Same comment about decapsulation.
>
>
> [minor] The "cloud network" is not shown in the figure.  The fact that
> the services may be provided in the cloud is probably not relevant to
> the figure, but may be relevant to the description of the system.
>
>
>
> 262	  - H3-LISP Mobility: overlay which spans cXTRs to sXTRs
>
> [major] I assume that you're referring to the "H3-LISP Mobility
> Network".  If so, it connects the EdgeRTRs, not the cXTRs and sXTRs.
> At this point the traffic has been re-encapsulated.
>
>
>
> 263	  - Uploads: routed to appropriate tile by the LISP network
>
> [?] I don't see "uploads" in the picture.  Maybe this is related to
> the "life of a packet"...or the application itself.
>
>
> [major] "routed to appropriate tile by the LISP network"
>
> Again, LISP is not routing, just delivering the information to the
> destination address -- IOW, there's no knowledge of the "appropriate
> tile" -- and no explanation in the document about the relationship
> between sourced data and "appropriate" destinations.
>
>
>
> 264	  - EdgeRTRs: perform multicast replication to edges and then cXTRs
>
> [-] I guess "uploads" referred to the MobilityClient to server
> direction.  Now you're talking about the "downward" direction.
>
>
> [minor] "replication to edges"
>
> Do you mean other EdgeRTRs?  Terminology consistency...
>
>
>
> 265	  - Clients: receive tile-by-tile geo-state updates via the multicast
>
> [-] This last bullet describes the information carried, while most of
> the other bullets talked about network functions.  It would be good to
> separate those.
>
>
> [nit] s/via the multicast/via multicast
>
>
>
> 267	3.  Deployment Assumptions
>
> 269	   The specification described in this document makes the following
> 270	   deployment assumptions:
>
> 272	   (1) Unique 64-bit HID is associated with each H3 geo-spatial tile
> 273	   (2) MobilityClients and H3ServiceEIDs share this well known index
> 274	   (3) 64-bit BDD state value is associated with each H3-indexed tile
> 275	   (4) Tile state is compiled 16 fields of 4-bits, or max 16 enums
>
> [major] All these assumptions are outside of lisp -- that in itself is
> not a bad thing.  What is not good is that there's no description of
> what some of these things are (index, BDD state, tile state), how they
> are configured, or exchanged, or ??, and much less how to
> verify/validate that the assumptions are satisfied.  As mentioned
> before, there is no specific reference to the H3 or BDD work.
>
> Furthermore, besides the "64-bit HID", which I think is associated to
> the H3ServiceEID, there's no specific relationship to lisp operating
> if any of these assumptions is met, or not.
>
>
> [major] What is the effect on the system if one, or more, of these
> assumptions is not met?
>
>
>
> 277	  0       1       2       3       4       5       6       7
> 278	  +-------+-------+-------+-------+-------+-------+-------+-------+
> 279	  |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
> 280	  |0123012301230123012301230123012301230123012301230123012301230123
> 281	  +---------------------------------------------------------------+
>
> 283	  Figure 3: Nibble based representation, 16 fields x 16 enumerations
>
> [major] This is a representation of what?  The "tile state"?
>
>
> 285	   We name the nibbles using hexadecimal index according to the
> 286	   position where the most significant nibble has index 0.
> 287	   Values are defined in section 8.
>
> [style nit] I prefer it if the document is written in the third person
> (The nibbles are named...) instead of the first (We name...).
>
>
> [minor] "index 0"
>
> Does that mean that the numbers on line 279 represent the index?
> Please indicate that on the figure, or at least be more explicit.
>
>
> [major] Where are these values carried?  How are they signaled?  From
> the assumptions above, it sounds like the values represent the "tile
> state"...but I'm not sure if that is an H3 or BDD attribute.  ??
>
> In either case, defining and maintaining an IETF-created registry
> seems to assume that H3/BDD will use it.  Will they?
>
>
>
> 289	   Subscription of MobilityClients to mobility-network is renewed
> 290	   while on the move and is not intended as the basic connectivity.
> 291	   MobilityClients use DNS/AAA to obtain temporary EIDs/EdgeRTRs
> 292	   and use (LISP) data-plane tunnels to communicate using their
> 293	   temporary EIDs with the dynamically assigned EdgeRTRs.
>
> [nit] s/to mobility-network/to the mobility-network
>
>
> [minor] "not intended as the basic connectivity"  Then what it?  This
> whole document talks about the mobility network -- the fact that
> different connectivity may exist seems out of scope.
>
> [minor] "use DNS/AAA...obtain temporary EIDs/EdgeRTRs...dynamically
> assigned EdgeRTRs"
>
> Where is this specified?  Please put a reference to that part of the document.
>
>
>
> 295	   MobilityClient are otherwise unaware of the LISP network control
> 296	   plane and simply regard the data-plane tunnels as a virtual
> 297	   private network (VPN) that supports IPv6 EID to upload (Ucast)
> 298	   and Subscribe-to (Mcast) H3Services.
>
> [minor] "MobilityClient are otherwise unaware of the LISP network
> control plane..."
>
> As I understand it, the MobilityClient only uses the LISP data plane...
>
>
> [major] The term "VPN" (used only here and in the next paragraph) may
> carry connotations related to privacy that are not explained.  If
> needed, consider using a different descriptor.
>
>
> [nit] This is the first time "Ucast" is used.  Please expand.
>
>
> [nit] Assuming that mcast was expanded before, please be consistent
> with the capitalizations: most instances use "mcast", not "Mcast".
>
>
>
> 300	   In order to get access to the MobilityVPN, MobilityClients first
> 301	   authenticate with the MobilityVPN AAA Server. DIAMETER [RFC6733]
> 302	   based AAA is typically done at the provider edge (PE) by gateways.
> 303	   However, the typical case involves several types of CPE connected
> 304	   to a specific service provider. On other hand, the Mobility VPN
> 305	   may overlay a number of wireless networks and cloud-edge providers.
> 306	   It also involves dozens of Car-OEM, Driving-Applications, Smart-
> 307	   City vendors. This is why we require clients to first go through
> 308	   AAA in order to get both a MobilityClientEID and EdgeRTR RLOC.
>
> [minor] Is the "MobilityVPN" (or "Mobility VPN") the same as the
> "Mobility Network"?  Please be consistent!
>
>
> [minor] Please expand AAA on first use.
>
>
> [nit] I believe rfc6733 doesn't capitalize "DIAMETER" (Diameter).
>
>
> [nit] s/AAA is typically done/AAA is typically used
>
>
> [major] "AAA is typically done at the provider edge"
>
> If AAA is not used, what are the risks of having an unauthorized
> MobileClient. If AAA is not used, can the system operate?
>
>
> [major] "AAA in order to get both a MobilityClientEID and EdgeRTR RLOC"
>
> This is a major departure from the lisp architecture!  In general,
> ITRs query the Mapping System, but in this case there are no
> Map-Request/Map-Reply messages, they are replaced by AAA.  IOW, AAA is
> the mapping system -- at least part of it.  Am I understanding this
> correctly?
>
> Is this new mapping system specified somewhere else?  If not, this
> document will need a lot more details -- for example, I included some
> questions below about the AVPs used.
>
> Given that the Diameter Server is now the Map-Server, there's also the
> question of how the mappings (if any) are registered by the ETRs.
>
> If only the LISP data plane is used, it is ok to use a different
> "mapping system".  It just needs to be completely specified -- or a
> pointer to where it is included.
>
>
>
> 310	   ClientXTR performs the following steps to use the mobility network:
> 311	   1) obtain the address of the mobility network AAA server using DNS
> 312	   2) obtain MobilityClientEID and EdgeRTR(s) from AAA DIAMETER server
>
> [major] Where is this exchange specified?
>
>
> 313	   3) renew authorization from AAA while using the mobility network
> 314	     MobilityClient DomainNameServer  DIAMETER-AAA  MobilityEdgeRTR
> 315	     |                    |                   |                   |
> 316	     | nslookup nexagon   |                   |                   |
> 317	     |------------------->|                   |                   |
> 318	     |<-------------------|                   |                   |
> 319	     |  Mobility AAA IP   |                   |                   |
> 320	     |                    |                   |                   |
> 321	     |  AAR(AVP:IMSI/User/Password/Toyota)    |                   |
> 322	     |--------------------------------------->|                   |
> 323	     |                    |                   | ACR(AVP ClientEID)|
> 324	     |                    |                   |------------------>|
> 325	     |                    |                   |<------------------|
> 326	     |                    |                   | ACA(AVP ClientEID)|
> 327	     |    AAA (Client::EID,EdgeRTR::RLOC)     |                   |
> 328	     |<---------------------------------------|                   |
> 329	     |                    |                   |                   |
> 330	     .                                                            .
> 331	     . Upload to IPv6 H3ServiceEID, Subscribe MLDv2 H3ServiceEID  .
> 332	     .                                                            .
> 333	     |                                                            |
> 334	     |----------------------------------------------------------->|
> 335	     .                                                            .
> 336	     .                                                            .
> 337	     |<-----------------------------------------------------------|
> 338	     |                                                            |
> 339	     .                                                            .
> 340	     .   Signal freeing multicast Updates from H3ServiceEID       .
> 341	     .                                                            .
> 342	     |                    |                   |                   |
> 343	     |               AAR(Interim)             |                   |
> 344	     |--------------------------------------->|   ACR (Interim)   |
> 345	     |                    |                   |------------------>|
> 346	     |                    |                   |<------------------|
> 347	     |                    |                   |   ACA (Interim)   |
> 348	     |<---------------------------------------|                   |
> 349	     |               AAA (Interim)            |                   |
>
> 351	  Figure 4: DNS and AAA Exchange for nexagon-network login
>
> [major] "nslookup nexagon"
>
> This is not a FQDN -- what is the expectation about the DNS setup that
> will work in this network?
>
> I think that going into this type of detail is too much for what
> should be a description of how LISP works in this type of network.
>
>
> [minor] Expand or define AAR, AAA, ACR, ACA, AVP -- I only found these
> last three in rfc6733.
>
>
> [major] Which AVPs are used?  Where are they specified?
>
>
> [minor] The figure uses both "ClientEID" and "Client::EID" to, I
> think, refer to the "MobilityClient EID".  Please be consistent.
>
>
> [minor] The Figure mentions MLDv2 and multicast in general -- please
> put a forward reference to where that is discussed.
>
>
> [?] Does the "Interim" indication have a special meaning?  Maybe it's
> something related to Diameter (?).
>
>
>
> 353	   Using this network login and re-login method we ensure that:
>
> [?] I'm not sure where the "login and re-login method" is reflected above.
>
>
>
> 354	   - MobilityClientEIDs serve as credentials with the EdgeRTRs
>
> [major] Does this mean that the EdgeRTRs are the nodes that complete
> the authorization process -- is that what this step is?
>
> 323	     |                    |                   | ACR(AVP ClientEID)|
> 324	     |                    |                   |------------------>|
> 325	     |                    |                   |<------------------|
> 326	     |                    |                   | ACA(AVP ClientEID)|
>
> If so, there seems to be a required relationship between the Diameter
> server and the EdgeRTR.  What is that?
>
>
>
> 355	   - EdgeRTRs are provisioned to whitelist MobilityClient EIDs
>
> [major] This seems related to my last question: the EdgeRTRs are
> provisioned with MobilityClient EIDs -- but, how does the Diameter
> server know to select a specific EID that will be authorized by the
> EdgeRTR.
>
> Note that none of this is specific to lisp -- so if there are
> references where the process is explained, please point to them.
>
>
> [major] "whitelist"
>
> In order to improve inclusivity, please consider using a different term.
>
> https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/
>
>
>
> 356	   - EdgeRTRs are not tightly coupled to H3.r9 areas (privacy/balance)
>
> [major] I'm missing the explanation of why "privacy/balance" is the
> reason for not tightly coupling, or maybe the result of it.
>
>
>
> 357	   - MobilityClients do not need to update EdgeRTRs while roaming
> 358	   The same EdgeRTR may serve several H3.r9 areas for ride continuity
> 359	   and several EdgeRTRs may load balance an H3.r9 area with high
> 360	   density of MobilityClients. When a MobilityClient ClientXTR is
> 361	   homed to EdgeRTR, it is able to communicate with H3ServiceEIDs.
>
> [major] "MobilityClients do not need to update EdgeRTRs...may serve
> several H3.r9 areas"
>
> The MobilityClients are in the H3.r15 tiles, not H3.r9.  My guess is
> that there is a hierarchical relationship that hasn't been explained.
>
> How/When does a MobilityClient need to "update EdgeRTRs" (which I
> think means change to another EdgeRTR)?  Is this an action triggered
> by the MobilityClient?
>
>
>
> 363	4. Mobility Clients Network Services
>
> 365	  The mobility network functions as a standard LISP overlay.
> 366	  The overlay delivers unicast and multicast packets across:
> 367	   - multiple access-networks and radio-access specifications
> 368	   - multiple edge providers, public, private, and hybrid clouds
>
> [?]
>
>
>
> 370	  We use data-plane XTRs in the stack of each mobility client/server.
> 371	  ClientXTRs and ServerXTRs are homed to one or more EdgeRTRs.
> 372	  This structure allows for MobilityClients to "show up" at any time,
> 373	  behind any network provider in a given mobility network admin/NAT
> 374	  domain, and for any H3ServiceEID to be instantiated, moved, or
> 375	  failed-over to any rack in any cloud-provider. LISP overlay enables
> 376	  these roaming mobility network elements to communicate uninterrupted.
> 377	  This quality is insured by the LISP RFCs. The determination of
> 378	  identities for MobilityClients to always refer to the correct
> 379	  H3ServiceEID is insured by H3 geo-spatial HIDs.
>
> [minor] "...XTRs are homed to one or more EdgeRTRs"
>
> You've mentioned the concept of "homed to" a couple of times.  What
> does that mean from a lisp point of view?  How is it enforced?  The
> next sentence uses "to associate"...
>
>
>
> 381	  There are two options to associate ClientXTRs with LISP EdgeRTRs:
>
> 383	  i. Semi-random load-balancing by DNS/AAA
>
> 385	  In this option we assume that in a given metro edge a pool of
> 386	  EdgeRTRs can distribute the Mobility Clients load randomly between
> 387	  them and that EdgeRTRs are topologically equivalent. Each RTR uses
> 388	  LISP to tunnel traffic to and from other EdgeRTRs for MobilityClient
> 389	  with H3Service exchanges. MobilityClients home to EdgeRTRs.
>
> 391	  ii. Topological by anycast
>
> 393	  In this option we align an EdgeRTR with topological aggregation.
> 394	  Mobility Clients are roaming in an area home to that RTR and so
> 395	  is the H3 Server. There is only one hop across the edge overlay
> 396	  between clients and servers and mcast replication is more
> 397	  focused, but clients need to keep re-homing as they move.
>
> [major] Both of this options make assumptions.  How can a deployment
> determine which scenario it's in?  What happens if the assumption made
> is not met anymore?
>
>
> [major] The "association" of the ClientXTRs to an EdgeRTR is the
> function of the mapping system.  This document is not properly
> specifying this new mapping system.
>
> Both methods above assume that ant RTR will be able to provide the
> needed reachability.  It assumes that even if both sets of EdgeRTRs
> may be moving, the reachability will always be there.
>
> Also, I assume that the EdgeRTRs learn about mappings between them
> (through the mobility network) through rfc6833bis mechanisms.  This
> means that the traffic may reach an EdgeRTR that doesn't have a
> specific mapping, or (in the anycast case) that is even disconnected
> from the mobility network.
>
> What are the conditions that guarantee end-to-end reachability?  When
> can they not be met?  What are the consequences?  Are there any
> possible mitigations?
>
>
>
> ...
> 408	       MobilityClients <> ClientXTR <Access Provider > EdgeRTR  v
> 409	                                                                v
> 410	       v < < < < Map-Assisted Mobility-Network Overlay < < < <  v
> 411	       v
> 412	       > > > > EdgeRTR <Cloud Provider> ServerXTR <> H3ServiceEID
>
> [major] What does the term "Map-Assisted" mean?  This figure needs
> more explanation.
>
>
>
> ...
> 416	5. Mobility Unicast and Multicast
>
> 418	  Regardless of the way a given ClientXTR was associated with EdgeRTR,
> 419	  an authenticated MobilityClient EID can send: [64bitH3.15ID ::
> 420	  64bitState]annotations to the H3.r9 H3ServiceEID. The H3.r9 EID can
> 421	  be calculated by clients algorithmically from the H3.15 localization.
>
> [??] "[64bitH3.15ID :: 64bitState]annotations"  ??
>
>
> [minor] Are the "H3.r9 H3ServiceEID" and "H3.r9 EID" the same thing?
>
>
> [nit] s/H3.15/H3.r15
>
>
> [major] "The H3.r9 EID can be calculated by clients algorithmically
> from the H3.15 localization."
>
> By "clients" I assume you're referring to the MobilityClients.  Where
> is the algorithm specified?
>
>
>
> 423	  The ClientXTR encapsulates MobilityClient EID and H3ServiceEID from
> 424	  the ClientXTR with the destination of the EdgeRTR RLOC LISP port.
> 425	  EdgeRTRs then re-encapsulate annotation packets to remote EdgeRTR.
> 426	  The remote EdgeRTR aggregating H3ServiceEIDs re-encapsulates
> 427	  MobilityClient EID to the ServerXTR, to the H3ServiceEID.
>
> [minor] "encapsulates MobilityClient EID and H3ServiceEID from the ClientXTR"
>
> The descriptions can be a lot clearer.  The EIDs are the
> source/destination of the packet that comes from the MobilityClient
> (not the ClientXTR)...
>
>
> [minor] "with the destination of the EdgeRTR RLOC LISP port"
>
> The destination is the EdgeRTR RLOC, where does the "LISP port" come
> in?  Maybe you tried to compress in the UDP port number.  Please be
> clear and specific.
>
>
> [minor] I'm not sure what the relevance of "annotation packets" (the
> specific type) is.  From the lisp point of view, a packet is a packet,
> or are you expecting something different for other packets from the
> MobilityClient?
>
>
> [nit] s/to remote EdgeRTR/to a remote EdgeRTR
>
>
> [minor] "re-encapsulates MobilityClient EID to the ServerXTR, to the
> H3ServiceEID"
>
> As written it sounds like a double re-encapsulation: to the ServerXTR
> and then to the H3ServiceEID.  What is re-encapsulated is not the EID,
> but the packet.
>
>
>
> 429	  The headers consist of the following fields:
>
> 431	  Outer headers = 40 (IPv6) + 8 (UDP) + 8 (LISP) = 56
> 432	  Inner headers = 40 (IPv6) + 8 (UDP) + 4 (Nexagon Header) = 52
> 433	  1500 (MTU) - 56 - 52 = 1392 bytes of effective payload
>
> [minor] Please explain somewhere that you are listing the size of the headers.
>
>
>
> 435	  Nexagon Header Type allows for kv tupples or vkkk flooding
>
> [?] What do k and v stand for?  This is the only part of the document
> (and below) where this nomenclature is used.
>
>
>
> 436	  Type 0:reserved
> 437	  Type 1:key-value, key-value.. 1392 / (8 + 8) = 87 pairs
> 438	  Type 2:value, key,key,key.. (1392 - 8) / 8 = 173 H3-R15 IDs
> 439	  Type 3-255: unassigned
>
> [minor] Ok, so kv, vkkk is somewhat clarified.  Does this mean that
> the types have different formats?  Please be more descriptive in the
> definition of the types.
>
>
> [major] Peeking ahead, I see that there's no description of the fields
> or where the values come from after Figure 6.  I think it's better to
> first present the figure and then describe the fields.  Please move
> the fields description to after the figure.
>
>
> [major] I assume you want IANA to manage the allocation of the types.
> Please include that information in the IANA Considerations Section.
>
>
>
> 440	  Nexagon Header GZIP field: 0x000 no compression, or GZIP version.
>
> [major] What is compressed?
>
>
> [major] Where do the versions come from?  I found rfc1952 which
> specifies GZIP version 4.3 -- how would that be represented in the
> 3-bit field?
>
>
> [major] What should a receiver do if the version is not supported or
> unknown?  This part of the specification seems to go beyond describing
> how lisp is used --- but the packet format is described here, so I
> have to ask.
>
>
>
> 441	  Nexagon Header Reserved bits
>
> [major] In most cases reserved fields are specified as being set to 0
> on transmission and ignored when received, do you want to specify
> anything like that?
>
>
>
> 442	  Nexagon Header kv count (in any format)
>
> [major] The figure shows "Pair Count = X" (which should really be just
> "Pair Count"), and not "kv count".
>
>
> [minor] What do you mean by "in any format"?  I assume you're
> referring to the types...but then it's not clear how, for example Type
> 2 ("value, key,key,key..") should be counted.  Please be specific.
>
>
>
> 444	 0                   1                   2                   3
> 445	 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
> 446	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
> 447	|Version| Traffic Class |           Flow Label                  |  |
> 448	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
> 449	|         Payload Length        |  Next Header  |   Hop Limit   |  |
> 450	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
> 451	|                                                               |  |
> 452	+                                                               +  |
> 453	|                                                               |  |
> 454	+                    Source MobilityClientEID                   +  |
> 455	|                                                               | IPv6
> 456	+                                                               +  |
> 457	|                                                               |  |
> 458	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
> 459	|                                                               |  |
> 460	+                                                               +  |
> 461	|                                                               |  |
> 462	+                       Dest H3ServiceEID                       +  |
> 463	|                                                               |  |
> 464	+                                                               +  |
> 465	|                                                               | /
> 466	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 467	|       Source Port = xxxx      |       Dest Port = xxxx        | \
> 468	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
> 469	|           UDP Length          |        UDP Checksum           | /
> 470	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
> 471	|  Type         |gzip |        Reserved         | Pair Count = X| Nexgon
> 472	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
> 473	|                                                               |
> 474	+                       64 Bit H3-R15 ID                        +
> 475	|                                                               |
> 476	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 477	|                                                               |
> 478	+                       64 Bit State                            +
> 479	|                                                               |
> 480	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 481	|                                                               |
> 482	+                       64 Bit H3-R15 ID                        +
> 483	|                                                               |
> 484	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 485	|                                                               |
> 486	+                       64 Bit State                            +
> 487	|                                                               |
> 488	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 490	  Figure 6: Uploaded detections packet format
>
> [nit] s/Nexgon/Nexagon
>
> I realize that the whole word may not fit, but that is not an excuse
> to use a shorthand version without explanation.  Instead, explain
> which fields are part of the Nexagon Header (as mentioned above).
>
>
> [major] The rest of the fields are not specified anywhere.
>
>
>
> 491	  To Summarize Unicast Uploads:
>
> 493	   (1) MobilityClients can send annotations are localized to H3.r15
> 494	       tile. These annotations are sent to H3.r9 mobility H3ServiceEIDs
>
> [minor] "MobilityClients can send annotations are localized to H3.r15 tile."
>
> It's not clear to me if the MobilityClients or the annotations are localized.
>
>
> [?] I'm guessing that "annnotations" and "uploads" are the same thing.
> The word "upload" is used elsewhere as a noun, not just an action.
> Please clarify.
>
>
> [minor] "sent to H3.r9 mobility H3ServiceEIDs"
>
> "H3ServiceEIDs" and "H3.r9 EIDs" have been used before to mean the
> same thing -- I think.  This sentence seems to introduce a new term:
> "H3.r9 mobility H3ServiceEIDs".   If they are all the same, please use
> only one.  See the definition in §2.
>
>
> [nit] s/H3ServiceEIDs/H3ServiceEIDs.
>
>
>
> 495	   (2) MobilityClient EID and H3ServiceEID HID are encapsulated:
> 496	         XTR <> RTR <> RTR <> XTR
> 497	       * RTRs can map-resolve re-tunnel HIDs
>
> [minor] Please explain what is meant by "<>", it may not be clear to everyone.
>
>
> [minor] Even though I understand what you mean my "map-resolve", I
> haven't seen the term used as a verb in rfc6830bis/rfc6833.
>
>
> [minor] s/re-tunnel/re-encapsulates
>
>
> [minor] I mentioned before about the need to clarify what an HID is
> and its relationship to EID and the H3ServiceEID in particular.
>
>
>
> 498	   (3) RTRs re-encapsulate original source-dest to ServerXTRs
> 499	       ServerXTRs decapsulate packets to H3ServiceEID
>
> [minor] This text sounds like a repetition of step 2, which shows the
> whole path.
>
>
>
> 501	  Each H3.r9 Server is also an IP Multicast Source used to update
> 502	  subscribers on the aggregate state of the H3.r15 tiles in the H3.r9
> 503	  server. This forms a multipoint to multipoint state channel per H3
> 504	  location, where the aggregation has compute-first propagation.
>
> [minor] "H3.r9 Server" is a new term.
>
>
> [minor] s/state of the H3.r15 tiles in the H3.r9 server/state of the
> H3.r15 tiles
>
>
> [?] "multipoint to multipoint state channel per H3 location"
>
> Because there are multiple H3.r9 Servers per tile?  You'll probably
> need to explain that more.
>
>
> [minor] "the aggregation has compute-first propagation"
>
> ??
>
>
>
> 506	  We use [RFC8378] signal-free multicast to implement mcast channels in
> 507	  the overlay. The mobility network has many channels, with thousands
> 508	  subscribers per channel. MobilityClients driving through/subscribing
> 509	  to an H3.r9 area can explicitly issue an [RFC4604] MLDv2 in order to
> 510	  subscribe, or, may be subscribed implicitly by the EdgeRTR.
>
> [minor] Is an "area" the same things as a "tile"?
>
>
> [?] "MobilityClients driving through/subscribing to an H3.r9 area..."
>
> I thought the MobilityClients were in the H3.r15 tiles.  :-(
>
>
> [major] The MobilityClient "can explicitly issue an [RFC4604] MLDv2" what?
>
>
> [major] s/RFC4604/RFC3810
>
>
> [major] How does the MobilityClient know/discover which (S,G) to join?
>
>
> [major] "MobilityClients...can...subscribe, or, may be subscribed
> implicitly by the EdgeRTR."
>
> How does a MobilityClient know what to do -- discover and join, or
> wait.  How does the EdgeRTR discover which groups to join?  Even if
> implicitly subscribed, the MobilityClient should somehow know which
> (S,G) to listen to -- how is that done?
>
>
>
> 512	  The advantage of explicit client MLDv2 registration as [RFC8378]
> 513	  trigger is that clients manage their own mobility mcast handover per
> 514	  location-direction vectors, and that it allows for otherwise silent
> 515	  non annotating clients. The advantage of EdgeRTR implicit registration
> 516	  is that less signaling required.
>
> [major] "client MLDv2 registration as [RFC8378] trigger"
>
> rfc8378 unfortunately only talked about IGMP, no mention of MLD.
> We'll need to add a paragraph or two (a couple of sentences may be
> enough) about how the specification in rfc8378 also applies without
> modification (?) to MLDv2.
>
>
> [nit] s/clients/MobilityClients/g
>
>
> [major] "mcast handover per location-direction vectors"
>
> This makes discovering the (S,G) more important as it may change.
>
>
> [major] "otherwise silent non annotating clients"
>
> I thought annotations were in the client to server direction.  But
> multicast is in the opposite direction.  What is the relationship
> between the ability (or maybe willingness) of the MobilityClient to
> send/annotate information and them receiving multicast traffic?  Is
> there a downside if silent MobilityClients receive the multicast
> information and use it...
>
>
>
> 518	  MLDv2 signaling messages are encapsulated between the ClientXTR and
> 519	  EdgeRTR, therefore there is no requirement for the underlying network
> 520	  to support native multicast. If native access multicast is supported
> 521	  then MobilityClient registration to H3ServiceEID safety channels may
> 522	  be integrated with it, in which case mobile packet-core element
> 523	  supporting it will use this standard to register with the
> 524	  appropriate H3.r9 channels in its area.
>
> [major] "MLDv2 signaling messages are encapsulated between the
> ClientXTR and EdgeRTR..."
>
> rfc8378 doesn't talk about encapsulating anything -- §5.1.1 assumes
> PIM being enabled.  As mentioned above, the use of rfc8378 is not "as
> is", but there are assumptions made that are not obvious.  You'll need
> to add text about the use of rfc8378 and the assumptions/differences.
>
> The paragraph goes on to talk about the case when "native access
> multicast is supported" -- I guess at this point rfc8378 is not used
> anymore.  The text says that the "registration...may be integrated
> with it" -- does this mean that is is optional?
>
> But then it goes back to an "element supporting it will use this
> standard to register with the appropriate H3.r9 channels in its area".
> By "this standard" do you mean using rfc8378 or not -- I'm confused.
> Also, I guess that the "H3.r9 channels" are equivalent to the
> "H3ServiceEID safety channels" mentioned before, and to any other
> mention of multicast information.  Is that a good guess?
>
>
> [minor] This is the first time that "H3ServiceEID safety channels" is
> used.  I assume the type of channel doesn't matter -- it's just that
> it was never mentioned this way before.  Or is there relevance in the
> use of "safety" to describe it?  Also, if we want to be strict, the
> multicast information is provided by the servers not the EID.
>
>
>
> 526	  Multicast update packets are of the following structure:
>
> 528	 0                   1                   2                   3
> 529	 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
> 530	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
> 531	|Version| Traffic Class |           Flow Label                  |  |
> 532	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
> 533	|         Payload Length        |  Next Header  |   Hop Limit   |  |
> 534	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
> 535	|                                                               |  |
> 536	+                                                               +  |
> 537	|                                                               |  |
> 538	+                       Source H3-R9 EID Address                +  |
> 539	|                                                               | IPv6
> 540	+                                                               +  |
> 541	|                                                               |  |
> 542	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
> 543	|                                                               |  |
> 544	+                                                               +  |
> 545	|                                                               |  |
> 546	+                          Group Address                        +  |
> 547	|                                                               |  |
> 548	+                                                               +  |
> 549	|                                                               | /
> 550	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 551	|       Source Port = xxxx      |       Dest Port = xxxx        | \
> 552	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
> 553	|           UDP Length          |        UDP Checksum           | /
> 554	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
> 555	|                                                               |Nexagon
> 556	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
> 557	~                            Nexagons Payload                   ~
> 558	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 560	  Figure 7: Mcast update packet header
>
> [minor] As drawn, the "Nexagon" section seems to only cover the first
> 4 bytes.  It also looks like those are empty.  ??
>
>
> [major] Where is the "Nexagons Payload" defined?  Is that what the
> next two figures show?  It is not clear.
>
>
> [major] This part shows application level packet formats -- which have
> no relationship to LISP.  Does this part of the description need to be
> part of this document?
>
>
>
> 562	 0                   1                   2                   3
> 563	 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
> 564	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
> 565	|  Type =   1   |gzip |        Reserved         | Pair Count = X|Nexagon
> 566	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
> 567	|                                                               |
> 568	+                       64 Bit H3-R15 ID                        +
> 569	|                                                               |
> 570	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 571	|                                                               |
> 572	+                       64 Bit State                            +
> 573	|                                                               |
> 574	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 575	|                                                               |
> 576	+                       64 Bit H3-R15 ID                        +
> 577	|                                                               |
> 578	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 579	|                                                               |
> 580	+                       64 Bit State                            +
> 581	|                                                               |
> 582	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 584	  Figure 8: Mcast update payload, key-value, key-value..
>
> [major] Where are the fields specified?  If they were defined earlier
> (gzip, for example), please include a pointer to where.
>
>
>
> ...
> 610	  The remote EdgeRTRs homing MobilityClients in turn replicate the
> 611	  packet to the MobilityClients registered with them.
>
> [major] The paragraph before the figures talked about how the tail end
> of the multicast tree (from the MobilityClient to the EdgeRTR) was
> formed.  But the rest of the process was not described.  This
> paragraph jumps right into the delivery.  IOW, there's no description
> of how the Servers know if there are subscribers..
>
>
>
> 613	  We expect an average of 600 H3.r15 tiles of the full 7^6 (~100K)
> 614	  possible in H3.r9 to be part of any road. The H3.r9 server can
> 615	  transmit the status of all 600 or just those with meaningful states
> 616	  based on updated SLA and policy.
>
> [major] "We expect an average of 600 H3.r15 tiles of the full 7^6
> (~100K) possible...The H3.r9 server can transmit the status of all 600
> or just those with meaningful states..."
>
> Is there a scalability limitation with the system?
>
>
>
> 618	  To Summarize:
>
> 620	   (1) H3LISP Clients tune to H3.r9 mobility updates using [RFC8378]
> 621	       H3LISP Client issue MLDv2 registration to H3.r9 HIDs
> 622	       ClientXTRs encapsulate MLDv2 to EdgeRTRs who register (s,g).
>
> [minor] "H3LISP" was used before in the context of a network...not a client.
>
>
> [nit] These seem to be 3 separate sentences (or fragments).  Maybe use bullets.
>
>
> [minor] "tune to H3.r9 mobility updates"   This is a new way to refer
> to registration and multicast...
>
>
> [minor] "using [RFC8378]"  See my comments above about rfc8378.
>
>
> [minor] "H3.r9 HIDs"  And another way to refer to "H3.r9 channels"...
>
>
>
> 624	   (2) ServerXTRs encapsulate updates to EdgeRTRs who map-resolve (s,g)
> 625	       RLOCs EdgeRTRs replicate mobility update and tunnel to registered
> 626	       EdgeRTRs Remote EdgeRTRs replicate updates to ClientXTRs.
>
> [] See other comments above about the description of the process.
>
>
>
> 628	6.  Security Considerations
>
> 630	  The nexagon layer3 v2n network is inherently more secure and private
> 631	  then peer to peer alternatives because of the indirection. No car or
> 632	  infrastructure element communicates directly with MobilityClients.
> 633	  All information is conveyed using shared addressable geo-state.
> 634	  MobilityClients receive information only from geospatial channels
> 635	  originating from a trusted broker. MobilityClients have no indication
> 636	  as to the origin of the information. This is an important step towards
> 637	  better privacy, security, extendability, and interoperability compared
> 638	  with legacy layer2 protocols.
>
> [major] This paragraph uses indirection to claim that this proposal is
> "more secure and private" than the alternatives.  However, we don't
> need a comparison, or a justification that this is better because the
> alternative is not.  What is needed in an analysis of *this* proposal.
>
> [Even if you wanted to compare to "peer to peer alternatives", there
> is no baseline (or reference) presented to compare to.]
>
> Please take a look at rfc6973 and rfc3552.
>
> Note that I'm making this comment because of the claims made in
> different parts of the document.  Because this use case is built on
> top of lisp, many of the aspects should have been considered in the
> base specifications, so pointing to them should cover a significant
> portion of what is needed.  The only things left should be anything
> that is specific to a nexagon-type deployment that is not present in a
> typical lisp deployment.
>
>
>
> 640	  In order to be able to use the nexagon mobility network for a given
> 641	  period, the mobility clients go through a DNS/AAA stage by which they
> 642	  obtain their clientEID identifiers-credentials and the RLOCs of
> 643	  EdgeRTRs they may use as gateways to the network. This MobilityClient
> 644	  <> EdgeRTR interface is the most sensitive in this network to privacy
> 645	  and security considerations.
>
> [major] This (the "DNS/AAA stage") is one of the parts of the solution
> that is not related to lisp.
>
>
> 647	  The traffic on the MobilityClient<>EdgeRTR interface is tunneled, and
> 648	  its UDP content may be encrypted; still, the EdgeRTR will know based
> 649	  on the LISP headers alone the MobilityClient RLOC and H3-R9 (~0.1sqkm)
> 650	  geo-spatial area to which a given client uploads or subscribes to.
>
> [major] "may be encrypted"
>
> This is the first mention of encryption in the document.  If it is
> possible, where is it specified?  What are the considerations to do it
> or not?
>
>
> [major] "H3-R9 (~0.1sqkm) geo-spatial area"
>
> Knowing the location of the MobilityClient, its movement, and being
> able to track it is a privacy issue.  I need you to address that in a
> privacy section (see rfc6973).
>
>
>
> 652	  For this reason we envision the ability of enterprise or groups of
> 653	  users to "bring their own" EdgeRTRs. BYO-RTR masks individual clients'
> 654	  RLOC to H3-R9 association and is pre-provisioned to be able to use the
> 655	  mapping system and be on a white-list of EdgeRTRs aggregating
> 656	  H3ServiceEIDs. If the EdgeRTR functionality is delivered by 5GCore UPF
> 657	  then the only entity which can correlate underlay IP, User, and Geo-
> 658	  location is the regulated carrier, which can do so anyway.
>
> [major] There are two sets of EdgeRTRs -- MobilityClient-facing and
> Server-facing.  Does the ""bring their own" EdgeRTRs" strategy apply
> to both or just one?  If only the MobilityClient-facing EdgeRTRs are
> enterprise-specific, but the rest of the network is not, then there
> are still opportunities for the tracking given that the rest of the
> traffic (both annotations and multicast are in the clear), etc.
>
>
> [?] "BYO-RTR...pre-provisioned to be able to use the mapping system
> and be on a white-list of EdgeRTRs aggregating H3ServiceEIDs."
>
> If the "EdgeRTRs aggregating H3ServiceEIDs" are "public" (not
> enterprise-specific) then the configuration task is not trivial.  Are
> there management/operational considerations that would apply to making
> the decision of using BYO-RTRs?  Given that we're talking about
> security/privacy considerations, I'm specially interested in those.
>
>
> [major] "EdgeRTR functionality is delivered by 5GCore UPF"
>
> This is the one and only time when 5G is mentioned in this document.
> You'll need to provide more background on this option, expand UPF,
> etc.
>
>
>
> 660	  Beyond this hop, the mapping system does not hold MobilityClientEIDs,
> 661	  and remote EdgeRTRs are only aware of MobilityClient ephemeral EIDs,
> 662	  not actual RLOC or any other mobile-device identifiers. EdgeRTRs
> 663	  register in the mapping (s,g) H3-R9 multicast groups. Which clients
> 664	  use which EdgeRTR is not in the mapping system, only the AAA server is
> 665	  aware of that. The H3ServiceEIDs themselves decrypt and parse actual
> 666	  H3-R15 annotations; they also consider during this MobilityClientEID
> 667	  credentials to avoid "fake-news", but again these are only temporary
> 668	  EIDs allocated to clients in order to be able to use the mobility
> 669	  network and not for their actual IP.
>
> [?] What is the difference between MobilityClientEIDs and
> "MobilityClient ephemeral EIDs"?  I understand the word "ephemeral" --
> but the EID of the MobilityClient part is what sounds the same to me.
>
>
> [major] "consider during this MobilityClientEID credentials to avoid
> "fake-news""
>
> Which credentials?
>
> Does this mean that the H3ServiceEID can make decision on whether to
> accept the information from the MobilityClients based on their
> credentials?
>
> You might want to be a little more specific on the meaning of "fake
> news" in this context.
>
>
>
> 671	  H3Services are provisioned to their EdgeRTRs, in the EdgeRTRs, and
> 672	  optionally also in the mapping system.
>
> [?] "provisioned to their EdgeRTRs, in the EdgeRTRs"   To and in???
>
>
> [major] Services are provisioned in the mapping system?
>
>
>
> 674	  In summary of main risk mitigations for the lisp-nexagon interface:
>
> [major] This is the first mention of the "lisp-nexagon interface".
> The description below doesn't reflect what I would consider an
> "interface".  Please describe more.
>
>
>
> 676	  (1) tapping: all communications are through dynamic tunnels therefore
> 677	  may be encrypted using IP-Sec or other supported point to point
> 678	  underlay standards. These are not static tunnels but LISP re-tunneling
> 679	  routers (RTRs) perform all nexagon Overlay aggregation.
>
> [minor] "dynamic tunnels therefore may be encrypted"
>
> Maybe it's just me, but I don't see an obvious connection between a
> dynamic tunnel and the fact that encryption can be used.  I'm sure the
> contents of static tunnels can be encrypted too.
>
>
> [major] "may be encrypted using IP-Sec or other supported point to
> point underlay standards"
>
> If the encryption (this is just the second mention) is not required or
> even recommended, protection against monitoring is not assured.
>
>
> [?] "These are not static tunnels but LISP re-tunneling routers (RTRs)
> perform all nexagon Overlay aggregation."
>
> Sorry, but in the context of this section, I'm not sure what this
> sentence is expected to convey.  In the previous sentence the use of
> dynamic tunnels (aka "not static tunnels") seem to be used in a
> positive way.  This sentence uses "but", which is confusing me...
>
>
>
> 681	  (2) spoofing: it is very hard to guess a MobilityClientEID valid for
> 682	  a short period of time. Clients and H3Services EIDs are whitelisted
> 683	  in EdgeRTRs, Clients using the AAA procedure, H3Services via dev-ops.
>
> [major] "it is very hard to guess"
>
> I'm not a security expert, but the pool of addresses is finite, so it
> would seem that it may not be too hard to randomly spoof packets from
> a limited range.  I'm sure the security reviewers will want more
> assurances.
>
>
> [] The mention of "dev-ops" will trigger the question of "how?" and
> whether a YANG model exists for the configuration and monitoring of
> this system.
>
>
> 685	  (3) impersonating: efforts to use MobilityClients and H3Services RLOCs
> 686	  should be caught by the underlying service provider edge and access
> 687	  networks. EID impersonating is caught by EdgeRTR EID RLOC whitelist
> 688	  mismatch.
>
> [] I don't think I understand the difference between "spoofing" and
> "impersonating". :-(
>
>
> [major] "should be caught by the underlying service provider edge and
> access networks"
>
> "should be caught" doesn't transmit a lot of confidence.   How is it done?
>
>
>
> 690	  (4) credibility: the interface crowd-sources geo-state and does not
> 691	  assume to trust single detections. Credit history track to
> 692	  MobilityClientEIDs by as part of normal H3Services fact checking,
> 693	  aggregate scores affect AAA credentials.
>
> [major] "the interface crowd-sources geo-state"
>
> In this context, "the interface" sounds like a place in the network,
> an entity/node that has this function.  ???
>
> This function seems to be at the application layer...and not one
> related to lisp.
>
>
> [major] "Credit history track to MobilityClientEIDs by as part of
> normal H3Services fact checking, aggregate scores affect AAA
> credentials."
>
> Again, this part is not related to lisp.
>
> Also, "fact checking" is mentioned -- I assume related to the mention
> of "fake news" earlier.  I don't understand the relationship between
> "credit history" and the "AAA credentials".
>
>
>
> 695	  (5) privacy: Only EdgeRTRs are aware of both clients' RLOC and
> 696	  geo-location, only AAA is aware of client IDs credentials and credit
> 697	  but not geo-location. Aggregate credit score span all H3Services
> 698	  administratively without source.
>
> [major] From the privacy point of view, please indicate which
> potential risk still may exist even if all the information is not
> known everywhere.  I'm specially interested in the location.
>
>
>
> ...
> 707	8.  IANA Considerations
> ...
> 715	Such registry should be populated with the following sub registries.
>
> [major] There's no indication how/when any of the values in these
> registries is used, or what they mean.  If defined here there should
> be a discussion of their use (not in this section).
>
>
> [EoR -19]
>
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp