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

[Juergen Schoenwaelder <[e-mail]>]

Having skimmed draft-ietf-netmod-geo-location-05.txt again, I agree
that people should use the grouping. The examples in Appendix A make
it pretty clear that it is possible to report minimal values if that
is desirable but having the flexibility to report more details may
come in handy where needed.

As far as rfc6991bis is concerned, it is clear that there is nothing
to be done for latitude and longitude.

/js

On Fri, Jul 31, 2020 at 04:34:17AM -0400, Christian Hopps wrote:
> The point of the grouping is to not cut corners, and that it was vetted by experts in the field. Just re-using some typedefs of lat/long/height is not sufficient. You must also talk about the reference system which defines the meaning of those values, and know what you are talking about. It matters. Providing typedef's would suggest that it was OK to just re-use those values alone, when in fact it is not. If you read through the document you will see comparisons to other geographic location specifications. None of them just define "lat/long" as decimal degrees and call it done, as that is not sufficient.
> 
> Why shouldn't the grouping be used as is here? Nothing says that the software has to support every possible variation of data. Yes, the grouping allows specifying many types of coordinates (e.g., on the Moon), but that does not mean that the software that uses the grouping has to actually support those inputs.
> 
> In fact, If you look at the case we are talking about here, there's not only no reason to be limiting the geo-location, it's literally the use-case that drove me to create the grouping and its generality (i.e., locating network elements for a telecom and its management system).
> 
> Thanks,
> Chris.
> 
> > On Jul 30, 2020, at 9:32 PM, Qin Wu <[e-mail]> wrote:
> > 
> > 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:[e-mail] <mailto:[e-mail]>]
> > 发送时间: 2020年7月31日 0:38
> > 收件人: Juergen Schoenwaelder <[e-mail] <mailto:[e-mail]>>
> > 抄送: Christian Hopps <[e-mail] <mailto:[e-mail]>>; Qin Wu <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> > 主题: 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 <[e-mail] <mailto:[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] <mailto:[e-mail]>]
> > 发送时间: 2020年7月30日 21:32
> > 收件人: Qin Wu <[e-mail] <mailto:[e-mail]>>
> > 抄送: [e-mail] <mailto:[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] <mailto:[e-mail]>] 代表 Juergen Schoenwaelder
> > 发送时间: 2020年7月18日 3:16
> > 收件人: [e-mail] <mailto:[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/ <https://www.jacobs-university.de/>>
> > 
> > _______________________________________________
> > netmod mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/netmod <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/ <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/>>
> > 
> > --
> > 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/>>
> 



-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>