I received specific external feedback from the geo experts to just use a number instead of a type. I think they may have been thinking that it would be easier to redefine the values meaning for different systems.
Thanks, Chris. > On Jul 30, 2020, at 12:23 PM, Juergen Schoenwaelder > <[email protected]> wrote: > > Looking in the I-Ds, I see that draft-ietf-netmod-geo-location-05 > defines a grouping geo-location. draft-ietf-teas-yang-te-topo-22 > has: > > +--ro geolocation > +--ro altitude? int64 > +--ro latitude? geographic-coordinate-degree > +--ro longitude? geographic-coordinate-degree > > You might simply use the grouping here that comes out of > draft-ietf-netmod-geo-location-05 - but then the grouping is > also a bit more complex than what you have. > > Unfortunately, draft-ietf-netmod-geo-location-05 does not define > helper types. The latitude and longitude leafs are simply decimal64s > with all details spelled out inline: > > 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 value."; > } > 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."; > } > > The teas document has > > typedef geographic-coordinate-degree { > type decimal64 { > fraction-digits 8; > } > description > "Decimal degree (DD) used to express latitude and longitude > geographic coordinates."; > } > > leaf latitude { > type geographic-coordinate-degree { > range "-90..90"; > } > description > "Relative position north or south on the Earth's surface."; > } > > leaf longitude { > type geographic-coordinate-degree { > range "-180..180"; > } > description > "Angular distance east or west on the Earth's surface."; > } > > Note also the differences in the precision. Obviously, > draft-ietf-netmod-geo-location-05 could have defined > helper types like > > typedef latitude { > type decimal64 { > fraction-digits 16; > } > units "decimal degrees"; > description > "The latitude value on the astronomical body."; > } > > typdef 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."; > } > > and a bunch more and used them to define the leafs. These types could > then have been reused in situations where the grouping in all its > details is not needed. > > I am not entirely sure where draft-ietf-netmod-geo-location-05 is in > the WG process, the datatracker says "In WG Last Call, Revised I-D > Needed - Issue raised by WGLC" - so perhaps there is a chance to get > the inline type definitions factored out so that they can be reused. > > I think this is something where the input from Chris Hopps and the > NETMOD chairs is important to determine the path forward. Since we > have an ietf-geo-location module, I would prefer to have common types > for location information defined there and not in yang-types. > > /js > > On Thu, Jul 30, 2020 at 04:02:51PM +0200, Juergen Schoenwaelder wrote: >> But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated >> or you need to use a grouping. I think we should not have overlapping >> work in different documents. >> >> /js >> >> On Thu, Jul 30, 2020 at 01:54:43PM +0000, Qin Wu wrote: >>> That is a good option, but draft-ietf-netmod-geo-location-05 only define >>> grouping, there is typedef for longitude and latitude, altitude. >>> >>> -Qin >>> -----邮件原件----- >>> 发件人: Juergen Schoenwaelder [mailto:[email protected]] >>> 发送时间: 2020年7月30日 21:32 >>> 收件人: Qin Wu <[email protected]> >>> 抄送: [email protected] >>> 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, >>> yang:postal-code, yang:country-code >>> >>> But there is draft-ietf-netmod-geo-location-05... What about using the >>> types defined in there? >>> >>> /js >>> >>> On Thu, Jul 30, 2020 at 01:28:17PM +0000, Qin Wu wrote: >>>> See geolocation definition in draft-ietf-teas-yang-te-topo-22 which >>>> defines longitude and latitude, altitude. >>>> I know it is beneficial for future document to import these types from >>>> rfc6991bis instead of from te topo model. >>>> >>>> -Qin >>>> -----邮件原件----- >>>> 发件人: netmod [mailto:[email protected]] 代表 Juergen Schoenwaelder >>>> 发送时间: 2020年7月18日 3:16 >>>> 收件人: [email protected] >>>> 主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, >>>> yang:postal-code, yang:country-code >>>> >>>> - It was suggested to add types for longitude, latitude, postal >>>> code, country-code. Do we go there or do we leave these for other >>>> modules to define? It seems such definitions should go into >>>> draft-ietf-netmod-geo-location. >>>> >>>> - Geo location is covered by draft-ietf-netmod-geo-location >>>> (so do nothing). >>>> >>>> - For country codes, there is ISO 3166, which defines two-letter, >>>> three-letter, and numeric country codes. I assume people wanted >>>> two-letter codes (as used in the DNS), i.e. they want DE and not >>>> DEU. But note that it is GB and not UK, i.e., what we commonly >>>> use in the DNS may not be exactly ISO 3166. (The devil is always >>>> in the details.) >>>> >>>> - For postal codes, it is unclear what the requirements are or what >>>> a proper definition for postal codes is. It is not entirely clear >>>> what the authoritative definition of the format of postal codes >>>> is, perhaps the Universal Postal Union. >>>> >>>> - Options: (i) do nothing or (ii) add a country code definition >>>> only or (iii) add both a country code definition and a postal >>>> code definition (which might be to some extend vague) >>>> >>>> - Proposal: do nothing >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/ > <https://www.jacobs-university.de/>>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
