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

[Qin Wu <[e-mail]>]

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]]
发送时间: 2020年7月31日 0:38
收件人: Juergen Schoenwaelder <[e-mail]>
抄送: Christian Hopps <[e-mail]>; Qin Wu <[e-mail]>; [e-mail]; [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]]
发送时间: 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]] 代表 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/>

_______________________________________________
netmod mailing list
[e-mail]<mailto:[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/>