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

Christian Hopps <chopps@chopps.org> Thu, 30 July 2020 16:38 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B3E3A0475; Thu, 30 Jul 2020 09:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9egvDbUQJ3RD; Thu, 30 Jul 2020 09:38:19 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7C09F3A040F; Thu, 30 Jul 2020 09:38:18 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 7D42C61669; Thu, 30 Jul 2020 16:38:17 +0000 (UTC)
From: Christian Hopps <chopps@chopps.org>
Message-Id: <9546C16C-C108-463F-A5D5-2F33DA131E82@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_9002F501-D708-460E-B7E9-34820D76BDB7"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 30 Jul 2020 12:38:16 -0400
In-Reply-To: <20200730162326.b2pcn646d2bk45iy@anna.jacobs.jacobs-university.de>
Cc: Christian Hopps <chopps@chopps.org>, Qin Wu <bill.wu@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>, netmod-chairs@ietf.org
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
References: <B8F9A780D330094D99AF023C5877DABAAD8A8660@dggeml511-mbs.china.huawei.com> <20200730140251.q7hwxc6j4kxuy5vq@anna.jacobs.jacobs-university.de> <20200730162326.b2pcn646d2bk45iy@anna.jacobs.jacobs-university.de>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3DT2aBcdaDz3uZkwfHtViJZ-olc>
Subject: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2020 16:38:22 -0000

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 <j.schoenwaelder@jacobs-university.de> 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:j.schoenwaelder@jacobs-university.de]
>>> 发送时间: 2020年7月30日 21:32
>>> 收件人: Qin Wu <bill.wu@huawei.com>
>>> 抄送: netmod@ietf.org
>>> 主题: 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:netmod-bounces@ietf.org] 代表 Juergen Schoenwaelder
>>>> 发送时间: 2020年7月18日 3:16
>>>> 收件人: netmod@ietf.org
>>>> 主题: [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
>>>> netmod@ietf.org
>>>> 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/ <https://www.jacobs-university.de/>>