> > Hi Dino, > >> On 9 Dec 2022, at 22:20, Dino Farinacci <farina...@gmail.com> 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 <g...@gigix.net> 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: farina...@gmail.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Farinacci Expires 27 May 2023 [Page 13] >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
