Thanks Chris and Jurgen for clarification, Chris, I am not sure I catch what you said. Does adding new typedef for longtitude and latitude do harm to draft-ietf-netmod-geo-location-05? Type in my opinion is more reusable building block.
-Qin 发件人: Christian Hopps [mailto:[email protected]] 发送时间: 2020年7月31日 0:38 收件人: Juergen Schoenwaelder <[email protected]> 抄送: Christian Hopps <[email protected]>; Qin Wu <[email protected]>; [email protected]; [email protected] 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code 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]<mailto:[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]<mailto:[email protected]>> 抄送: [email protected]<mailto:[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]<mailto:[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]<mailto:[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/>
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
