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

[Dino Farinacci <[e-mail]>]

> 
> Hi Dino,
> 
>> On 9 Dec 2022, at 22:20, Dino Farinacci <[e-mail]> wrote:
>> 
>> 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.
> 
> Indeed it has been quite some time….
> 
> If you look Section 4.3 of RFC 8060 you can see Type 5 LCAF Format that is completely incompatible with the specs in this document.

We need to update RFC 8060 so the format in the geo draft matches and points to this use-case draft. That is what we have done with the other LCAF types. So we just need to be consistent.

> What about asking for type 15 and name it “extended Geo-coordinates”?

There is no point to have 2 code points for Geo-Coordinates.

Want me to start on a 8060bis document?

Dino

> 
> Ciao
> 
> L.
> 
> 
> 
>> 
>> 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
>> 
>