Re: [netmod] for a future rfc6991bis

"Acee Lindem (acee)" <acee@cisco.com> Fri, 02 November 2018 14:55 UTC

Return-Path: <acee@cisco.com>
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 C7DDD1292F1 for <netmod@ietfa.amsl.com>; Fri, 2 Nov 2018 07:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.699
X-Spam-Level:
X-Spam-Status: No, score=-14.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 o7l_Wh5mbOP9 for <netmod@ietfa.amsl.com>; Fri, 2 Nov 2018 07:55:45 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC0D123FFD for <netmod@ietf.org>; Fri, 2 Nov 2018 07:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34470; q=dns/txt; s=iport; t=1541170545; x=1542380145; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=45V1dYxuU015ZqBzqQDPWkZAV/0kppzSSFH2723gSY8=; b=hxbpg2vHg/NbIHIIZCzvKM1DhMdHwQzOhqIOX3TfqXC1jrPQF/tjG6ak pEBpFq8Wh4Qtb6+e6KZwHxCimNgxvcZuEFuDLQ17+1vKU6wtZXz3UrmDB rJgY9l4/84uwR4KfsS1AGj6dp4uvggLlJI4eqK+nGASlvxj92/b2kXw4c k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AIAAAAZNxb/5tdJa1hAxkBAQEBAQEBAQEBAQEHAQEBAQEBgVMCAQEBAQELAYENSC9mfygKg2yULoINepYyFIFmCwEBGAEMhAFGAheDJyI2Cw0BAwEBAgEBAm0cDIU6AQEBAQMBASFLCw4CAgEGAg4CAQMBAgEgBwMCAgIZDAsUCQgBAQQBDQUZgwgBgR1kD4sdm06BLoE4gnUBAwKBCYRaBQWLbBeCAIEQAScfghc1gxsBAQEBAYEXFAEMBgElEQkBBRARgj0xgiYCjl0WkDcJAoZqiiAYgVWPBolAg0WHUIJCAhEUgSYkBitkcXAVOyoBgkGGBTOEYYU+bwGKeg4XgQiBHwEB
X-IronPort-AV: E=Sophos;i="5.54,456,1534809600"; d="scan'208,217";a="472842176"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2018 14:55:43 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wA2EthxY009226 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Nov 2018 14:55:43 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 2 Nov 2018 10:55:43 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Fri, 2 Nov 2018 10:55:43 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Qin Wu <bill.wu@huawei.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: netmod <netmod@ietf.org>
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdRyf5vg5pZToCjlLEK5aT+9YAPiFwAJrGSAAAhCoAD//+mPgA==
Date: Fri, 02 Nov 2018 14:55:43 +0000
Message-ID: <DB8040C6-5AB7-4F31-98F9-477B9694AA6D@cisco.com>
References: <B8F9A780D330094D99AF023C5877DABA9B0E9794@nkgeml513-mbs.china.huawei.com> <20181102081929.k72onwwawkblz3od@anna.jacobs.jacobs-university.de> <B8F9A780D330094D99AF023C5877DABA9B0EAE38@nkgeml513-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9B0EAE38@nkgeml513-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.15.45]
Content-Type: multipart/alternative; boundary="_000_DB8040C65AB74F3198F9477B9694AA6Dciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/lZeWzo7W-JUcAPrr8x73NBl8Pdw>
Subject: Re: [netmod] for a future rfc6991bis
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: Fri, 02 Nov 2018 14:55:48 -0000

I’ll participate as well. I agree it should be a separate YANG module and draft from the geo-location advertisement protocol specifications (currently OSPF, IS-IS, BGP, and LISP).
Thanks,
Acee

From: netmod <netmod-bounces@ietf.org> on behalf of Qin Wu <bill.wu@huawei.com>
Date: Friday, November 2, 2018 at 8:16 AM
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: netmod <netmod@ietf.org>
Subject: Re: [netmod] for a future rfc6991bis

I can volunteer to do that if this helps.
发件人: Juergen Schoenwaelder
收件人: Qin Wu<bill.wu@huawei.com<mailto:bill.wu@huawei.com>>
抄送: netmod<netmod@ietf.org<mailto:netmod@ietf.org>>
主题: Re: [netmod] for a future rfc6991bis
时间: 2018-11-02 15:23:10

It seems someone should draft an ietf-geo yang module proposal.

/js

On Fri, Nov 02, 2018 at 07:42:58AM +0000, Qin Wu wrote:
> Longitude is not defined in RFC8299, RFC8299 provide location parameter such as city, country, country-code, postal-code, street.
> https://www.ietf.org/archive/id/draft-acee-ospf-geo-location-05.txt  seems to provide a few definitions of longitude and latitude in section 2:
> https://tools.ietf.org/html/draft-seedorf-lmap-alto-02#section-6.2 provide an example of longitude usage in table 1 which use different unit(i.e.,decimal degree)
> See https://www.rapidtables.com/convert/number/degrees-to-degrees-minutes-seconds.html
> RFC6280 provide a good taxonomy of location object.
> "
>    Location Object (LO):   An object used to convey location information
>       together with Privacy Rules.  Geopriv supports both geodetic
>       location data (latitude, longitude, altitude, etc.) and civic
>       location data (street, city, state, etc.).  Either or both types
>       of location information may be present in a single LO (see the
>       considerations in [5] for LOs containing multiple locations).
>       Location Objects typically include some sort of identifier of the
>       Target.
> "
>
> -Qin
> -----邮件原件-----
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> 发送时间: 2018年11月2日 15:07
> 收件人: Qin Wu <bill.wu@huawei.com>
> 抄送: netmod <netmod@ietf.org>
> 主题: Re: [netmod] for a future rfc6991bis
>
> I searched for longitute or geo in RFC 8299 and this was not a big hit.. Concrete definitions will help. I do know about
> https://tools.ietf.org/html/draft-irtf-nmrg-location-ipfix-07 and that has been dragging on from 2012 to 2016 within the NMRG and I think this even had a life outside the NMRG before. What I am looking for is concrete (ideally YANG) definitions that people have already created and that can be the basis of a common standard. And of course an argument why location data is so essential that it has to be in ietf-yang-types and can't be in say a module ietf-geo-types.
>
> /js
>
> On Fri, Nov 02, 2018 at 03:17:21AM +0000, Qin Wu wrote:
> > Agree with this criteria, remember geo location proposal was discussed before by ALTO proponents in LMAP, in addition, location service is useful for L3VPN sevice placement, see example case in RFC8299 which can select appropriate PE based on location info. Acee also provided a valid use case in this e-mail thread.
> >
> > 发件人: Juergen Schoenwaelder
> > 收件人: Qin Wu<bill.wu@huawei.com<mailto:bill.wu@huawei.com>>
> > 抄送: netmod<netmod@ietf.org<mailto:netmod@ietf.org>>
> > 主题: Re: [netmod] for a future rfc6991bis
> > 时间: 2018-11-01 20:04:15
> >
> > I think we need to find a way to limit the update to types that are
> > known (or expected) to be 'widely' needed. In other words, for every
> > proposed type, an argument should be made why this should be included
> > in RFC 6991bis.
> >
> > /js
> >
> > On Thu, Nov 01, 2018 at 11:55:25AM +0000, Qin Wu wrote:
> > > I am wondering if we can add longitude, latitude in DMS or decimal
> > > degree, Further we can consider to add Postal-code, Country-code
> > > like Location type.
> > >
> > > -Qin
> > > -----邮件原件-----
> > > 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Juergen
> > > Schoenwaelder
> > > 发送时间: 2018年10月31日 20:47
> > > 收件人: netmod@ietf.org
> > > 主题: Re: [netmod] for a future rfc6991bis
> > >
> > > Here is my list of possible additions. I might have lost some items on a computer that meanwhile is not used anymore, I will have to dig a bit to see what I can recover.
> > >
> > > /js
> > >
> > > On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotka wrote:
> > > > Hi,
> > > >
> > > > another update that was discussed recently is a clarification of
> > > > the XPath context for the xpath1.0 type.
> > > >
> > > > Lada
> > > >
> > > > Kent Watsen <kwatsen@juniper.net> writes:
> > > >
> > > > > NETMOD WG,
> > > > >
> > > > > A conversation in NETCONF WG regarding the yang-push noted that
> > > > > it might be time to update RFC 6991, in particular to introduce a type for time-duration.
> > > > >
> > > > >
> > > > > https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZ
> > > > > NwB-
> > > > > SYBnQ
> > > > >
> > > > > In addition, it might be good to introduce [inet?] types for RFC
> > > > > 5322 (Internet Message Format) including perhaps:
> > > > >
> > > > >   - email-address        (addr-spec, per Section 3.4.1)
> > > > >   - named-email-address  (name-addr, per Section 3.4)
> > > > >
> > > > >
> > > > > Kent // contributor
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > >
> > > > _______________________________________________
> > > > 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/>

--
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/>