Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Christian Hopps <[e-mail]>]

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 <[e-mail]> 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:[e-mail]]
>>> 发送时间: 2020年7月30日 21:32
>>> 收件人: Qin Wu <[e-mail]>
>>> 抄送: [e-mail]
>>> 主题: 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:[e-mail]] 代表 Juergen Schoenwaelder
>>>> 发送时间: 2020年7月18日 3:16
>>>> 收件人: [e-mail]
>>>> 主题: [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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   [phone]         <https://www.jacobs-university.de/>
>>>> 
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>>> --
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   [phone]         <https://www.jacobs-university.de/>
>> 
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>