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

From: Qin Wu <[email-masked]>
Date: Thu, 30 Jul 2020 13:54:43 +0000

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-masked]] 
发送时间: 2020年7月30日 21:32
收件人: Qin Wu <[email-masked]>
抄送: [email-masked]
主题: 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-masked]] 代表 Juergen Schoenwaelder
> 发送时间: 2020年7月18日 3:16
> 收件人: [email-masked]
> 主题: [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-masked]
> 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/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2020 16:02:51 +0200

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2020 18:23:26 +0200

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

---

From: Christian Hopps <[email-masked]>
Date: Thu, 30 Jul 2020 12:38:16 -0400

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-masked]> wrote:
> 
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 30 Jul 2020 17:25:07 +0000

+1

On 2020-07-30, 10:04 AM, "netmod on behalf of Juergen Schoenwaelder" <[email-masked] on behalf of [email-masked]> wrote:

    /js