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

[Luigi Iannone <[e-mail]>]

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]