<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?> <?rfc toc="yes"?> <?rfc compact="no"?> <?rfc subcompact="no"?> <?rfc symrefs="yes" ?> <?rfc sortrefs="yes"?> <?rfc iprnotified="no"?> <?rfc strict="yes"?><!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc ipr="trust200902"category="std"docName="draft-ietf-netmod-geo-location-11" number="9179" submissionType="IETF" category="std" consensus="true" updates="" obsoletes="" xmlns:xi="http://www.w3.org/2001/XInclude" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" version="3"> <front> <title abbrev="A YANG Grouping for Geographic Locations">A YANG Grouping for Geographic Locations</title> <seriesInfo name="RFC" value="9179"/> <author initials='C.' surname='Hopps' fullname='Christian Hopps'><organization>LabN Consulting, L.L.C.</organization><address><email>chopps@chopps.org</email></address></author><date/><abstract><t>This<date year="2022" month="February" /> <keyword>geolocation</keyword> <abstract><t>This document defines a generic geographical location YANG grouping. The geographical location grouping is intended to be used in YANG data models for specifying a location on or in reference to Earth or any other astronomical object.</t></abstract> </front> <middle> <section title="Introduction"> <t>In manyapplicationsapplications, we would like to specify the location of something geographically. Some examples of locations in networking might be the location of datacenter,centers, a rack in aninternetInternet 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.</t> <t>Additionally, while this location is typically relative to Earth, it does not need to be. Indeed, it is easy to imagine a network or device located onThethe Moon, on Mars, on Enceladus (the moon ofSaturn)Saturn), or even on a comet (e.g., 67p/churyumov-gerasimenko).</t> <t>Finally, one can imagine defining locations using different frames of reference or even alternate systems (e.g., simulations or virtual realities).</t> <t>This document defines a<tt>geo-location</tt>'<tt>geo-location</tt>' YANG grouping that allows for all the above data to be captured.</t> <t>This specification conforms to <xref target="ISO.6709.2008"/>.</t> <t>The YANG data model described in this document conforms to the Network Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t> <section title="Terminology"><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <section title="TheGeo LocationGeolocation Object"> <section title="Frame of Reference" anchor="sec-frame-of-reference"> <t>The frame of reference(<tt>reference-frame</tt>)('<tt>reference-frame</tt>') defines what the location values refer to and their meaning. Thereferred toreferred-to object can be any astronomical body. It could be a planet such as 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<tt>astronomical-body</tt>'<tt>astronomical-body</tt>' and is defined by the <ereftarget="http://www.iau.org">Internationaltarget="http://www.iau.org" brackets="angle">International Astronomical Union</eref>. The default<tt>astronomical-body</tt>'<tt>astronomical-body</tt>' value is<tt>earth</tt>.</t>'<tt>earth</tt>'.</t> <t>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<tt>geodetic-datum</tt>'<tt>geodetic-datum</tt>' value. The default value for<tt>geodetic-datum</tt>'<tt>geodetic-datum</tt>' is<tt>wgs-84</tt>'<tt>wgs-84</tt>' (i.e., the World GeodeticSystem,System <xref target="WGS84"/>), which is used by the Global Positioning System (GPS) among many others. We define an IANA registry for specifying standard values for the<tt>geodetic-datum</tt>.</t>'<tt>geodetic-datum</tt>'.</t> <t>In addition to the<tt>geodetic-datum</tt>'<tt>geodetic-datum</tt>' value, we allow overriding the coordinate and height accuracy using<tt>coord-accuracy</tt>'<tt>coord-accuracy</tt>' and<tt>height-accuracy</tt>'<tt>height-accuracy</tt>', respectively. When specified, these values override the defaults implied by the<tt>geodetic-datum</tt>'<tt>geodetic-datum</tt>' value.</t> <t>Finally, we define an optional featurewhichthat allows for changing the system for which the above values are defined. This optional feature adds an<tt>alternate-system</tt>'<tt>alternate-system</tt>' value to the reference frame. This value is normally notpresentpresent, which implies the natural universe is the 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.</t> </section> <section title="Location"> <t>This is the location on, or relative to, the astronomical object. It is specified using2two or3 coordinatesthree coordinate values. These values are given either as<tt>latitude</tt>, <tt>longitude</tt>,'<tt>latitude</tt>', '<tt>longitude</tt>', and an optional<tt>height</tt>,'<tt>height</tt>', or as Cartesian coordinates of<tt>x</tt>, <tt>y</tt>'<tt>x</tt>', '<tt>y</tt>', and<tt>z</tt>.'<tt>z</tt>'. For the standard locationchoice <tt>latitude</tt>choice, '<tt>latitude</tt>' and<tt>longitude</tt>'<tt>longitude</tt>' are specified as decimal degrees, and the<tt>height</tt>'<tt>height</tt>' value is in fractions of meters. For the Cartesianchoice <tt>x</tt>, <tt>y</tt>choice, '<tt>x</tt>', '<tt>y</tt>', and<tt>z</tt>'<tt>z</tt>' are in fractions of meters. In bothchoiceschoices, the exact meanings of all the values are defined by the<tt>geodetic-datum</tt>'<tt>geodetic-datum</tt>' value inthe<xref target="sec-frame-of-reference"></xref>.</t> </section> <section title="Motion"> <t>Support is added for objects in relatively stable motion. For objects in relatively stablemotionmotion, the grouping provides a3-dimensionalthree-dimensional vector value. The components of the vector are<tt>v-north</tt>, <tt>v-east</tt>'<tt>v-north</tt>', '<tt>v-east</tt>', and<tt>v-up</tt>'<tt>v-up</tt>', which are all given in fractional meters per second. The values<tt>v-north</tt>'<tt>v-north</tt>' and<tt>v-east</tt>'<tt>v-east</tt>' are relative to true north as defined by the reference frame for the astronomicalbody, <tt>v-up</tt>body; '<tt>v-up</tt>' is perpendicular to the plane defined by<tt>v-north</tt>'<tt>v-north</tt>' and<tt>v-east</tt>,'<tt>v-east</tt>', and is pointed away from the center of mass.</t> <t>To derive the2-dimensionaltwo-dimensional heading andspeedspeed, one would use the following formulas:</t> <artwork><![CDATA[ ,------------------------------ speed = V v_{north}^{2} + v_{east}^{2} heading = arctan(v_{east} / v_{north}) ]]></artwork> <t>For some applications that demand highaccuracy,accuracy and where the data is infrequentlyupdatedupdated, this velocity vector can track very slow movement such as continental drift.</t> <t>Tracking more complex forms of motion is outside the scope of this work. The intent of the grouping being defined here is to identify where something is located, and generally this is expected to be somewhere on, or relative to, Earth (or another astronomical body). At least two options are available to YANG data models that wish to use this grouping with objects that are changing location frequently in non-simple ways.TheyA data model can either add additional motion data totheirits modeldirectly. Or,directly, or if the application allows, it can require more frequent queries to keep the location datacurrent.</t>current. </t> </section> <section title="Nested Locations"> <t>When locations are nested (e.g., a building may have a locationwhichthat houses routers that also havelocations)locations), the module using this grouping is free to indicate in its definition that the<tt>reference-frame</tt>'<tt>reference-frame</tt>' is inherited from the containing object so that the<tt>reference-frame</tt>'<tt>reference-frame</tt>' need not be repeated in every instance of location data.</t> </section> <section title="Non-location Attributes"> <t>During the development of this module, the question of whether it would support data such as orientation arose. These types of attributes are outside the scope of this grouping because they do not deal with a location but rather describe something more about the object that is at the location. Module authors are free to add these non-location attributes along with their use of this location grouping.</t> </section> <section title="Tree"> <t>The following is the YANG tree diagram <xref target="RFC8340"/> for the geo-location grouping.</t><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-geo-location groupinggeo-locationgeo-location: +-- 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? decimal64 | | +-- longitude? decimal64 | | +-- height? decimal64 | +--:(cartesian) | +-- x? decimal64 | +-- y? decimal64 | +-- z? decimal64 +-- velocity | +-- v-north? decimal64 | +-- v-east? decimal64 | +-- v-up? decimal64 +-- timestamp? yang:date-and-time +-- valid-until? yang:date-and-time]]></artwork>]]></sourcecode> </section> </section> <section title="YANG Module"> <t>This model imports Common YANG Data Types <xref target="RFC6991"/>. It uses YANG version 1.1 <xreftarget="RFC7950"/></t> <sourcecode><![CDATA[ <CODE BEGINS> file "ietf-geo-location@2019-02-17.yang"target="RFC7950"/>.</t> <sourcecode name="ietf-geo-location@2022-2-7.yang" type="yang" markers="true"><![CDATA[ module ietf-geo-location { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-geo-location"; prefix geo; import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG DataTypes.";Types"; } organization "IETF NETMOD Working Group (NETMOD)"; contact "WG Web: <https://datatracker.ietf.org/wg/netmod/> WG List: <mailto:netmod@ietf.org> Editor: Christian Hopps <mailto:chopps@chopps.org>";// RFC Ed.: replace XXXX with actual RFC number or IANA reference // and remove this note.description "This module defines a grouping of a container object for specifying a location on or around an astronomical object (e.g., 'earth'). The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 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. Copyright (c)20192022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, theSimplifiedRevised BSD License set forth in Section4.c4.e of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX (https://www.rfc-editor.org/info/rfcXXXX);9179 (https://www.rfc-editor.org/info/rfc9179); see the RFC itself for full legalnotices. // RFC Ed.: replace XXXX with the actual RFC number or IANA // reference and remove this note. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 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.";notices."; revision2019-02-172022-2-7 { description "Initial Revision"; reference "RFCXXXX:9179: A YANG Grouping for Geographic Locations"; } 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."; container geo-location { description "A location on an astronomical body (e.g., 'earth') somewhere in a universe."; container reference-frame { description "The Frame of Reference for the location values."; leaf alternate-system { if-featurealternate-systems;"alternate-systems"; type string; description "The system in which the astronomical body and geodetic-datum is defined. Normally, this value is not present and the system is the natural universe; however, whenpresentpresent, this value allows for specifying alternate systems (e.g., virtual realities). An alternate-system modifies the definition (but not the type) of the other values in the reference frame."; } leaf astronomical-body { type string { pattern '[ -@\[-\^_-~]*'; } 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), and '67p/churyumov-gerasimenko (a comet). The ASCII value SHOULD haveupper caseuppercase converted tolower caselowercase and not include control characters (i.e., values 32..64, and 91..126). Any preceding 'the' in the name SHOULD NOT be included."; reference "https://www.iau.org/"; } container geodetic-system { description "The geodetic system of the location data."; leaf geodetic-datum { type string { pattern '[ -@\[-\^_-~]*'; } description "A geodetic-datum defining the meaning of latitude,longitudelongitude, and height. The default when the astronomical body is 'earth' is'wgs-84''wgs-84', which is used by the Global Positioning System (GPS). The ASCII value SHOULD haveupper caseuppercase converted tolower caselowercase and not include control characters (i.e., values 32..64, and 91..126). The IANA registry further restricts the value by converting all spaces (' ') to dashes ('-'). The specification for the geodetic-datum indicates how accurately it models the astronomical body in question, both for the 'horizontal' latitude/longitude coordinates and for height coordinates."; reference"IANA XXXX"RFC 9179: A YANG Grouping for GeographicLocation Parameters, Geodetic System Values";Locations, Section 6.1"; } leaf coord-accuracy { type decimal64 { fraction-digits 6; } description "The accuracy of thelatitude longitudelatitude/longitude pair for ellipsoidal coordinates, or the X,YY, and Z components for Cartesian coordinates. When coord-accuracy is specified, it indicates how precisely the coordinates in the associated list of locations have been determined with respect to the coordinate system defined by the geodetic-datum. For example, there might be uncertainty due to measurement error if an experimental measurement was made to determine each location."; } leaf height-accuracy { type decimal64 { fraction-digits 6; } units "meters"; description "The accuracy of the height value for ellipsoidalcoordinates,coordinates; this value is not used with Cartesian coordinates. When height-accuracy is specified, it indicates how precisely the heights in the associated list of locations have been determined with respect to the coordinate system defined by the geodetic-datum. For example, there might be uncertainty due to measurement error if an experimental measurement was made to determine each location."; } } } choice location { description "The location data either inlat/longlatitude/longitude or Cartesian values"; case ellipsoid { leaf latitude { 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."; } leaf longitude { 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 inmotionmotion, the velocity vector describes this motion at thethetime given by the timestamp. For a formula to convert these values to speed andheadingheading, see RFCXXXX.";9179."; reference "RFCXXXX:9179: A YANG Grouping for Geographic Locations"; leaf v-north { type decimal64 { fraction-digits 12; } units "meters per second"; description "v-north is the rate of change (i.e., speed) towardstruthtrue north as defined by the geodetic-system."; } leaf v-east { type decimal64 { fraction-digits 12; } units "meters per second"; description "v-east is the rate of change (i.e., speed) perpendicular to the right of true north as defined by the geodetic-system."; } leaf v-up { type decimal64 { fraction-digits 12; } units "meters per second"; description "v-up is the rate of change (i.e., speed) away from the center of mass."; } } leaf timestamp { type yang:date-and-time; description "Reference time when location was recorded."; } leaf valid-until { type yang:date-and-time; description "The timestamp for which this geo-location is valid until. Ifunspecifiedunspecified, the geo-location has no specific expiration time."; } } } }<CODE ENDS>]]></sourcecode> </section> <section title="ISO 6709:2008 Conformance"> <t><xref target="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 ofnon-applicableinapplicable tests.</t> <table> <name>Conformance Test Results</name> <thead><tr><th>Test</th><th>Description</th><th>Pass Explanation</th></tr> </thead> <tbody><tr><td>A.1.2.1</td><td>elementsreqd.required for ageo.geographic point location</td><td>CRS is always indicated</td></tr><tr><td>A.1.2.2</td><td>Description<tr><td>A.1.2.2</td><td>description of a CRS from a register</td><td>CRS register is defined</td></tr> <tr><td>A.1.2.3</td><td>definition of CRS</td><td>N/A - Don't define CRS</td></tr> <tr><td>A.1.2.4</td><td>representation of horizontalposition</td><td>lat/longposition</td><td>latitude/longitude values conform</td></tr> <tr><td>A.1.2.5</td><td>representation of vertical position</td><td>height value conforms</td></tr> <tr><td>A.1.2.6</td><td>text string representation</td><td>N/A - No string format</td></tr> </tbody> </table> <t>For test<tt>A.1.2.1</tt>'<tt>A.1.2.1</tt>', the YANGgeo locationgeo-location object either includes a Coordinate Reference System (CRS)(<tt>reference-frame</tt>)('<tt>reference-frame</tt>') or has a default defined(<xref target="WGS84"/>).</t><xref target="WGS84"/>.</t> <t>For<tt>A.1.2.3</tt>'<tt>A.1.2.3</tt>', we do not define our own CRS, and doing so is not required for conformance.</t> <t>For<tt>A.1.2.6</tt>'<tt>A.1.2.6</tt>', we do not define a text string representation, which is also not required for conformance.</t> </section> <section title="Usability"> <t>The geo-location object defined in this document and YANG modulehavehas been designed to be usable in a very broad set of applications. This includes the ability to locate things on astronomical bodies other than Earth, and to utilize entirely different coordinate systems and realities.</t> <section title="Portability"> <t>In order to verify portability while developing thismodulemodule, the following standards and standard APIs were considered.</t> <section title="IETF URI Value"> <t><xref target="RFC5870"/> defines a standard URI value for geographic location data. It includes the ability to specify the<tt>geodetic-value</tt>'<tt>geodetic-value</tt>' (it calls this<tt>crs</tt>)'<tt>crs</tt>') with the default being<tt>wgs-84</tt>'<tt>wgs-84</tt>' <xref target="WGS84"/>. For the locationdatadata, it allows2two to3three coordinates defined by the<tt>crs</tt>'<tt>crs</tt>' value. For accuracy, it has a single<tt>u</tt>'<tt>u</tt>' parameter for specifying uncertainty. The<tt>u</tt>'<tt>u</tt>' value is in fractions of meters and applies to all the location values. As the URI is a string, all values are specified as strings and so are capable of as much precision as required.</t> <t>URI values can be mapped to and from the YANGgrouping,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.</t> </section> <section title="W3C"> <t>W3CDefinesdefines ageo-locationgeolocation API in <xref target="W3CGEO"/>. We show a snippet of code belowwhichthat defines thegeo-locationgeolocation data for this API. This is used by many applications (e.g., Google Maps API).</t> <figure><name>Snippet ShowingGeo-Location Definition</name><sourcecode><![CDATA[Geolocation Definition</name><sourcecode type=""><![CDATA[ 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? heading; readonly attribute double? speed; }; ]]></sourcecode></figure> <sectiontitle="Comparetitle="Comparison with YANG Data Model"> <table> <thead><tr><th>Field</th><th>Type</th><th>YANG</th><th>Type</th></tr> </thead> <tbody><tr><td>accuracy</td><td>double</td><td>coord-accuracy</td><td>dec64 fr 6</td></tr> <tr><td>altitude</td><td>double</td><td>height</td><td>dec64 fr 6</td></tr> <tr><td>altitudeAccuracy</td><td>double</td><td>height-accuracy</td><td>dec64 fr 6</td></tr> <tr><td>heading</td><td>double</td><td>v-north, v-east</td><td>dec64 fr 12</td></tr> <tr><td>latitude</td><td>double</td><td>latitude</td><td>dec64 fr 16</td></tr> <tr><td>longitude</td><td>double</td><td>longitude</td><td>dec64 fr 16</td></tr> <tr><td>speed</td><td>double</td><td>v-north, v-east</td><td>dec64 fr 12</td></tr> <tr><td>timestamp</td><td>DOMTimeStamp</td><td>timestamp</td><td>string</td></tr> </tbody> </table> <dl> <dt>accuracy(double)</dt><dd><t>Accuracy(double):</dt><dd><t>Accuracy of<tt>latitude</tt>'<tt>latitude</tt>' and<tt>longitude</tt>'<tt>longitude</tt>' values in meters.</t></dd> <dt>altitude(double)</dt><dd><t>Optional(double):</dt><dd><t>Optional height in meters above the <xref target="WGS84"/> ellipsoid.</t></dd> <dt>altitudeAccuracy(double)</dt><dd><t>Optional(double):</dt><dd><t>Optional accuracy of<tt>altitude</tt>'<tt>altitude</tt>' value in meters.</t></dd> <dt>heading(double)</dt><dd><t>Optional Direction(double):</dt><dd><t>Optional direction in decimaldegdegrees from true north increasingclock-wise.</t></dd>clockwise.</t></dd> <dt>latitude, longitude(double)</dt><dd><t>Standard lat/long(double):</dt><dd><t>Standard latitude/longitude values in decimal degrees.</t></dd> <dt>speed(double)</dt><dd><t>Speed(double):</dt><dd><t>Speed along the heading in meters per second.</t></dd> <dt>timestamp(DOMTimeStamp)</dt><dd><t>Specifies(DOMTimeStamp):</dt><dd><t>Specifies milliseconds since theUnix EPOCHUNIX Epoch in64 bita 64-bit unsigned integer. The YANG data model defines the timestamp with arbitrarily large precision by using a stringwhichthat encompasses all representable values of this timestamp value.</t></dd> </dl> <t>W3C API values can be mapped to the YANGgrouping,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.</t> <t>Conversely, only YANG values for Earth using the default<tt>wgs-84</tt>'<tt>wgs-84</tt>' <xref target="WGS84"/> as the<tt>geodetic-datum</tt>,'<tt>geodetic-datum</tt>' can be directly mapped to the W3Cvalues,values as W3C does not provide the extra features necessary to map the broader set of values supported by the YANG grouping.</t> </section> </section> <section title="Geography Markup Language (GML)"> <t>ISO adopted the Geography Markup Language (GML) defined by OGC 07-036 <xref target="OGC"/> as <xref target="ISO.19136.2007"/>. GML defines, among many other things, a position type<tt>gml:pos</tt>'<tt>gml:pos</tt>', which is a sequence of<tt>double</tt>'<tt>double</tt>' values. This sequence of values represents coordinates in a given CRS. The CRS is either inherited from containing elements or directly specified as attributes<tt>srsName</tt>'<tt>srsName</tt>' and optionally<tt>srsDimension</tt>'<tt>srsDimension</tt>' on the<tt>gml:pos</tt>.</t>'<tt>gml:pos</tt>'.</t> <t>GML defines an Abstract CRS type from which Concrete CRS typesderive from.are derived. This allows for many types of CRS definitions. We are concerned with the Geodetic CRStypetype, which can have either ellipsoidal or Cartesian coordinates. We believe that othernon-Earth based CRSnon-Earth-based CRSs as well as virtualCRSCRSs should also be representable by the GML CRS types.</t> <t>Thus, GML<tt>gml:pos</tt>'<tt>gml:pos</tt>' values can be mapped directly to the YANGgrouping,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.</t><t>Conversely,<t> Conversely, mapping YANG grouping valuescan be mappedto GMLas directly as the GML CRS available definitions allow with a minimum ofis fully supported for Earth-based geodeticsystems fully supported.</t>systems.</t> <t>GML also defines an observation value in<tt>gml:Observation</tt>'<tt>gml:Observation</tt>', which includes a timestamp value<tt>gml:validTime</tt>'<tt>gml:validTime</tt>' in addition to other components such as<tt>gml:using</tt> <tt>gml:target</tt>'<tt>gml:using</tt>', '<tt>gml:target</tt>', and<tt>gml:resultOf</tt>.'<tt>gml:resultOf</tt>'. Only the timestamp is mappable to and from the YANG grouping. Furthermore,<tt>gml:validTime</tt>'<tt>gml:validTime</tt>' can either be anInstantaneousinstantaneous measure(<tt>gml:TimeInstant</tt>)('<tt>gml:TimeInstant</tt>') or a time period(<tt>gml:TimePeriod</tt>).('<tt>gml:TimePeriod</tt>'). The instantaneous<tt>gml:TimeInstant</tt>'<tt>gml:TimeInstant</tt>' is mappable to and from the YANG grouping<tt>timestamp</tt>'<tt>timestamp</tt>' value, and values down to the resolution of seconds for<tt>gml:TimePeriod</tt>'<tt>gml:TimePeriod</tt>' can be mapped using the<tt>valid-until</tt>'<tt>valid-until</tt>' node of the YANG grouping.</t> </section> <section title="KML"> <t>KML 2.2 <xref target="KML22"/> (formerly Keyhole Markup Language) was submitted by Google to the <eref target="https://www.opengeospatial.org/">Open GeospatialConsortium,</eref>Consortium</eref> and was adopted. The latest version as of this writing is KML 2.3 <xref target="KML23"/>. This schema includes geographic location data in some of its objects (e.g.,<tt>kml:Point</tt>'<tt>kml:Point</tt>' or<tt>kml:Camera</tt>'<tt>kml:Camera</tt>' objects). This data is provided in string format and corresponds to the values specified in <xreftarget="W3CGEO"/> values.target="W3CGEO"/>. The timestamp value is also specified as a string as in our YANG grouping.</t> <t>KML has some special handling for the height value that is useful for visualization software,<tt>kml:altitudeMode</tt>. These'<tt>kml:altitudeMode</tt>'. The values for<tt>kml:altitudeMode</tt>'<tt>kml:altitudeMode</tt>' includeindicating'<tt>clampToGround</tt>', which indicates the height isignored (<tt>clampToGround</tt>), in relationignored; '<tt>relativeToGround</tt>', which indicates the height value is relative to the location's groundlevel (<tt>relativeToGround</tt>),level; orin relation to'<tt>absolute</tt>', which indicates the height value is an absolute value within the geodeticdatum (<tt>absolute</tt>).datum. The YANG grouping can directly map the ignored and absolutecases,cases but not therelative to groundrelative-to-ground case.</t> <t>In addition to the<tt>kml:altitudeMode</tt>'<tt>kml:altitudeMode</tt>', KML also defines two seafloor height values using<tt>kml:seaFloorAltitudeMode</tt>.'<tt>kml:seaFloorAltitudeMode</tt>'. One value is to ignore the height value(<tt>clampToSeaFloor</tt>)('<tt>clampToSeaFloor</tt>') and the other is relative(<tt>relativeToSeaFloor</tt>).('<tt>relativeToSeaFloor</tt>'). As with the<tt>kml:altitudeMode</tt>'<tt>kml:altitudeMode</tt>' value, the YANG grouping supports the ignore case but not the relative case.</t><t>The<t> The KML location values use a geodetic datum defined in Annex Aby the GML Coordinate Reference System (CRS)of <xref target="ISO.19136.2007"/> with identifier<tt>LonLat84_5773</tt>.'<tt>LonLat84_5773</tt>'. The altitude value for KML absolute height mode is measured from the vertical datum specified by <xref target="WGS84"/>.</t> <t>Thus, the YANG grouping and KML values can be directly mapped in both directions (when using a supported altitude mode) with the caveat that some loss of precision (in the extremes) may occur due to the YANG grouping using decimal64 values rather than strings. For the relative height cases, the application doing the transformation is expected to have the data available to transform the relative height into an absolute height, which can then be expressed using the YANG grouping.</t> </section> </section> </section> <section title="IANA Considerations"> <section title="Geodetic System Values Registry"> <t>IANAis asked to create a new registryhas created the "Geodetic System Values" registry undera new protocol category groupthe "YANG Geographic LocationParameters".</t>Parameters" registry.</t> <t>This registry allocates names for standard geodetic systems.OftenOften, these values are referred to using multiple names (e.g., full names or multiple acronyms). The intent of this registry is to provide a single standard value for any given geodetic system.</t> <t>The valuesSHOULD<bcp14>SHOULD</bcp14> use an acronym when available, theyMUST<bcp14>MUST</bcp14> be converted tolower case,lowercase, and spacesMUST<bcp14>MUST</bcp14> be changed to dashes "-".</t> <t>Each entry should be sufficient to define the2two coordinatevalues,values and to define height if height is required. So, for example, the<tt>wgs-84</tt>'<tt>wgs-84</tt>' is defined as WGS-84 with the geoid updated by at least <xref target="EGM96"/> for height values. Specific entries for <xref target="EGM96"/> and <xref target="EGM08"/> are present if a more precise definition of the data is required.</t> <t>It should be noted that <xref target="RFC5870"/> alsocreatescreated a registry forGeodetic Systems (it calls CRS);geodetic systems (the "'geo' URI 'crs' Parameter Values" registry); however, this registry has a very strict modification policy. The authors of <xref target="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,scope (i.e., beyond Earth), the registry defined below is meant to be more easily modified.</t> <t>The allocation policy for this registry is FirstCome,Come FirstServed,Served <xreftarget="RFC8126"/>target="RFC8126"/>, as the intent is simply to avoid duplicate values.</t> <t>The Reference value can either be a document or a contact person as defined in <xref target="RFC8126"/>. The ChangeControlController (i.e., Owner) is also defined by <xref target="RFC8126"/>.</t> <t>The initial values for this registry are as follows. They include thenon-Earth basednon-Earth-based geodetic-datum value for themoonMoon based on <xreftarget="ME"/>.</t>target="MEAN-EARTH"/>.</t> <table><thead><tr><th>Name</th><th>Description</th><th>Reference</th><th>Change</th></tr> <tr><th> </th><th> </th><th>/Contact</th><th>Control</th></tr><thead><tr><th>Name</th><th>Description</th><th>Reference</th><th>Change Controller</th></tr> </thead> <tbody><tr><td>me</td><td>Mean Earth/Polar Axis(Moon)</td><td>this</td><td>IESG</td></tr>(Moon)</td><td>RFC 9179</td><td>IETF</td></tr> <tr><td>wgs-84-96</td><td>World Geodetic System1984</td><td>this</td><td>IESG</td></tr>1984</td><td>RFC 9179</td><td>IETF</td></tr> <tr><td>wgs-84-08</td><td>World Geodetic System1984</td><td>this</td><td>IESG</td></tr>1984</td><td>RFC 9179</td><td>IETF</td></tr> <tr><td>wgs-84</td><td>World Geodetic System1984</td><td>this</td><td>IESG</td></tr>1984</td><td>RFC 9179</td><td>IETF</td></tr> </tbody> </table> </section> <section title="Updates to the IETF XML Registry"> <t>This document registers a URI in the "IETF XML Registry" <xref target="RFC3688"/>. Following the format in <xref target="RFC3688"/>, the following registration has been made:</t><dl> <dt>URI</dt><dd><t>urn:ietf:params:xml:ns:yang:ietf-geo-location</t></dd><dl spacing="compact"> <dt>URI:</dt><dd><t>urn:ietf:params:xml:ns:yang:ietf-geo-location</t></dd> <dt>RegistrantContact</dt><dd><t>TheContact:</dt><dd><t>The IESG.</t></dd><dt>XML</dt><dd><t>N/A;<dt>XML:</dt><dd><t>N/A; the requested URI is an XML namespace.</t></dd> </dl> </section> <section title="Updates to the YANG Module Names Registry"> <t>This document registers one YANG module in the "YANG Module Names" registry <xref target="RFC6020"/>. Following the format in <xref target="RFC6020"/>, the following registration has been made:</t><dl> <dt>name</dt><dd><t>ietf-geo-location</t></dd> <dt>namespace</dt><dd><t>urn:ietf:params:xml:ns:yang:ietf-geo-location</t></dd> <dt>prefix</dt><dd><t>geo</t></dd> <dt>reference</dt><dd><t>RFC XXXX (RFC Ed.: replace XXXX with RFC number and remove this note.)</t></dd><dl spacing="compact"> <dt>Name:</dt><dd><t>ietf-geo-location</t></dd> <dt>Maintained by IANA:</dt><dd><t>N</t></dd> <dt>Namespace:</dt><dd><t>urn:ietf:params:xml:ns:yang:ietf-geo-location</t></dd> <dt>Prefix:</dt><dd><t>geo</t></dd> <dt>Reference:</dt><dd><t>RFC 9179</t></dd> </dl> </section> </section> <section title="Security Considerations"> <t>The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such asNETCONFthe Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) <xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.</t> <t>The NETCONF access control model <xref target="RFC8341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.</t> <t>Since the modules defined in this document only define groupings, these considerations are primarily for the designers of other modules that use these groupings.</t> <t>All the data nodes defined in this YANG module are writable/creatable/deletable (i.e., "config true", which is the default).</t> <t>None of the writable/creatable/deletable data nodes in the YANG module defined in this document are by themselves considered more sensitive or vulnerable than standard configuration.</t> <t>Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes.</t> <t>Since the grouping defined in this module identifies locations, authors using this groupingSHOULD<bcp14>SHOULD</bcp14> consider any privacy issues that may arise when the data is readable (e.g., customer device locations, etc).</t> </section> </middle> <back> <references title="Normative References"> <reference anchor="EGM08"> <front> <title>An Earth Gravitational Model to Degree 2160: EGM08.</title> <authorinitials='N.K.'initials='N.' surname='Pavlis' fullname='N.K.Pavlis'><organization/></author> <authorinitials='S.A.'initials='S.' surname='Holmes' fullname='S.A.Holmes'><organization/></author> <authorinitials='S.C.'initials='S.' surname='Kenyon' fullname='S.C.Kenyon'><organization/></author> <authorinitials='J.K.'initials='J.' surname='Factor' fullname='J.K.Factor'><organization/></author> <dateyear="2008"/>year="2008" month="April"/> </front><refcontent>Presented at the 2008 General Assembly of the European Geosciences Union,Vienna, Arpil13-18, 2008</refcontent>Vienna</refcontent> </reference> <reference anchor="EGM96"> <front> <title>The Development of the Joint NASA GSFC and the National Imagery and Mapping Agency (NIMA) Geopotential Model EGM96.</title> <authorinitials='F.G.'initials='F.' surname='Lemoine' fullname='F.G.Lemoine'><organization/></author> <authorinitials='S.C.'initials='S.' surname='Kenyon' fullname='S.C.Kenyon'><organization/></author> <authorinitials='J.K.'initials='J.' surname='Factor' fullname='J.K.Factor'><organization/></author> <authorinitials='R.G.'initials='R.' surname='Trimmer' fullname='R.G.Trimmer'><organization/></author> <authorinitials='N.K.'initials='N.' surname='Pavlis' fullname='N.K.Pavlis'><organization/></author> <authorinitials='D.S.'initials='D.' surname='Chinn' fullname='D.S.Chinn'><organization/></author> <authorinitials='C.M.'initials='C.' surname='Cox' fullname='C.M.Cox'><organization/></author> <authorinitials='S.M.'initials='S.' surname='Klosko' fullname='S.M.Klosko'><organization/></author> <authorinitials='S.B.'initials='S.' surname='Luthcke' fullname='S.B.Luthcke'><organization/></author> <authorinitials='M.H.'initials='M.' surname='Torrence' fullname='M.H.Torrence'><organization/></author> <authorinitials='Y.M.'initials='Y.' surname='Wang' fullname='Y.M.Wang'><organization/></author> <authorinitials='R.G.'initials='R.' surname='Williamson' fullname='R.G.Williamson'><organization/></author> <authorinitials='E.C.'initials='E.' surname='Pavlis' fullname='E.C.Pavlis'><organization/></author> <authorinitials='R.H.'initials='R.' surname='Rapp' fullname='R.H.Rapp'><organization/></author> <authorinitials='T.R.'initials='T.' surname='Olson' fullname='T.R.Olson'><organization/></author> <dateyear="1998"/> </front><refcontent>Technical Report NASA/TP-1998-206861, NASA, Greenbelt.</refcontent>year="1998" month="July"/> </front><refcontent>NASA/TP-1998-206861</refcontent> </reference> <reference anchor="ISO.6709.2008"> <front><title>ISO 6709:2008 Standard<title>Standard representation of geographic point location bycoordinates.</title>coordinates</title> <author><organization>International Organization for Standardization</organization></author> <date year="2008"/> </front> <seriesInfo name="ISO" value="6709:2008"/> </reference> <referenceanchor="ME">anchor="MEAN-EARTH"> <front> <title>A Standardized Lunar Coordinate System for the Lunar ReconnaissanceOrbiter, Version 4.</title> <author><organization>National Aeronautics and Space Administration, Goddard Space Flight Center.</organization></author>Orbiter</title> <author><organization>NASA</organization></author> <dateday="14" month="5"month="May" year="2008"/> </front> <refcontent>Version 4, Goddard Space Flight Center</refcontent> </reference><reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author> <date year='1997' month='March' /> <abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract> </front> <seriesInfo name='BCP' value='14'/> <seriesInfo name='RFC' value='2119'/> <seriesInfo name='DOI' value='10.17487/RFC2119'/> </reference> <reference anchor='RFC6991' target='https://www.rfc-editor.org/info/rfc6991'> <front> <title>Common YANG Data Types</title> <author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder' role='editor'><organization /></author> <date year='2013' month='July' /> <abstract><t>This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.</t></abstract> </front> <seriesInfo name='RFC' value='6991'/> <seriesInfo name='DOI' value='10.17487/RFC6991'/> </reference> <reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author> <date year='2017' month='May' /> <abstract><t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t></abstract> </front> <seriesInfo name='BCP' value='14'/> <seriesInfo name='RFC' value='8174'/> <seriesInfo name='DOI' value='10.17487/RFC8174'/> </reference> <reference anchor='RFC8126' target='https://www.rfc-editor.org/info/rfc8126'> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></author> <author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author> <author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author> <date year='2017' month='June' /> <abstract><t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t><t>This is the third edition of this document; it obsoletes RFC 5226.</t></abstract> </front> <seriesInfo name='BCP' value='26'/> <seriesInfo name='RFC' value='8126'/> <seriesInfo name='DOI' value='10.17487/RFC8126'/> </reference> <reference anchor='RFC8342' target='https://www.rfc-editor.org/info/rfc8342'> <front> <title>Network Management Datastore Architecture (NMDA)</title> <author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization /></author> <author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'><organization /></author> <author initials='P.' surname='Shafer' fullname='P. Shafer'><organization /></author> <author initials='K.' surname='Watsen' fullname='K. Watsen'><organization /></author> <author initials='R.' surname='Wilton' fullname='R. Wilton'><organization /></author> <date year='2018' month='March' /> <abstract><t>Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.</t></abstract> </front> <seriesInfo name='RFC' value='8342'/> <seriesInfo name='DOI' value='10.17487/RFC8342'/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <reference anchor="WGS84"> <front><title>National Imagery and Mapping Agency Technical Report 8350.2, Third Edition.</title><title>Department of Defense World Geodetic System 1984</title> <author><organization>National Imagery and MappingAgency.</organization></author>Agency</organization></author> <dateday="3" month="1"month="January" year="2000"/> </front> <refcontent>NIMA TR8350.2, Third Edition</refcontent> </reference> </references> <references title="Informative References"> <reference anchor="OGC" target="https://portal.ogc.org/files/?artifact_id=20509"> <front> <title>OpenGIS® Geography Markup Language (GML) Encoding Standard</title> <author><organization>OpenGIS</organization></author> <date month="August" year="2007"/> </front> <refcontent>Version: 3.2.1</refcontent> <refcontent>OGC 07-036</refcontent> </reference> <reference anchor="ISO.19136.2007"> <front><title>ISO 19136:2007 Geographic<title>Geographic information -- Geography Markup Language (GML)</title> <author><organization>International Organization for Standardization</organization></author> <date/> </front> <seriesInfo name="ISO" value="19136:2007"/> </reference> <reference anchor="KML22"target='http://portal.opengeospatial.org/files/?artifact_id=27810'>target='https://portal.opengeospatial.org/files/?artifact_id=27810' > <front> <title>OGCKML (Version 2.2)</title>KML</title> <author role='editor' initials='T.' surname='Wilson' fullname='Tim Wilson'><organization>Open GeospatialConsortium</organization></author>Consortium Inc.</organization></author> <dateday="14" month="4"month="April" year="2008"/> </front> <refcontent>Version 2.2</refcontent> </reference> <reference anchor="KML23"target='http://docs.opengeospatial.org/is/12-007r2/12-007r2.html'>target='https://docs.opengeospatial.org/is/12-007r2/12-007r2.html'> <front> <title>OGCKML 2.3</title>KML</title> <author role='editor' initials='D.' surname='Burggraf' fullname='David Burggraf'><organization>Open GeospatialConsortium</organization></author>Consortium Inc.</organization></author> <dateday="4" month="8"month="August" year="2015"/> </front> <refcontent>Version 2.3</refcontent> </reference><reference anchor='RFC3688' target='https://www.rfc-editor.org/info/rfc3688'> <front> <title>The IETF XML Registry</title> <author initials='M.' surname='Mealling' fullname='M. Mealling'><organization /></author> <date year='2004' month='January' /> <abstract><t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t></abstract> </front> <seriesInfo name='BCP' value='81'/> <seriesInfo name='RFC' value='3688'/> <seriesInfo name='DOI' value='10.17487/RFC3688'/> </reference> <reference anchor='RFC5870' target='https://www.rfc-editor.org/info/rfc5870'> <front> <title>A Uniform Resource Identifier for Geographic Locations ('geo' URI)</title> <author initials='A.' surname='Mayrhofer' fullname='A. Mayrhofer'><organization /></author> <author initials='C.' surname='Spanring' fullname='C. Spanring'><organization /></author> <date year='2010' month='June' /> <abstract><t>This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo\' scheme name. A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way. The default coordinate reference system used is the World Geodetic System 1984 (WGS-84). [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='5870'/> <seriesInfo name='DOI' value='10.17487/RFC5870'/> </reference> <reference anchor='RFC6020' target='https://www.rfc-editor.org/info/rfc6020'> <front> <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title> <author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'><organization /></author> <date year='2010' month='October' /> <abstract><t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='6020'/> <seriesInfo name='DOI' value='10.17487/RFC6020'/> </reference> <reference anchor='RFC6241' target='https://www.rfc-editor.org/info/rfc6241'> <front> <title>Network Configuration Protocol (NETCONF)</title> <author initials='R.' surname='Enns' fullname='R. Enns' role='editor'><organization /></author> <author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'><organization /></author> <author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder' role='editor'><organization /></author> <author initials='A.' surname='Bierman' fullname='A. Bierman' role='editor'><organization /></author> <date year='2011' month='June' /> <abstract><t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='6241'/> <seriesInfo name='DOI' value='10.17487/RFC6241'/> </reference> <reference anchor='RFC6242' target='https://www.rfc-editor.org/info/rfc6242'> <front> <title>Using the NETCONF Protocol over Secure Shell (SSH)</title> <author initials='M.' surname='Wasserman' fullname='M. Wasserman'><organization /></author> <date year='2011' month='June' /> <abstract><t>This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='6242'/> <seriesInfo name='DOI' value='10.17487/RFC6242'/> </reference> <reference anchor='RFC7950' target='https://www.rfc-editor.org/info/rfc7950'> <front> <title>The YANG 1.1 Data Modeling Language</title> <author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'><organization /></author> <date year='2016' month='August' /> <abstract><t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t></abstract> </front> <seriesInfo name='RFC' value='7950'/> <seriesInfo name='DOI' value='10.17487/RFC7950'/> </reference> <reference anchor='RFC8040' target='https://www.rfc-editor.org/info/rfc8040'> <front> <title>RESTCONF Protocol</title> <author initials='A.' surname='Bierman' fullname='A. Bierman'><organization /></author> <author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization /></author> <author initials='K.' surname='Watsen' fullname='K. Watsen'><organization /></author> <date year='2017' month='January' /> <abstract><t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t></abstract> </front> <seriesInfo name='RFC' value='8040'/> <seriesInfo name='DOI' value='10.17487/RFC8040'/> </reference> <reference anchor='RFC8340' target='https://www.rfc-editor.org/info/rfc8340'> <front> <title>YANG Tree Diagrams</title> <author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization /></author> <author initials='L.' surname='Berger' fullname='L. Berger' role='editor'><organization /></author> <date year='2018' month='March' /> <abstract><t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t></abstract> </front> <seriesInfo name='BCP' value='215'/> <seriesInfo name='RFC' value='8340'/> <seriesInfo name='DOI' value='10.17487/RFC8340'/> </reference> <reference anchor='RFC8341' target='https://www.rfc-editor.org/info/rfc8341'> <front> <title>Network Configuration Access Control Model</title> <author initials='A.' surname='Bierman' fullname='A. Bierman'><organization /></author> <author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization /></author> <date year='2018' month='March' /> <abstract><t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t><t>This document obsoletes RFC 6536.</t></abstract> </front> <seriesInfo name='STD' value='91'/> <seriesInfo name='RFC' value='8341'/> <seriesInfo name='DOI' value='10.17487/RFC8341'/> </reference> <reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author> <date year='2018' month='August' /> <abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t></abstract> </front> <seriesInfo name='RFC' value='8446'/> <seriesInfo name='DOI' value='10.17487/RFC8446'/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5870.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <reference anchor="W3CGEO" target='https://www.w3.org/TR/2016/REC-geolocation-API-20161108/'> <front> <title>Geolocation API Specification</title> <author initials='A.' surname='Popescu' fullname='Andrei Popescu'><organization/></author> <dateday="8" month="11"month="November" year="2016"/> </front> <refcontent>2nd Edition</refcontent> </reference> </references> <section title="Examples"> <t>Below is a fictitious module that uses the geo-location grouping.</t> <figure><name>Example YANGmodule using geo location.</name><sourcecode><![CDATA[Module Using Geolocation</name><sourcecode type="yang"><![CDATA[ module example-uses-geo-location { namespace "urn:example:example-uses-geo-location"; prefix ugeo; import ietf-geo-location { prefix geo; } organization "Empty Org"; contact "Example Author <eauthor@example.com>"; description "Example use of geo-location"; revision2019-02-022022-2-7 { reference "None"; } container locatable-items { description"container"The container of locatable items"; list locatable-item { key name; description "A locatable item"; leaf name { type string; description"name"The name of locatable item"; } uses geo:geo-location; } } } ]]></sourcecode></figure> <t>Below is the YANG tree for the fictitious module that uses the geo-location grouping.</t><artwork><![CDATA[<figure><name>Example YANG Tree Using Geolocation</name> <sourcecode type="yangtree"><![CDATA[ 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? 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? yang:date-and-time +--rw valid-until? yang:date-and-time]]></artwork>]]></sourcecode> </figure> <t>Below is some example YANG XML data for the fictitious module that uses the geo-location grouping.</t> <figure><name>Example XMLdataData ofgeo location use.</name><sourcecode><![CDATA[Geolocation Use</name><sourcecode type="xml"><![CDATA[ <locatable-items xmlns="urn:example:example-uses-geo-location"> <locatable-item> <name>Gaetana's</name> <geo-location> <latitude>40.73297</latitude> <longitude>-74.007696</longitude> </geo-location> </locatable-item> <locatable-item> <name>Pont des Arts</name> <geo-location> <timestamp>2012-03-31T16:00:00Z</timestamp> <latitude>48.8583424</latitude> <longitude>2.3375084</longitude> <height>35</height> </geo-location> </locatable-item> <locatable-item> <name>Saint Louis Cathedral</name> <geo-location> <timestamp>2013-10-12T15:00:00-06:00</timestamp> <latitude>29.9579735</latitude> <longitude>-90.0637281</longitude> </geo-location> </locatable-item> <locatable-item> <name>Apollo 11 Landing Site</name> <geo-location> <timestamp>1969-07-21T02:56:15Z</timestamp> <reference-frame> <astronomical-body>moon</astronomical-body> <geodetic-system> <geodetic-datum>me</geodetic-datum> </geodetic-system> </reference-frame> <latitude>0.67409</latitude> <longitude>23.47298</longitude> </geo-location> </locatable-item> <locatable-item> <name>Reference Frame Only</name> <geo-location> <reference-frame> <astronomical-body>moon</astronomical-body> <geodetic-system> <geodetic-datum>me</geodetic-datum> </geodetic-system> </reference-frame> </geo-location> </locatable-item> </locatable-items> ]]></sourcecode></figure> </section> <sectiontitle="Acknowledgments">title="Acknowledgments" numbered="false"> <t>We would like to thankJim Biard and Ben Koziol<contact fullname="Jim Biard"/> and <contact fullname="Ben Koziol"/> for their reviews and suggested improvements. We would also like to thankPeter Lothberg<contact fullname="Peter Lothberg"/> for the motivation as well as help in defining a broadly useful geographic locationobject, and Acee Lindem and Qin Wuobject as well as <contact fullname="Acee Lindem"/> and <contact fullname="Qin Wu"/> for their work on a geographic location object that led to thisdocuments'document's creation. We would also like to thank thedocument shepherd Kent Watsen.</t>Document Shepherd <contact fullname="Kent Watsen"/>.</t> </section> </back> </rfc>