date:20181102

Re: [netmod] for a future rfc6991bis

2018-11-02 Thread Juergen Schoenwaelder

What about a concrete pointer or proposal?

/js

On Fri, Nov 02, 2018 at 04:44:24PM -0400, 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  wrote:
> 
> >  Original Message -
> > From: "Juergen Schoenwaelder" 
> > To: "Kent Watsen" 
> > Cc: 
> > Sent: Tuesday, October 30, 2018 10:14 AM
> >
> > > On Tue, Oct 30, 2018 at 12:05:17AM +, Kent Watsen wrote:
> > > >
> > > > >> 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)
> > > > >>
> > > > >
> > > > > 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
> > >
> > > --
> > > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103 
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > ___
> > 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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

2018-11-02 Thread Xufeng Liu

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  wrote:

>  Original Message -
> From: "Juergen Schoenwaelder" 
> To: "Kent Watsen" 
> Cc: 
> Sent: Tuesday, October 30, 2018 10:14 AM
>
> > On Tue, Oct 30, 2018 at 12:05:17AM +, Kent Watsen wrote:
> > >
> > > >> 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)
> > > >>
> > > >
> > > > 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
> >
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

2018-11-02 Thread tom petch

 Original Message -
From: "Juergen Schoenwaelder" 
To: "Kent Watsen" 
Cc: 
Sent: Tuesday, October 30, 2018 10:14 AM

> On Tue, Oct 30, 2018 at 12:05:17AM +, Kent Watsen wrote:
> >
> > >> 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)
> > >>
> > >
> > > 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
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

2018-11-02 Thread Acee Lindem (acee)

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  on behalf of Qin Wu 
Date: Friday, November 2, 2018 at 8:16 AM
To: Juergen Schoenwaelder 
Cc: netmod 
Subject: Re: [netmod] for a future rfc6991bis

I can volunteer to do that if this helps.
发件人： Juergen Schoenwaelder
收件人： Qin Wumailto:bill...@huawei.com>>
抄送： netmodmailto: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 +, 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.schoenwael...@jacobs-university.de]
> 发送时间: 2018年11月2日 15:07
> 收件人: Qin Wu 
> 抄送: netmod 
> 主题: 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 +, 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 Wumailto:bill...@huawei.com>>
> > 抄送： netmodmailto: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 +, 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-boun...@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  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

Re: [netmod] for a future rfc6991bis

2018-11-02 Thread Qin Wu

I can volunteer to do that if this helps.

发件人： Juergen Schoenwaelder
收件人： Qin Wumailto:bill...@huawei.com>>
抄送： netmodmailto: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 +, 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.schoenwael...@jacobs-university.de]
> 发送时间: 2018年11月2日 15:07
> 收件人: Qin Wu 
> 抄送: netmod 
> 主题: 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 +, 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 Wumailto:bill...@huawei.com>>
> > 抄送： netmodmailto: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 +, 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-boun...@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  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

Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

2018-11-02 Thread Lou Berger


Hi,

    The adoption poll is closed.

Authors,

    Please submit draft-kwatsen-netmod-artwork-folding-08 as 
draft-ietf-netmod-artwork-folding-00 with only the filename and date 
changed.  Issues raised during adoption should be addressed in -01 
(including, if you are so inclined, adding an open issues section.)


Thank you,

Lou(and co-chairs)

On 10/18/2018 9:03 AM, Lou Berger wrote:

All,

This is start of a two week poll on making
draft-kwatsen-netmod-artwork-folding-08 a working group
document. Please send email to the list indicating "yes/support" or
"no/do not support".  If indicating no, please state your reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

The poll ends Oct 1.

Thanks,

Lou (and co-chairs)

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

2018-11-02 Thread Robert Wilton




On 01/11/2018 12:03, Juergen Schoenwaelder wrote:

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.

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



/js

On Thu, Nov 01, 2018 at 11:55:25AM +, 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-boun...@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  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
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 


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

2018-11-02 Thread Juergen Schoenwaelder

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

/js

On Fri, Nov 02, 2018 at 07:42:58AM +, 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.schoenwael...@jacobs-university.de] 
> 发送时间: 2018年11月2日 15:07
> 收件人: Qin Wu 
> 抄送: netmod 
> 主题: 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 +, 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 Wumailto:bill...@huawei.com>>
> > 抄送： netmodmailto: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 +, 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-boun...@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  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
> > > >

Re: [netmod] for a future rfc6991bis

2018-11-02 Thread Qin Wu

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.schoenwael...@jacobs-university.de] 
发送时间: 2018年11月2日 15:07
收件人: Qin Wu 
抄送: netmod 
主题: 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 +, 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 Wumailto:bill...@huawei.com>>
> 抄送： netmodmailto: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 +, 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-boun...@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  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 
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587

Re: [netmod] for a future rfc6991bis

2018-11-02 Thread Juergen Schoenwaelder

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 +, 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 Wumailto:bill...@huawei.com>>
> 抄送： netmodmailto: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 +, 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-boun...@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  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
> > > > 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 
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

Re: [netmod] for a future rfc6991bis

Re: [netmod] for a future rfc6991bis

Re: [netmod] for a future rfc6991bis

Re: [netmod] for a future rfc6991bis

Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

Re: [netmod] for a future rfc6991bis

Re: [netmod] for a future rfc6991bis

Re: [netmod] for a future rfc6991bis

Re: [netmod] for a future rfc6991bis

10 matches

Site Navigation

Mail list logo

Footer information