Re: [lisp] Review for LISP Geo-Coordinate Use-Cases

[Dino Farinacci <[e-mail]>]

I agree with all your comments and will do a revision. 

Regarding Type 5, that type was previously allocated *for this draft*. Sometimes it is hard to remember since so much time has passed.

So we do not need a new type.

Dino

> On Dec 9, 2022, at 6:38 AM, Luigi Iannone <[e-mail]> wrote:
> 
> Hi Dino,
> 
> I reviewed the lisp-geo document. My comments inline.
> 
> Ciao
> 
> L.
> 
> 
> 
> 
> 
> 
> 
>> 
>> 
>> 
>> 
>> 
>> Network Working Group                                       D. Farinacci
>> Internet-Draft                                               lispers.net
>> Intended status: Experimental                           23 November 2022
>> Expires: 27 May 2023
>> 
>> 
>>                     LISP Geo-Coordinate Use-Cases
>>                         draft-ietf-lisp-geo-00
>> 
>> Abstract
>> 
>>   This draft describes how Geo-Coordinates can be used in the LISP
>>   Architecture and Protocols.
>> 
> 
> Would be good to add more word. The document does 2 things: propose uses cases, define geo coordinates encoding.
> 
> 
>> Status of This Memo
>> 
>>   This Internet-Draft is submitted in full conformance with the
>>   provisions of BCP 78 and BCP 79.
>> 
>>   Internet-Drafts are working documents of the Internet Engineering
>>   Task Force (IETF).  Note that other groups may also distribute
>>   working documents as Internet-Drafts.  The list of current Internet-
>>   Drafts is at https://datatracker.ietf.org/drafts/current/.
>> 
>>   Internet-Drafts are draft documents valid for a maximum of six months
>>   and may be updated, replaced, or obsoleted by other documents at any
>>   time.  It is inappropriate to use Internet-Drafts as reference
>>   material or to cite them other than as "work in progress."
>> 
>>   This Internet-Draft will expire on 27 May 2023.
>> 
>> Copyright Notice
>> 
>>   Copyright (c) 2022 IETF Trust and the persons identified as the
>>   document authors.  All rights reserved.
>> 
>>   This document is subject to BCP 78 and the IETF Trust's Legal
>>   Provisions Relating to IETF Documents (https://trustee.ietf.org/
>>   license-info) in effect on the date of publication of this document.
>>   Please review these documents carefully, as they describe your rights
>>   and restrictions with respect to this document.  Code Components
>>   extracted from this document must include Revised BSD License text as
>>   described in Section 4.e of the Trust Legal Provisions and are
>>   provided without warranty as described in the Revised BSD License.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                  [Page 1]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>> Table of Contents
>> 
>>   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>>   2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
>>   3.  Geo-Points in RLOC-records  . . . . . . . . . . . . . . . . .   3
>>   4.  Geo-Prefixes in EID-records and RLOC-records  . . . . . . . .   3
>>   5.  Geo-Prefix and Geo-Point Encodings  . . . . . . . . . . . . .   5
>>   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
>>   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
>>   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
>>   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
>>     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
>>     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
>>   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  10
>>   Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  10
>>     B.1.  Changes to draft-ietf-lisp-geo-00 . . . . . . . . . . . .  10
>>     B.2.  Changes to draft-farinacci-lisp-geo-15  . . . . . . . . .  11
>>     B.3.  Changes to draft-farinacci-lisp-geo-14  . . . . . . . . .  11
>>     B.4.  Changes to draft-farinacci-lisp-geo-13  . . . . . . . . .  11
>>     B.5.  Changes to draft-farinacci-lisp-geo-12  . . . . . . . . .  11
>>     B.6.  Changes to draft-farinacci-lisp-geo-11  . . . . . . . . .  11
>>     B.7.  Changes to draft-farinacci-lisp-geo-10  . . . . . . . . .  11
>>     B.8.  Changes to draft-farinacci-lisp-geo-09  . . . . . . . . .  11
>>     B.9.  Changes to draft-farinacci-lisp-geo-08  . . . . . . . . .  11
>>     B.10. Changes to draft-farinacci-lisp-geo-07  . . . . . . . . .  12
>>     B.11. Changes to draft-farinacci-lisp-geo-06  . . . . . . . . .  12
>>     B.12. Changes to draft-farinacci-lisp-geo-05  . . . . . . . . .  12
>>     B.13. Changes to draft-farinacci-lisp-geo-04  . . . . . . . . .  12
>>     B.14. Changes to draft-farinacci-lisp-geo-03  . . . . . . . . .  12
>>     B.15. Changes to draft-farinacci-lisp-geo-02  . . . . . . . . .  12
>>     B.16. Changes to draft-farinacci-lisp-geo-01  . . . . . . . . .  12
>>     B.17. Changes to draft-farinacci-lisp-geo-00  . . . . . . . . .  13
>>   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13
>> 
>> 1.  Introduction
>> 
>>   The LISP architecture and protocols [RFC9300] introduces two new
>>   namespaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs)
>>   which are intended to separate the semantics of identity and
>>   topological location from an IP address.  To provide flexibility for
>>   current and future applications, these values can be encoded in LISP
>>   control messages using a general syntax that includes Address Family
>>   Identifier (AFI) [RFC1700].
>> 
>>   This specification introduces the use of Geo-Coordinates that can be
>>   used in EID-records and RLOC-records of LISP control messages.  The
>>   encoding format is specified in [RFC8060] as the "Geo-Coordinates
>>   LCAF Type".
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                  [Page 2]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>> 2.  Definition of Terms
>> 
>>   Geo-Point  is a Geo-Coordinate according to [GEO] that defines a
>>      point from parameters Latitude, Longitude, and Altitude.
>> 
>>   Geo-Prefix  forms a circle of a geographic area made up of a Geo-
>>      Point and a Radius.  A Geo-Point is known to be "more-specific"
>>      than a Geo-Prefix when its physical location is within the
>>      geographic circle.
> 
> I would add the usual requirement notation section here.
> 
> 
>> 
>> 
> 
> May be make Section 3 and 4 sub sections of a more general “Relevant use-cases” section?
> 
> 
>> 3.  Geo-Points in RLOC-records
>> 
>>   Geo-Points can accompany an RLOC-record to determine the physical
>>   location of an ETR or RTR.  This can aid in determining geographical
>>   distance when topological distance is inaccurate or hidden.  When
>>   Geo-Points are encoded in RLOC-records with RLOC addresses the LCAF
>>   AFI-List Type should be used.
>> 
>>   Geo-Points can be used as the sole piece of information in an RLOC-
>>   record when an EID maps to a Geo-Coordinate.  If it is desirable to
>>   find the geographical location of any EID, this method can be
>>   convenient.
>> 
>>   Here is a high-level use-case where an EID that maps to a Geo-
>>   Coordinate can be used.  Lets say that am EID is assigned to a
> 
> Two typos: Let’s say that an EID….
> 
> 
>>   physical shipping package by a package delivery company.  And the EID
>>   is encoded as an IPv6 address where the tracking number is embedded
>>   in an IPv6 EID.  The network has LISP nodes deployed in many
>>   locations that are configured with their respective Geo-Coordinates.
>>   As the package roams, the LISP node that discovers the EID, registers
>>   it to the LISP mapping system.  The EID-to-RLOC mapping is EID=IPv6
>>   and RLOC=Geo-Coordinate.  If someone does a mapping database lookup
>>   on the IPv6 EID, what is returned is the Geo-Coordinate.  As the EID
>>   roams, new registrations with different Geo-Coordinates are stored,
>>   allowing the physical tracking of the package.
>> 
>> 4.  Geo-Prefixes in EID-records and RLOC-records
>> 
>>   A Geo-Prefix is defined to be a Geo-Coordinate point and a Radius.
>>   This allows a circle to be drawn on a geographic map.  The Geo-Prefix
>>   can describe a coarse physical location for an RLOC when encoded in
>>   an RLOC-record.  So an RLOC could be registered in the mapping
>>   database indicating it is in a city or country versus the exact
>>   location where a Geo-Point would locate it.
>> 
>> 
>> 
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                  [Page 3]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>>   A Geo-Prefix could allow a Distinguished-Name
>>   [I-D.ietf-lisp-name-encoding] to be registered as an EID with an RLOC
>>   that contains a Geo-Prefix.  For example EID="San Francisco", with
>>   RLOC=geo-prefix could be stored in the mapping system.
>> 
>>   A Geo-Prefix, when encoded in an EID-record, could be registered as
>>   an EID-prefix and when a Geo-Point is used as an EID lookup key, a
>>   sort of longest match could be looked up.  If the Geo-Point is in the
>>   Circle described by the Geo-Prefix, an entry is returned to the Map-
>>   Requestor.
> 
> If you have overlapping Geo-prefixes this can have several matches. Would be good to have text describing this case.
> 
> 
>> 
>> 
>>   You could take a combination of mappings from the above examples to
>>   ask the question: "Is the package in San Francisco"?  This could be
>>   done with two lookups to the mapping system:
>> 
>> 
>>   Contents of Mapping Database:
>>     EID=<dist-name="san francisco">
>>     RLOC=<geo-prefix-of-60-mile-radius-of-sf>
>> 
>>     EID=<ipv6-package-tracking-number>
>>     RLOC=<geo-point-of-current-location>
>> 
>>     EID=<geo-prefix-of-60-mile-radius-of-sf>
>>     RLOC=<dist-name="san francisco">
>> 
>>   Map-Request for package:
>>     EID=<ipv6-package-tracking-number>
>>   Mapping system returns:
>>     RLOC=<geo-point-of-current-location>
>> 
>>   Map-Request for geo-point:
>>     EID=<geo-point-of-current-location>
>>   Mapping system longest-match lookup returns:
>>     EID=<geo-prefix-of-60-mile-radius-of-sf>
>>     RLOC=<dist-name="san francisco">
>> 
>> 
>>   If the package was not in San Francisco, the second mapping table
>>   lookup would fail.
>> 
>>   Another application is concentric rings of WiFi access-points.  The
>>   radius of each ring corresponds to the Wifi signal strength.  An EID
>>   could be located in any on the inner rings but possibly on the edge
>>   of a ring.  A WiFi access-point RLOC can be selected to encapsulate
>>   packets to because it will have better signal to the current EID
>>   location.  And when there are intersecting circles, it can be
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                  [Page 4]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>>   determined that when the EID is in the intersection of the circles,
>>   it would be a good time to transition radios to closer APs or base
>>   stations.
>> 
>>   When assigning EIDs to vehicles
>>   [I-D.jeong-its-v2i-problem-statement], a Geo-Prefix could be used to
>>   create a "reachability set" of Road-Side-Units (RSUs).  So an ITR
>>   could encapsulate to multiple RLOCs in the Geo-Prefix to try to
>>   create connectivity to the vehicle while roaming.  This makes use of
>>   predictive RLOCs that can be used when the direction of the roaming
>>   EID is known (a train track or single direction road, but not a
>>   flight path of a plane).
>> 
>> 
>> 5.  Geo-Prefix and Geo-Point Encodings
>> 
>>   When a Geo-Prefix or a Geo-Point are encoded in an EID-record, it is
>>   encoded solely with the Geo-Coordinates LCAF Type format when VPNs
>>   are not in use.  When VPNs are used, the Geo-Coordinate LCAF Type is
>>   encoded within an Instance-ID LCAF Type.
> 
> I found the VPN text superfluous, but if you really want to keep it I would put it at the end of this section. You first define the encoding and than details the VPN case.  
> 
> 
>> 
>> 
>>     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
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |           AFI = 16387         |     Rsvd1     |     Flags     |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |   Type = 5    |     Rsvd2     |            Length             |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> You cannot use type 5. The type has been allocated in RFC 8060 and the associated format already defined there (see also IANA section).
> 
> 
>>    |U|N|E|A|M|R|K|    Reserved     |     Location Uncertainty      |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |  Lat Degrees  |        Latitude Milliseconds                  |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |  Long Degrees |        Longitude Milliseconds                 |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                            Altitude                           |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |             Radius            |          Reserved             |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |              AFI = x          |         Address  ...          |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
> 
> Why you need the “= x” part in the AFI field? 
> 
> 
>> 
>>   Rsvd1/Rsvd2/Flags:  See [RFC8060] for details.
>> 
>>   Length:  length in bytes starting and including the byte after this
>>      Length field.
>> 
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                  [Page 5]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>>   U-bit:  If the U-bit is set, it indicates that the "Location
>>      Uncertainty" field is specified.  
> 
> Rather than “specified” I would say “used and meaningful"
> 
>> If the U-bit is clear, it
>>      indicates the "Location Uncertainty" field is unspecified.
> 
> I would write:
> 
> If the U-bit is clear, the "Location Uncertainty" field  MUST  be set to 0 on transmission  and MUST be ignored on reception.
> 
> The last two comments apply as well to the bit A and R.
> 
> 
> I would use capital letters for North, South, East and West.
> 
> 
>> 
>>   N-bit:  If the N-bit is set, it indicates the Latitude is north
>>      relative to the Equator.  If the N-bit is clear, it indicates the
>>      Latitude is south of the Equator.
>> 
>>   E-bit:  If the E-bit is set, it indicates the Longitude is east of
>>      the Prime Meridian.  If the E-bit is clear, it indicates the
>>      Longitude is west of the Prime Meridian.
>> 
>>   A-bit:  If the A-bit is set, it indicates the "Altitude" field is
>>      specified.  If the A-bit is clear, it indicates the "Altitude"
>>      field is unspecified.
>> 
>>   M-bit:  If the M-bit is set, it indicates the "Altitude" is specified
>>      in meters.  If the M-bit is clear, it indicates the "Altitude" is
>>      in centimeters.
>> 
>>   R-bit:  If the R-bit is set, it indicates the "Radius" field is
>>      specified and the encoding is a Geo-Prefix.  If the R-bit is
>>      clear, it indicates the "Radius" field is unspecified and the
>>      encoding is a Geo-Point.
>> 
>>   K-bit:  If the K-bit is set, it indicates the "Radius" is specified
>>      in kilometers.  If the K-bit is clear, it indicates the "Radius"
>>      is in meters.
>> 
>>   Reserved:  These bits are reserved.  They SHOULD be set to 0 when
>>      sending protocol packets and MUST be ignored when receiving
>>      protocol packets.
> 
> Rephrase: They MUST  be set to 0 on transmission  and MUST be ignored on reception.
> 
> 
>> 
>>   Location Uncertainty:  Unsigned 16-bit integer indicating the number
>>      of centimeters of uncertainty for the location.
> 
> Why not meters? Any reasoning?
> 
> 
>> 
>>   Latitude Degrees:  Unsigned 8-bit integer with a range of 0 - 90
>>      degrees north or south of the Equator (northern or southern
>>      hemisphere, respectively).
>> 
>>   Latitude Milliseconds:  Unsigned 24-bit integer with a range of 0 -
>>      3,599,999 (i.e., less than 60 minutes).
>> 
>>   Longitude Degrees:  Unsigned 8-bit integer with a range of 0 - 180
>>      degrees east or west of the Prime Meridian.
>> 
>>   Longitude Milliseconds:  Unsigned 24-bit integer with a range of 0 -
>>      3,599,999 (i.e., less than 60 minutes).
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                  [Page 6]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>>   Altitude:  Signed 32-bit integer containing the Height relative to
>>      sea level in centimeters or meters.  A negative height indicates
>>      that the location is below sea level.
>> 
>>   Radius:  Unsigned 16-bit integer containing the radius of a circle
>>      (or sphere) centered at the specified coordinates.  The radius is
>>      specified in meters unless the K-bit is specified indicating
>>      radius is in kilometers.  When the radius is specified, this LCAF
>>      type encodes a Geo-Prefix where the geo-coordinates define the
>>      entire area of the circle defined by the radius and center point.
>> 
>>   AFI = x:  x can be any AFI value from [AFI] and [RFC8060].
> 
> Again, why x?
> 
>> 
>> 6.  Security Considerations
> 
> 
> The first 4 paragraph are IMO privacy issues and should go in the privacy section.
> I would put the privacy section before the security one.
> 
>> 
>>   The use of Geo-Coordinates in any application must be considered
>>   carefully to not violate any privacy concerns about physical
>>   location.  This draft does take into consideration the applicability
>>   of BCP160 [RFC6280] for location-based privacy protection.
>> 
>>   In a LISP environment, Geo-Coordinates can be registered to the
>>   Mapping Database System.  When this occurs, an xTR is allowing its
>>   physical location to be known to queriers of the mapping system as
>>   well as network components that make up the mapping system.  There
>>   are various sets of trust relationships that may exist.
>> 
>>   An xTR at a LISP site already has a business and trust relationship
>>   with its Mapping Service Provider (MSP).  When xTRs register their
>>   mappings with Geo-Coordinate information, a policy is agreed upon
>>   about who can access the information.  Typically, the policy is
>>   stored locally and processed by the xTR when the MSP forwards Map-
>>   Requests to the xTRs of the LISP site.  Conditionally, based on the
>>   requesting xTR, the responding xTR can apply the local policy to
>>   decide if a Map-Reply is sent with all RLOC-records, or perhaps, the
>>   RLOC-records that do not contain Geo-Coordinate information.
>> 
>>   The MSP can also be requested by LISP site xTRs to proxy Map-Reply to
>>   Map-Requests.  In this case, the MSP must apply the xTR policy so
>>   only authorized requesters get access to Geo-Coordinate information.
>> 
>>   Note that once a requester is authorized, Map-Replies are returned
>>   directly to the requester and are signed with [I-D.ietf-lisp-sec].
> 
> Don’t we have a RFC number ? ;-)
> 
>>   The Map-Replies not only authenticates the Map-Replier but can be
>>   encrypted by the Map-Replier so no eavesdropping of Geo-Coordinate
>>   information can occur.
>> 
> 
> I would put more words in stating that LISP-Sec or any other protection mechanism should be used to protect the sensible information from eavesdropper.
> 
> Also can you state whether this introduces other security threats in the LISP architecture?
> 
> 
> 
>> 
>> 
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                  [Page 7]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>> 7.  Privacy Considerations
>> 
>>   In addition to controlling where LISP Geo-Coordinate mapping records
>>   go and applying policies [Section 6] for who can access them, there
>>   are additional steps that can be taken to protect threats.
>> 
>>   The suggestions from [RFC6973] can be implemented by existing LISP
>>   features, such as:
>> 
>>   *  Using signatures from [I-D.ietf-lisp-ecdsa-auth] can authenticate
>>      and authorize who can request such mapping records.
>> 
>>   *  Obfuscating a geo-point by using geo-prefixes instead uses data
>>      minimization techniques.
>> 
>>   *  Using short TTLs so the Geo-Coordinate mapping records are
>>      ephemeral reduces the attack window.
>> 
>>   *  Encrypting mapping records with either shared keys or using PKI
>>      [I-D.ietf-lisp-ecdsa-auth] so data is confidential both in transit
>>      to/from and at rest in the mapping system.  Implementations exist
>>      which do encryption for various contract-tracing (virus-related)
>>      applications.
>> 
>>   The typical applicability for the use of Geo-Coordinates will be to
>>   describe physical location for well known public structures, places,
>>   and landmarks versus people, vehicles, and equipment.
>> 
>> 8.  IANA Considerations
>> 
>>   At this time there are no specific requests for IANA.
> 
> You should ask for a new LCAF type.
> Type 5 in RFC 8060 is allocated for a format that already defined there, hence you need a new type value for the new format.
> 
> 
> 
> 
>> 
>> 9.  References
>> 
>> 9.1.  Normative References
>> 
>>   [GEO]      Geodesy and Geophysics Department, DoD., "World Geodetic
>>              System 1984", NIMA TR8350.2, 3 January 2000,
>>              <http://earth-info.nga.mil/GandG/publications/tr8350.2/
>>              wgs84fin.pdf>.
>> 
>>   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
>>              DOI 10.17487/RFC1700, October 1994,
>>              <https://www.rfc-editor.org/info/rfc1700>.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                  [Page 8]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>>   [RFC6280]  Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
>>              Tschofenig, H., and H. Schulzrinne, "An Architecture for
>>              Location and Location Privacy in Internet Applications",
>>              BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011,
>>              <https://www.rfc-editor.org/info/rfc6280>.
>> 
>>   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
>>              Morris, J., Hansen, M., and R. Smith, "Privacy
>>              Considerations for Internet Protocols", RFC 6973,
>>              DOI 10.17487/RFC6973, July 2013,
>>              <https://www.rfc-editor.org/info/rfc6973>.
>> 
>>   [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
>>              Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
>>              February 2017, <https://www.rfc-editor.org/info/rfc8060>.
>> 
>>   [RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
>>              Cabellos, Ed., "The Locator/ID Separation Protocol
>>              (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
>>              <https://www.rfc-editor.org/info/rfc9300>.
>> 
>> 9.2.  Informative References
>> 
>>   [AFI]      "Address Family Identifier (AFIs)", ADDRESS FAMILY
>>              NUMBERS http://www.iana.org/assignments/address-family-
>>              numbers/address-family-numbers.xhtml?, February 2007.
>> 
>>   [I-D.acee-ospf-geo-location]
>>              Lindem, A., Shen, N., and E. Chen, "OSPF Extensions for
>>              Advertising/Signaling Geo Location Information", Work in
>>              Progress, Internet-Draft, draft-acee-ospf-geo-location-05,
>>              18 October 2017, <https://www.ietf.org/archive/id/draft-
>>              acee-ospf-geo-location-05.txt>.
>> 
>>   [I-D.chen-idr-geo-coordinates]
>>              Chen, E., Shen, N., and R. Raszuk, "Carrying Geo
>>              Coordinates in BGP", Work in Progress, Internet-Draft,
>>              draft-chen-idr-geo-coordinates-02, 31 October 2016,
>>              <https://www.ietf.org/archive/id/draft-chen-idr-geo-
>>              coordinates-02.txt>.
>> 
>>   [I-D.ietf-lisp-ecdsa-auth]
>>              Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
>>              Authentication and Authorization", Work in Progress,
>>              Internet-Draft, draft-ietf-lisp-ecdsa-auth-09, 11
>>              September 2022, <https://www.ietf.org/archive/id/draft-
>>              ietf-lisp-ecdsa-auth-09.txt>.
>> 
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                  [Page 9]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>>   [I-D.ietf-lisp-name-encoding]
>>              Farinacci, D., "LISP Distinguished Name Encoding", Work in
>>              Progress, Internet-Draft, draft-ietf-lisp-name-encoding-
>>              00, 6 September 2022, <https://www.ietf.org/archive/id/
>>              draft-ietf-lisp-name-encoding-00.txt>.
>> 
>>   [I-D.ietf-lisp-sec]
>>              Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
>>              "LISP-Security (LISP-SEC)", Work in Progress, Internet-
>>              Draft, draft-ietf-lisp-sec-29, 7 July 2022,
>>              <https://www.ietf.org/archive/id/draft-ietf-lisp-sec-
>>              29.txt>.
>> 
>>   [I-D.jeong-its-v2i-problem-statement]
>>              Jeong, J. P. and T. (. Oh, "Problem Statement for Vehicle-
>>              to-Infrastructure Networking", Work in Progress, Internet-
>>              Draft, draft-jeong-its-v2i-problem-statement-02, 19 July
>>              2016, <https://www.ietf.org/archive/id/draft-jeong-its-
>>              v2i-problem-statement-02.txt>.
>> 
>>   [I-D.shen-isis-geo-coordinates]
>>              Shen, N. and E. Chen, "Carrying Geo Coordinates
>>              Information In IS-IS", Work in Progress, Internet-Draft,
>>              draft-shen-isis-geo-coordinates-04, 18 October 2017,
>>              <https://www.ietf.org/archive/id/draft-shen-isis-geo-
>>              coordinates-04.txt>.
>> 
>> Appendix A.  Acknowledgments
>> 
>>   The author would like to thank the LISP WG for their review and
>>   acceptance of this draft.
>> 
>>   A special thanks goes to Enke Chen, Acee Lindem, and Naiming Shen for
>>   collaboarting on a consistent geo-location encoding format with OSPF
>>   [I-D.acee-ospf-geo-location], IS-IS [I-D.shen-isis-geo-coordinates],
>>   and BGP [I-D.chen-idr-geo-coordinates] protocols.
>> 
>> Appendix B.  Document Change Log
>> 
>>   [RFC Editor: Please delete this section on publication as RFC.]
>> 
>> B.1.  Changes to draft-ietf-lisp-geo-00
>> 
>>   *  Posted November 2022.
>> 
>>   *  Renamed draft-farinacci-lisp-geo-15 to make working group draft.
>> 
>> 
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                 [Page 10]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>> B.2.  Changes to draft-farinacci-lisp-geo-15
>> 
>>   *  Posted November 2022.
>> 
>>   *  Made change to reflect last call comments.  First sentence of
>>      intro and added a Privacy Considerations section.
>> 
>> B.3.  Changes to draft-farinacci-lisp-geo-14
>> 
>>   *  Posted September 2022.
>> 
>>   *  Update document timer and references.
>> 
>> B.4.  Changes to draft-farinacci-lisp-geo-13
>> 
>>   *  Posted March 2022.
>> 
>>   *  Update document timer and references.
>> 
>> B.5.  Changes to draft-farinacci-lisp-geo-12
>> 
>>   *  Posted September 2021.
>> 
>>   *  Update document timer and references.
>> 
>> B.6.  Changes to draft-farinacci-lisp-geo-11
>> 
>>   *  Posted March 2021.
>> 
>>   *  Update document timer and references.
>> 
>> B.7.  Changes to draft-farinacci-lisp-geo-10
>> 
>>   *  Posted October 2020.
>> 
>>   *  Update document timer and references.
>> 
>> B.8.  Changes to draft-farinacci-lisp-geo-09
>> 
>>   *  Posted April 2020.
>> 
>>   *  Update document timer and references.
>> 
>> B.9.  Changes to draft-farinacci-lisp-geo-08
>> 
>>   *  Posted October 2019.
>> 
>>   *  Update document timer and references.
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                 [Page 11]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>> B.10.  Changes to draft-farinacci-lisp-geo-07
>> 
>>   *  Posted April 2019.
>> 
>>   *  Update document timer and references.
>> 
>> B.11.  Changes to draft-farinacci-lisp-geo-06
>> 
>>   *  Posted October 2018.
>> 
>>   *  Update document timer and references.
>> 
>> B.12.  Changes to draft-farinacci-lisp-geo-05
>> 
>>   *  Posted April 2018.
>> 
>>   *  Update document timer and references.
>> 
>> B.13.  Changes to draft-farinacci-lisp-geo-04
>> 
>>   *  Posted October 2017.
>> 
>>   *  Update document timer and references.
>> 
>> B.14.  Changes to draft-farinacci-lisp-geo-03
>> 
>>   *  Posted April 2017.
>> 
>>   *  Update document timer.
>> 
>> B.15.  Changes to draft-farinacci-lisp-geo-02
>> 
>>   *  Posted October 2016.
>> 
>>   *  Change format of the Geo-Coordinates LCAF Type to be compatible
>>      with equivalent proposals for OSPF, IS-IS, and BGP.
>> 
>>   *  Add to the Security Considerations section to BCP160 compliance.
>> 
>> B.16.  Changes to draft-farinacci-lisp-geo-01
>> 
>>   *  Posted October 2016.
>> 
>>   *  Clarify that the Geo-Coordinates LCAF type should be encoded
>>      inside an Instance-ID LCAF type when VPNs are used.
>> 
>> 
>> 
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                 [Page 12]
>> Internet-Draft        LISP Geo-Coordinate Use-Cases        November 2022
>> 
>> 
>>   *  Indicate what the value of the Altitude field is when not included
>>      in a message.  Since this draft shortens the field, a new value is
>>      specified in this draft for not conveying an Altitude value in a
>>      message.
>> 
>> B.17.  Changes to draft-farinacci-lisp-geo-00
>> 
>>   *  Initial draft posted April 2016.
>> 
>> Author's Address
>> 
>>   Dino Farinacci
>>   lispers.net
>>   San Jose, CA
>>   United States of America
>>   Email: [e-mail]
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Farinacci                  Expires 27 May 2023                 [Page 13]
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp