--- 1/draft-ietf-netmod-geo-location-02.txt 2020-02-13 12:13:23.723793397 -0800 +++ 2/draft-ietf-netmod-geo-location-03.txt 2020-02-13 12:13:23.767794502 -0800 @@ -1,18 +1,18 @@ Network Working Group C. Hopps Internet-Draft LabN Consulting, L.L.C. -Intended status: Standards Track November 4, 2019 -Expires: May 7, 2020 +Intended status: Standards Track 13 February 2020 +Expires: 16 August 2020 YANG Geo Location - draft-ietf-netmod-geo-location-02 + draft-ietf-netmod-geo-location-03 Abstract This document defines a generic geographical location object YANG grouping. The geographical location grouping is intended to be used in YANG models for specifying a location on or in reference to the Earth or any other astronomical object. Status of This Memo @@ -22,65 +22,63 @@ 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 May 7, 2020. + This Internet-Draft will expire on 16 August 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. + 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 Simplified BSD License text + as described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Geo Location Object . . . . . . . . . . . . . . . . . . . 3 2.1. Frame of Reference . . . . . . . . . . . . . . . . . . . 3 2.2. Location . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Motion . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Nested Locations . . . . . . . . . . . . . . . . . . . . 5 2.5. Non-location Attributes . . . . . . . . . . . . . . . . . 5 2.6. Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. ISO 6709:2008 Conformance . . . . . . . . . . . . . . . . . . 11 5. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Portability . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. IETF URI Value . . . . . . . . . . . . . . . . . . . 13 5.1.2. W3C . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.3. Geography Markup Language (GML) . . . . . . . . . . . 15 - 5.1.4. KML . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.1.4. KML . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1. Geodetic System Value Registry . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 8.2. Informative References . . . . . . . . . . . . . . . . . 19 + 8. Normative References . . . . . . . . . . . . . . . . . . . . 18 + 9. Informative References . . . . . . . . . . . . . . . . . . . 19 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction In many applications we would like to specify the location of something geographically. Some examples of locations in networking might be the location of data center, a rack in an internet exchange point, a router, a firewall, a port on some device, or it could be the endpoints of a fiber, or perhaps the failure point along a fiber. Additionally, while this location is typically relative to The Earth, @@ -111,21 +109,21 @@ 2. The Geo Location Object 2.1. Frame of Reference The frame of reference ("reference-frame") defines what the location values refer to and their meaning. The referred to object can be any astronomical body. It could be a planet such as The Earth or Mars, a moon such as Enceladus, an asteroid such as Ceres, or even a comet such as 1P/Halley. This value is specified in "astronomical-body" and is defined by the International Astronomical Union - (), The default "astronomical-body" value is + (http://www.iau.org), The default "astronomical-body" value is "earth". In addition to identifying the astronomical body we also need to define the meaning of the coordinates (e.g., latitude and longitude) and the definition of 0-height. This is done with a "geodetic-datum" value. The default value for "geodetic-datum" is "wgs-84" (i.e., the World Geodetic System, [WGS84]), which is used by the Global Positioning System (GPS) among many others. We define an IANA registry for specifying standard values for the "geodetic-datum". @@ -141,27 +139,26 @@ system. The use of this value is intended to allow for creating virtual realities or perhaps alternate coordinate systems. The definition of alternate systems is outside the scope of this document. 2.2. Location This is the location on or relative to the astronomical object. It is specified using 2 or 3 coordinates values. These values are given either as "latitude", "longitude", and an optional "height", or as - Cartesian coordinates of "x", "y" and an optional "z". For the - standard location choice "latitude" and "longitude" are specified as - fractions of decimal degrees, and the "height" value is in fractions - of meters. For the Cartesian choice "x", "y" and "z" are in - fractions of meters. In both choices the exact meanings of all of - the values are defined by the "geodetic-datum" value in the - Section 2.1. + Cartesian coordinates of "x", "y" and "z". For the standard location + choice "latitude" and "longitude" are specified as fractions of + decimal degrees, and the "height" value is in fractions of meters. + For the Cartesian choice "x", "y" and "z" are in fractions of meters. + In both choices the exact meanings of all of the values are defined + by the "geodetic-datum" value in the Section 2.1. 2.3. Motion Support is added for objects in relatively stable motion. For objects in relatively stable motion the grouping provides a 3-dimensional vector value. The components of the vector are "v-north", "v-east" and "v-up" which are all given in fractional meters per second. The values "v-north" and "v-east" are relative to true-north as defined by the reference frame for the astronomical body, "v-up" is perpendicular to the plane defined by "v-north" and @@ -218,34 +215,33 @@ +-- geo-location +-- reference-frame | +-- alternate-system? string {alternate-systems}? | +-- astronomical-body? string | +-- geodetic-system | +-- geodetic-datum? string | +-- coord-accuracy? decimal64 | +-- height-accuracy? decimal64 +-- (location)? | +--:(ellipsoid) - | | +-- latitude? degrees - | | +-- longitude? degrees + | | +-- latitude? decimal64 + | | +-- longitude? decimal64 | | +-- height? decimal64 | +--:(cartesian) | +-- x? decimal64 | +-- y? decimal64 | +-- z? decimal64 +-- velocity | +-- v-north? decimal64 | +-- v-east? decimal64 | +-- v-up? decimal64 +-- timestamp? types:date-and-time - - Figure 1: Geo Location YANG tree diagram. + +-- valid-until? types:date-and-time 3. YANG Module file "ietf-geo-location@2019-02-17.yang" module ietf-geo-location { namespace "urn:ietf:params:xml:ns:yang:ietf-geo-location"; prefix geo; import ietf-yang-types { prefix types; } organization @@ -282,28 +278,20 @@ NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2019-02-17 { description "Initial Revision"; reference "RFC XXXX: YANG Geo Location"; } - typedef degrees { - type decimal64 { - fraction-digits 16; - } - units "decimal degrees"; - description "Coordinate value."; - } - feature alternate-systems { description "This feature means the device supports specifying locations using alternate systems for reference frames."; } grouping geo-location { description "Grouping to identify a location on an astronomical object."; @@ -335,22 +323,22 @@ default "earth"; description "An astronomical body as named by the International Astronomical Union (IAU) or according to the alternate system if specified. Examples include 'sun' (our star), 'earth' (our planet), 'moon' (our moon), 'enceladus' (a moon of Saturn), 'ceres' (an asteroid), '67p/churyumov-gerasimenko (a comet). The value should be comprised of all lower case ASCII characters not including control characters (i.e., values 32..64, and - 91..126). Any preceding 'the' in the name should not - be included."; + 91..126). Any preceding 'the' in the name should not be + included."; } container geodetic-system { description "The geodetic system of the location data."; leaf geodetic-datum { type string { pattern '[ -@\[-\^_-~]*'; } default "wgs-84"; description @@ -360,104 +348,104 @@ SHOULD be comprised of all lower case ASCII characters not including control characters (i.e., values 32..64, and 91..126). The IANA registry further restricts the value by converting all spaces (' ') to dashes ('-')"; } leaf coord-accuracy { type decimal64 { fraction-digits 6; } description - "The accuracy of the latitude longitude pair. When - coord-accuracy is specified it overrides the - geodetic-datum implied accuracy. If Cartesian - coordinates are in use this accuracy corresponds to - the X and Y components"; + "The accuracy of the latitude longitude pair for + ellipsoidal coordinates, or the X, Y and Z components + for Cartesian coordinates. When coord-accuracy is + specified it overrides the geodetic-datum implied + accuracy."; } leaf height-accuracy { type decimal64 { fraction-digits 6; } units "meters"; description - "The accuracy of height value. When specified it - overrides the geodetic-datum implied default. If - Cartesian coordinates ar in use this accuracy - corresponds to the Z component."; + "The accuracy of height value for ellipsoidal + coordinates, this value is not used with Cartesian + coordinates. When specified it overrides the + geodetic-datum implied default."; } - // May wish to allow for height to be relative. - // If so need to decide if we have a boolean (to ground) - // or an enumeration (e.g., local ground, sea-floor, - // ground floor, containing object, ...) or even allow - // for a string for most generic but least portable - // comparable - // leaf height-relative { - // } } } choice location { description "The location data either in lat/long or Cartesian values"; case ellipsoid { leaf latitude { - type degrees; + type decimal64 { + fraction-digits 16; + } + units "decimal degrees"; description "The latitude value on the astronomical body. The definition and precision of this measurement is indicated by the reference-frame value."; } leaf longitude { - type degrees; + type decimal64 { + fraction-digits 16; + } + units "decimal degrees"; description "The longitude value on the astronomical body. The definition and precision of this measurement is indicated by the reference-frame."; } leaf height { type decimal64 { fraction-digits 6; } units "meters"; description "Height from a reference 0 value. The precision and '0' value is defined by the reference-frame."; } } case cartesian { leaf x { type decimal64 { fraction-digits 6; } + units "meters"; description "The X value as defined by the reference-frame."; } leaf y { type decimal64 { fraction-digits 6; } + units "meters"; description "The Y value as defined by the reference-frame."; } leaf z { type decimal64 { fraction-digits 6; } units "meters"; description "The Z value as defined by the reference-frame."; } } } container velocity { description "If the object is in motion the velocity vector describes - this motion at the the time given by the timestamp."; + this motion at the the time given by the timestamp"; leaf v-north { type decimal64 { fraction-digits 12; } units "meters per second"; description "v-north is the rate of change (i.e., speed) towards truth north as defined by the ~geodetic-system~."; } @@ -479,54 +466,61 @@ units "meters per second"; description "v-up is the rate of change (i.e., speed) away from the center of mass."; } } leaf timestamp { type types:date-and-time; description "Reference time when location was recorded."; } + leaf valid-until { + type types:date-and-time; + description + "The timestamp for which this geo-location is valid until. + If unspecified the geo-location has no specific expiration + time."; + } } } } 4. ISO 6709:2008 Conformance [ISO.6709.2008] provides an appendix with a set of tests for conformance to the standard. The tests and results are given in the following table along with an explanation of non-applicable tests. - +---------+-----------------------------------+---------------------+ + +---------+----------------------+------------------+ | Test | Description | Pass Explanation | - +---------+-----------------------------------+---------------------+ - | A.1.2.1 | elements reqd. for a geo. point | CRS is always | - | | location | indicated | - | | | | - | A.1.2.2 | Description of a CRS from a | CRS register is | - | | register | defined | - | | | | - | A.1.2.3 | definition of CRS | N/A - Don't define | - | | | CRS | - | | | | - | A.1.2.4 | representation of horizontal | lat/long values | - | | position | conform | - | | | | - | A.1.2.5 | representation of vertical | height value | - | | position | conforms | - | | | | - | A.1.2.6 | text string representation | N/A - No string | - | | | format | - +---------+-----------------------------------+---------------------+ + +=========+======================+==================+ + | A.1.2.1 | elements reqd. for a | CRS is always | + | | geo. point location | indicated | + +---------+----------------------+------------------+ + | A.1.2.2 | Description of a CRS | CRS register is | + | | from a register | defined | + +---------+----------------------+------------------+ + | A.1.2.3 | definition of CRS | N/A - Don't | + | | | define CRS | + +---------+----------------------+------------------+ + | A.1.2.4 | representation of | lat/long values | + | | horizontal position | conform | + +---------+----------------------+------------------+ + | A.1.2.5 | representation of | height value | + | | vertical position | conforms | + +---------+----------------------+------------------+ + | A.1.2.6 | text string | N/A - No string | + | | representation | format | + +---------+----------------------+------------------+ - Conformance Test Results + Table 1: Conformance Test Results For test "A.1.2.1" the YANG geo location object either includes a CRS ("reference-frame") or has a default defined ([WGS84]). For "A.1.2.3" we do not define our own CRS, and doing so is not required for conformance. For "A.1.2.6" we do not define a text string representation, which is also not required for conformance. @@ -558,89 +552,88 @@ all the location values. As the URI is a string, all values are specifies as strings and so are capable of as much precision as required. URI values can be mapped to and from the YANG grouping, with the caveat that some loss of precision (in the extremes) may occur due to the YANG grouping using decimal64 values rather than strings. 5.1.2. W3C - See . + See https://w3c.github.io/geolocation-api/#dom-geolocationposition. W3C Defines a geo-location API in [W3CGEO]. We show a snippet of code below which defines the geo-location data for this API. This is used by many application (e.g., Google Maps API). interface GeolocationPosition { readonly attribute GeolocationCoordinates coords; readonly attribute DOMTimeStamp timestamp; }; interface GeolocationCoordinates { readonly attribute double latitude; readonly attribute double longitude; readonly attribute double? altitude; readonly attribute double accuracy; readonly attribute double? altitudeAccuracy; readonly attribute double? speed; }; - Figure 2: Snippet Showing Geo-Location Definition + Figure 1: Snippet Showing Geo-Location Definition 5.1.2.1. Compare with YANG Model +------------------+--------------+-----------------+-------------+ | Field | Type | YANG | Type | - +------------------+--------------+-----------------+-------------+ + +==================+==============+=================+=============+ | accuracy | double | coord-accuracy | dec64 fr 6 | - | | | | | + +------------------+--------------+-----------------+-------------+ | altitude | double | height | dec64 fr 6 | - | | | | | + +------------------+--------------+-----------------+-------------+ | altitudeAccuracy | double | height-accuracy | dec64 fr 6 | - | | | | | - | heading | double | heading | dec64 fr 16 | - | | | | | + +------------------+--------------+-----------------+-------------+ + | heading | double | v-north, v-east | dec64 fr 12 | + +------------------+--------------+-----------------+-------------+ | latitude | double | latitude | dec64 fr 16 | - | | | | | + +------------------+--------------+-----------------+-------------+ | longitude | double | longitude | dec64 fr 16 | - | | | | | - | speed | double | speed | dec64 fr 12 | - | | | | | + +------------------+--------------+-----------------+-------------+ + | speed | double | v-north, v-east | dec64 fr 12 | + +------------------+--------------+-----------------+-------------+ | timestamp | DOMTimeStamp | timestamp | string | +------------------+--------------+-----------------+-------------+ - accuracy (double): - Accuracy of "latitude" and "longitude" values in meters. + Table 2 - altitude (double): - Optional height in meters above the [WGS84] ellipsoid. + accuracy (double) Accuracy of "latitude" and "longitude" values in + meters. - altitudeAccuracy (double): - Optional accuracy of "altitude" value in meters. + altitude (double) Optional height in meters above the [WGS84] + ellipsoid. - heading (double): - Optional Direction in decimal deg from true north increasing - clock-wise. + altitudeAccuracy (double) Optional accuracy of "altitude" value in + meters. - latitude, longitude (double): - Standard lat/long values in decimal degrees. + heading (double) Optional Direction in decimal deg from true north + increasing clock-wise. - speed (double): - Speed along heading in meters per second. + latitude, longitude (double) Standard lat/long values in decimal + degrees. - timestamp (DOMTimeStamp): - Specifies milliseconds since the Unix EPOCH in 64 bit unsigned - integer. The YANG model defines the timestamp with arbitrarily - large precision by using a string which encompasses all - representable values of this timestamp value. + speed (double) Speed along heading in meters per second. + + timestamp (DOMTimeStamp) Specifies milliseconds since the Unix EPOCH + in 64 bit unsigned integer. The YANG model defines the timestamp + with arbitrarily large precision by using a string which + encompasses all representable values of this timestamp value. W3C API values can be mapped to the YANG grouping, with the caveat that some loss of precision (in the extremes) may occur due to the YANG grouping using decimal64 values rather than doubles. Conversely, only YANG values for The Earth using the default "wgs-84" [WGS84] as the "geodetic-datum", can be directly mapped to the W3C values, as W3C does not provide the extra features necessary to map the broader set of values supported by the YANG grouping. @@ -667,39 +660,41 @@ Conversely, YANG grouping values can be mapped to GML as directly as the GML CRS available definitions allow with a minimum of Earth-based geodetic systems fully supported. GML also defines an observation value in "gml:Observation" which includes a timestamp value "gml:validTime" in addition to other components such as "gml:using" "gml:target" and "gml:resultOf". Only the timestamp is mappable to and from the YANG grouping. Furthermore "gml:validTime" can either be an Instantaneous measure - ("gml:TimeInstant") or a time period ("gml:TimePeriod"). Only the + ("gml:TimeInstant") or a time period ("gml:TimePeriod"). The instantaneous "gml:TimeInstant" is mappable to and from the YANG - grouping. + grouping "timestamp" value, and values down to the resolution of + seconds for "gml:TimePeriod" can be mapped using the using the + "valid-for" node of the YANG grouping. 5.1.4. KML KML 2.2 [KML22] (formerly Keyhole Markup Language) was submitted by Google to Open Geospatial Consortium (OGC) - and was adopted. The latest - version as of this writing is KML 2.3 [KML23]. This schema includes - geographic location data in some of it's objects (e.g., objects). This data is provided in string format and + https://www.opengeospatial.org/ and was adopted. The latest version + as of this writing is KML 2.3 [KML23]. This schema includes + geographic location data in some of its objects (e.g., "kml:Point" or + "kml:Camera" objects). This data is provided in string format and corresponds to the [W3CGEO] values. The timestamp value is also specified as a string as in our YANG grouping. KML has some special handling for the height value useful for visualization software, "kml:altitudeMode". These values for "kml:altitudeMode" include indicating the height is ignored - ("clampToGround"), in relation to the locations ground level + ("clampToGround"), in relation to the location's ground level ("relativeToGround"), or in relation to the geodetic datum ("absolute"). The YANG grouping can directly map the ignored and absolute cases, but not the relative to ground case. In addition to the "kml:altitudeMode" KML also defines two seafloor height values using "kml:seaFloorAltitudeMode". One value is to ignore the height value ("clampToSeaFloor") and the other is relative ("relativeToSeaFloor"). As with the "kml:altitudeMode" value, the YANG grouping supports the ignore case but not the relative case. @@ -736,136 +731,130 @@ more precise definition of the data is required. It should be noted that [RFC5870] also creates a registry for Geodetic Systems (it calls CRS); however, this registry has a very strict modification policy. The authors of [RFC5870] have the stated goal of making CRS registration hard to avoid proliferation of CRS values. As our module defines alternate systems and has a broader (beyond earth) scope, the registry defined below is meant to be more easily modified. - TODO: Open question, should we create a new registry here or attempt - to modify the one created by [RFC5870]. It's worth noting that we - include the ability to specify any geodetic system including ones - designed for astronomical bodies other than the earth, as well as - ones based on alternate systems. These requirements may be too broad - for adapting the existing [RFC5870] registry. - - TODO: Open question, is FCFS too easy, perhaps expert review would - strike a good balance. If expert review is acceptable, would it also - be acceptable to update the policy on [RFC5870] and use it instead? - The allocation policy for this registry is First Come First Served, [RFC8126] as the intent is simply to avoid duplicate values. The initial values for this registry are as follows. +------------+------------------------------------------------------+ | Name | Description | - +------------+------------------------------------------------------+ + +============+======================================================+ | me | Mean Earth/Polar Axis (Moon) | - | | | + +------------+------------------------------------------------------+ | mola-vik-1 | MOLA Height, IAU Viking-1 PM (Mars) | - | | | + +------------+------------------------------------------------------+ | wgs-84-96 | World Geodetic System 1984 [WGS84] w/ EGM96 | - | | | + +------------+------------------------------------------------------+ | wgs-84-08 | World Geodetic System 1984 [WGS84] w/ [EGM08] | - | | | - | wgs-84 | World Geodetic System 1984 [WGS84] (EGM96 or better) | + +------------+------------------------------------------------------+ + | wgs-84 | World Geodetic System 1984 [WGS84] (EGM96 or | + | | better) | +------------+------------------------------------------------------+ + Table 3 + 7. Security Considerations This document defines a common geo location grouping using the YANG data modeling language. The grouping itself has no security or privacy impact on the Internet, but the usage of the grouping in concrete YANG modules might have. The security considerations spelled out in the YANG 1.1 specification [RFC7950] apply for this document as well. -8. References - -8.1. Normative References +8. Normative References - [EGM08] Pavlis, N., Holmes, S., Kenyon, S., and J. Factor, "An - Earth Gravitational Model to Degree 2160: EGM08.", 2008, + [EGM08] Pavlis, N.K., Holmes, S.A., Kenyon, S.C., and J.K. Factor, + "An Earth Gravitational Model to Degree 2160: EGM08.", + Presented at the 2008 General Assembly of the European + Geosciences Union, Vienna, Arpil13-18, 2008, 2008, . - [EGM96] Lemoine, F., Kenyon, S., Factor, J., Trimmer, R., Pavlis, - N., Chinn, D., Cox, C., Klosko, S., Luthcke, S., Torrence, - M., Wang, Y., Williamson, R., Pavlis, E., Rapp, R., and T. - Olson, "The Development of the Joint NASA GSFC and the - National Imagery and Mapping Agency (NIMA) Geopotential - Model EGM96.", 1998, + [EGM96] Lemoine, F.G., Kenyon, S.C., Factor, J.K., Trimmer, R.G., + Pavlis, N.K., Chinn, D.S., Cox, C.M., Klosko, S.M., + Luthcke, S.B., Torrence, M.H., Wang, Y.M., Williamson, + R.G., Pavlis, E.C., Rapp, R.H., and T.R. Olson, "The + Development of the Joint NASA GSFC and the National + Imagery and Mapping Agency (NIMA) Geopotential Model + EGM96.", Technical Report NASA/TP-1998-206861, NASA, + Greenbelt., 1998, . [ISO.6709.2008] International Organization for Standardization, "ISO 6709:2008 Standard representation of geographic point location by coordinates.", 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [WGS84] National Imagery and Mapping Agency., "National Imagery and Mapping Agency Technical Report 8350.2, Third - Edition.", 1 2000, . -8.2. Informative References +9. Informative References [ISO.19136.2007] International Organization for Standardization, "ISO 19136:2007 Geographic information -- Geography Markup Language (GML)". - [KML22] Wilson, T., Ed., "OGC KML (Version 2.2)", 4 2008, + [KML22] Wilson, T., Ed., "OGC KML (Version 2.2)", 14 April 2008, . - [KML23] Burggraf, D., Ed., "OGC KML 2.3", 8 2015, + [KML23] Burggraf, D., Ed., "OGC KML 2.3", 4 August 2015, . [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, DOI 10.17487/RFC5870, June 2010, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . - [W3CGEO] Popescu, A., "Geolocation API Specification", 11 2016, - . + [W3CGEO] Popescu, A., "Geolocation API Specification", 8 November + 2016, . Appendix A. Examples Below is a fictitious module that uses the geo-location grouping. module example-uses-geo-location { namespace "urn:example:example-uses-geo-location"; prefix ugeo; import ietf-geo-location { prefix geo; } @@ -880,56 +869,56 @@ description "A of locatable item"; leaf name { type string; description "name of locatable item"; } uses geo:geo-location; } } } - Figure 3: Example YANG module using geo location. + Figure 2: Example YANG module using geo location. Below is a the YANG tree for the fictitious module that uses the geo- location grouping. module: example-uses-geo-location +--rw locatable-items +--rw locatable-item* [name] +--rw name string +--rw geo-location +--rw reference-frame | +--rw alternate-system? string {alternate-systems}? | +--rw astronomical-body? string | +--rw geodetic-system | +--rw geodetic-datum? string | +--rw coord-accuracy? decimal64 | +--rw height-accuracy? decimal64 +--rw (location)? | +--:(ellipsoid) - | | +--rw latitude? degrees - | | +--rw longitude? degrees + | | +--rw latitude? decimal64 + | | +--rw longitude? decimal64 | | +--rw height? decimal64 | +--:(cartesian) | +--rw x? decimal64 | +--rw y? decimal64 | +--rw z? decimal64 +--rw velocity | +--rw v-north? decimal64 | +--rw v-east? decimal64 | +--rw v-up? decimal64 +--rw timestamp? types:date-and-time + +--rw valid-until? types:date-and-time Below is some example YANG XML data for the fictitious module that uses the geo-location grouping. - Gaetana's 40.73297 -74.007696 Pont des Arts @@ -967,28 +956,26 @@ moon me - - Figure 4: Example XML data of geo location use. + Figure 3: Example XML data of geo location use. Appendix B. Acknowledgements - We would like to thank Peter Lothberg for the motivation as well as - help in defining a more broadly useful geographic location object. - - We would also like to thank Acee Lindem and Qin Wu for their work on - a geographic location object that led to this documents creation. + We would like to thank Jim Biard and Ben Koziol for their reviews and + suggested improvements. We would also like to thank Peter Lothberg + for the motivation as well as help in defining a broadly useful + geographic location object, and Acee Lindem and Qin Wu for their work + on a geographic location object that led to this documents creation. Author's Address - Christian Hopps LabN Consulting, L.L.C. Email: chopps@chopps.org