Subject: Re: [netmod] for a future rfc6991bis

From: Balázs Lengyel <[email-masked]>
Date: Thu, 1 Nov 2018 09:39:14 +0000

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 would be nice to
have it defined in 6991.

email

regards Balazs

On 2018. 10. 31. 13:46, Juergen
Schoenwaelder wrote:

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 <[email-masked]> 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/KaUJloIShkLNIXTuHZNwB-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
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Qin Wu <[email-masked]>
Date: Thu, 1 Nov 2018 11:55:25 +0000

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:[email-masked]] 代表 Juergen Schoenwaelder
发送时间: 2018年10月31日 20:47
收件人: [email-masked]
主题: 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:
> > 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.
> >
> >   
> > In addition, it might be good to introduce [inet?] types for RFC 
> > 5322 (Internet Message Format) including perhaps:
> >

-- 
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, 1 Nov 2018 13:03:57 +0100

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 1 Nov 2018 14:17:54 +0000

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 priority for me. In fact, I let my draft expire: https://www.ietf.org/archive/id/draft-acee-ospf-geo-location-05.txt. I think trying to adding these before this happens could delay the BIS update. 

Thanks,
Acee

On 11/1/18, 7:55 AM, "netmod on behalf of Qin Wu" <[email-masked] on behalf of [email-masked]> wrote:

    -Qin
    -----邮件原件-----
    发件人: netmod [mailto:[email-masked]] 代表 Juergen Schoenwaelder
    发送时间: 2018年10月31日 20:47
    收件人: [email-masked]
    主题: Re: [netmod] for a future rfc6991bis

    /js

---

From: Qin Wu <[email-masked]>
Date: Fri, 2 Nov 2018 03:17:21 +0000

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<[email-masked]<mailto:[email-masked]>>
抄送： netmod<[email-masked]<mailto:[email-masked]>>
主题： Re: [netmod] for a future rfc6991bis
时间： 2018-11-01 20:04:15

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Nov 2018 08:07:19 +0100

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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 2 Nov 2018 09:57:28 +0000

> proposed type, an argument should be made why this should be included
So my view is:
- We should limit the immediate updates to RFC 6991bis to what is easy 
to define and agree on.
- We should try and get the updated module out as quickly as the IETF 
process allows.

In parallel, we could have IDs and discussion to define YANG for email 
addresses and geo locations (could we just revive Acee's draft)?  One we 
are agreed what those definitions should be we can work out the best way 
to get them published, be that in RFC6991bis, RFC6991bisbis or a 
separate RFC.

Thanks,
Rob

---

From: tom petch <[email-masked]>
Date: Fri, 2 Nov 2018 15:38:53 +0000

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Kent Watsen" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 30, 2018 10:14 AM

> On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
> >
5322
> > > Where are these used? Or have these already been used somewhere?
> >
> > I'm unaware of these ever having been used before.  I am working on
a private module for which I want to configure an email address.  After
some searching, I concluded that no such types have been defined, and
thus thought that they might be good candidates for addition.

We could defined a user-name, of the form localpart@domainpart as is
widely used to identify a user in operations but which does not, in my
experience, owe anything to i18n, just a straightforward character set;
yes it would not boil the ocean, but could be useful.  I am surprised
not to find such a definition somewhere in our 40 or so NETCONF I-Ds.

Tom Petch

> >
>
> It would be good to have strong use cases. I fear that defining this
> type won't be easy given that we also have internationalized email
> addresses (RFC 6530 provides an overview) and we might have to create
> a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
>
> /js
>
> --

---

From: Xufeng Liu <[email-masked]>
Date: Fri, 2 Nov 2018 16:44:24 -0400

Remember that some draft asked for a type of percentage value to the
nearest hundredth. Wondering if it can be put in.

Thanks,
- Xufeng

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Nov 2018 22:33:10 +0100

What about a concrete pointer or proposal?

/js

---

From: Balázs Lengyel <[email-masked]>
Date: Sun, 4 Nov 2018 12:07:46 +0000

+1 to percentage.

Balazs

On 2018. 11. 03. 3:44, Xufeng Liu
wrote:

Remember that some draft asked for a type of
percentage value to the nearest hundredth. Wondering if it can
be put in.

Thanks,

- Xufeng

On Fri, Nov 2, 2018 at 11:39 AM tom petch <[email-masked]>
wrote:

----
Original Message -----

Cc: <[email-masked]>

5322

> > I'm unaware of these ever having been used before.
I am working on

a private module for which I want to configure an email
address.  After

some searching, I concluded that no such types have been
defined, and

We could defined a user-name, of the form localpart@domainpart
as is

widely used to identify a user in operations but which does
not, in my

experience, owe anything to i18n, just a straightforward
character set;

yes it would not boil the ocean, but could be useful.  I am
surprised

not to find such a definition somewhere in our 40 or so
NETCONF I-Ds.

Tom Petch

netmod mailing list

[email-masked]

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 5 Nov 2018 15:48:44 -0500

The draft that asked for the percentage type is:
https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02

They currently define:

              leaf availability {
                type decimal64 {
                  fraction-digits 4;
                  range "0..99.9999";
                }
                description "Availability level of the link";
              }

Thanks,
- Xufeng

On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel <[email-masked]>
wrote:

> +1 to percentage.
>
> Balazs
> On 2018. 11. 03. 3:44, Xufeng Liu wrote:
>
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Nov 2018 23:48:57 +0100

Apparently people have different needs concerning precision...

/js

On Mon, Nov 05, 2018 at 03:48:44PM -0500, Xufeng Liu wrote:
> On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel <balazs.lengyel@ericsson..com>
> wrote:
> 
> > +1 to percentage.
> >
> > Balazs