Hello,
We do see a need for the following types:
date (in the earlier debate as I remember Martin wanted to
include timezone)
time
node-instance-identifier from netconf-acm. We found that this
is a useful type used not just in acm, so it
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 +, Qin Wu wrote:
> I am
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-boun...@ietf.org] 代表 Juergen Schoenwaelder
发送时间: 2018年10月31日 20:47
收件人: netmod@ietf.org
主题: Re:
Hi Qin,
We'd tried to converge on geo-coordinates in the protocols and received and a
rather wide range of opinions as to the precision and what was required. An
IETF consensus is required and not everyone is going to be happy. However, I'm
not sure where this work lies and it hasn't been a
That's a good use case for geo-location service. If the geo-location
information is specified in routing protocol, I think it should also be
specified by YANG, but need to make sure they are consistent.
For precision of longitude and latitude, why not use DMS (Degree, Minute,
Second)?
-Qin
Hi Qin,
On 11/1/18, 10:44 AM, "Qin Wu" wrote:
That's a good use case for geo-location service. If the geo-location
information is specified in routing protocol, I think it should also be
specified by YANG, but need to make sure they are consistent.
For precision of longitude and
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
