subject:"\[netmod\] for a future rfc6991bis"

Re: [netmod] for a future rfc6991bis

2018-12-31 Thread Acee Lindem (acee)

Hi Tom, Juergen, 
I agree with Juergen - we went through this discussion with ietf-routing-types 
(RFC 8294) and came to the same conclusion. We kept, the generic 
link-access-type enum but I believe it is, heretofore, unused. 
Thanks,
Acee

On 12/31/18, 7:48 AM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

Tom,

since states are often protocol specific, I believe we are better off
with having states defined with protocol specific semantics. If you go
for generic states, then you end up with mappings of generic states to
protocol specific states, which are often non-trivial to get right and
meaningful.

/js

On Mon, Dec 31, 2018 at 12:29:34PM +, tom petch wrote:
> Many (most?) routing protocols introduce a state - up, down +- coming
> up, going down, maintenance and such like, used for interfaces, tunnels,
> adjacencies and the like.  It is a shame that there are so many
> variations on this although to some extent this reflects the differences
> in the protocols.  And some use types, others identity.
> 
> Tom Petch
> 
> 
> - Original Message -
> From: "Juergen Schoenwaelder" 
> Sent: Friday, November 30, 2018 11:56 AM
> 
> > This is already on my list (was already proposed by Balázs).
> >
> > /js
> >
> > On Fri, Nov 30, 2018 at 11:25:44AM +0100, Martin Bjorklund wrote:
> > > Balázs Lengyel  wrote:
> > > > Hello,
> > > >
> > > > In a similar manner we found multiple uses for the
> > > > ietf-netconf-acm:node-instance-identifier. We
> > > > imported nacm just to reuse this type.
> > > > Anyone else interested?
> > >
> > > Yes, this is a useful type that is not just NACM-specific.  We also
> > > use in various places.
> > >
> > >
> > > /martin
> > >
> > >
> > > >
> > > > regards Balazs
> > > >
> > > > On 2018. 11. 29. 12:03, Robert Wilton wrote:
> > > >
> > > >  Hi Juergen,
> > > >
> > > >  YANG library currently defines the type "revision-identifer". Is
> this a typedef that should
> > > >  logically migrate to rfc6991bis?
> > > >
> > > >  Thanks,
> > > >  Rob
> > > >
> > > >  On 14/11/2018 08:16, Ladislav Lhotka wrote:
> > > >
> > > >  On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:
> > > >
> > > >  Hi,
> > > >
> > > >  Alex Campbell  wrote:
> > > >
> > > >  Does a percentage really need a single standard type in the first
> > > >  place? How about "units percent;"?
> > > >
> > > >  At this point, after hearing about how different modules have
> > > >  differing requirement on this type, I tend to agree.
> > > >
> > > >  +1
> > > >
> > > >  Or even "units %;"
> > > >
> > > >  Lada
> > > >
> > > >  /martin
> > > >
> > > >  
> > > >  From: netmod  on behalf of Acee Lindem
> (acee)
> > > >  
> > > >  Sent: Wednesday, 14 November 2018 5:03 a.m.
> > > >  To: Juergen Schoenwaelder; Balázs Lengyel
> > > >  Cc: NETMOD WG
> > > >  Subject: Re: [netmod] for a future rfc6991bis
> > > >
> > > >  On 11/13/18, 9:07 AM, "netmod on behalf of Juergen
> Schoenwaelder"
> > > >   > > >  j.schoenwael...@jacobs-university.de> wrote:
> > > >
> > > >  On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> > > >  > Hello,
> > > >  >
> > > >  > In some cases I want a percentage without fractions. This could
> be
> > > >  > defined
> > > >  > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100
> in the
> > > >  > range's
> > > >  > argument.
> > > >  >
> > > >  > typedef percent-short {
> > > >  > type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type

Re: [netmod] for a future rfc6991bis

2018-12-31 Thread Juergen Schoenwaelder

Tom,

since states are often protocol specific, I believe we are better off
with having states defined with protocol specific semantics. If you go
for generic states, then you end up with mappings of generic states to
protocol specific states, which are often non-trivial to get right and
meaningful.

/js

On Mon, Dec 31, 2018 at 12:29:34PM +, tom petch wrote:
> Many (most?) routing protocols introduce a state - up, down +- coming
> up, going down, maintenance and such like, used for interfaces, tunnels,
> adjacencies and the like.  It is a shame that there are so many
> variations on this although to some extent this reflects the differences
> in the protocols.  And some use types, others identity.
> 
> Tom Petch
> 
> 
> - Original Message -
> From: "Juergen Schoenwaelder" 
> Sent: Friday, November 30, 2018 11:56 AM
> 
> > This is already on my list (was already proposed by Balázs).
> >
> > /js
> >
> > On Fri, Nov 30, 2018 at 11:25:44AM +0100, Martin Bjorklund wrote:
> > > Balázs Lengyel  wrote:
> > > > Hello,
> > > >
> > > > In a similar manner we found multiple uses for the
> > > > ietf-netconf-acm:node-instance-identifier. We
> > > > imported nacm just to reuse this type.
> > > > Anyone else interested?
> > >
> > > Yes, this is a useful type that is not just NACM-specific.  We also
> > > use in various places.
> > >
> > >
> > > /martin
> > >
> > >
> > > >
> > > > regards Balazs
> > > >
> > > > On 2018. 11. 29. 12:03, Robert Wilton wrote:
> > > >
> > > >  Hi Juergen,
> > > >
> > > >  YANG library currently defines the type "revision-identifer". Is
> this a typedef that should
> > > >  logically migrate to rfc6991bis?
> > > >
> > > >  Thanks,
> > > >  Rob
> > > >
> > > >  On 14/11/2018 08:16, Ladislav Lhotka wrote:
> > > >
> > > >  On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:
> > > >
> > > >  Hi,
> > > >
> > > >  Alex Campbell  wrote:
> > > >
> > > >  Does a percentage really need a single standard type in the first
> > > >  place? How about "units percent;"?
> > > >
> > > >  At this point, after hearing about how different modules have
> > > >  differing requirement on this type, I tend to agree.
> > > >
> > > >  +1
> > > >
> > > >  Or even "units %;"
> > > >
> > > >  Lada
> > > >
> > > >  /martin
> > > >
> > > >  
> > > >  From: netmod  on behalf of Acee Lindem
> (acee)
> > > >  
> > > >  Sent: Wednesday, 14 November 2018 5:03 a.m.
> > > >  To: Juergen Schoenwaelder; Balázs Lengyel
> > > >  Cc: NETMOD WG
> > > >  Subject: Re: [netmod] for a future rfc6991bis
> > > >
> > > >  On 11/13/18, 9:07 AM, "netmod on behalf of Juergen
> Schoenwaelder"
> > > >   > > >  j.schoenwael...@jacobs-university.de> wrote:
> > > >
> > > >  On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> > > >  > Hello,
> > > >  >
> > > >  > In some cases I want a percentage without fractions. This could
> be
> > > >  > defined
> > > >  > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100
> in the
> > > >  > range's
> > > >  > argument.
> > > >  >
> > > >  > typedef percent-short {
> > > >  > type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type
> > > >  out
> > > >  > all the 101 integer values :-)
> > > >  > }
> > > >  >
> > > >
> > > >  I guess we need to settle on a small number of percentage types
> that
> > > >  people find useful and then module authors hopefully find what
> they
> > > >  need. I am not sure that listing 101 numbers is a good pattern to
> use
> > > >  (although it does achieve what you want). For percentages that
> have no
> > > >  fraction, you likely want to derive from a base type that is
> efficient
> > > >  to encode for binary encodings such as CBOR.
> > > >
> > > >  Or simply define a type with a base type of unit8 type an

Re: [netmod] for a future rfc6991bis

2018-12-31 Thread tom petch

Many (most?) routing protocols introduce a state - up, down +- coming
up, going down, maintenance and such like, used for interfaces, tunnels,
adjacencies and the like.  It is a shame that there are so many
variations on this although to some extent this reflects the differences
in the protocols.  And some use types, others identity.

Tom Petch


- Original Message -
From: "Juergen Schoenwaelder" 
Sent: Friday, November 30, 2018 11:56 AM

> This is already on my list (was already proposed by Balázs).
>
> /js
>
> On Fri, Nov 30, 2018 at 11:25:44AM +0100, Martin Bjorklund wrote:
> > Balázs Lengyel  wrote:
> > > Hello,
> > >
> > > In a similar manner we found multiple uses for the
> > > ietf-netconf-acm:node-instance-identifier. We
> > > imported nacm just to reuse this type.
> > > Anyone else interested?
> >
> > Yes, this is a useful type that is not just NACM-specific.  We also
> > use in various places.
> >
> >
> > /martin
> >
> >
> > >
> > > regards Balazs
> > >
> > > On 2018. 11. 29. 12:03, Robert Wilton wrote:
> > >
> > >  Hi Juergen,
> > >
> > >  YANG library currently defines the type "revision-identifer". Is
this a typedef that should
> > >  logically migrate to rfc6991bis?
> > >
> > >  Thanks,
> > >  Rob
> > >
> > >  On 14/11/2018 08:16, Ladislav Lhotka wrote:
> > >
> > >  On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:
> > >
> > >  Hi,
> > >
> > >  Alex Campbell  wrote:
> > >
> > >  Does a percentage really need a single standard type in the first
> > >  place? How about "units percent;"?
> > >
> > >  At this point, after hearing about how different modules have
> > >  differing requirement on this type, I tend to agree.
> > >
> > >  +1
> > >
> > >  Or even "units %;"
> > >
> > >  Lada
> > >
> > >  /martin
> > >
> > >  
> > >  From: netmod  on behalf of Acee Lindem
(acee)
> > >  
> > >  Sent: Wednesday, 14 November 2018 5:03 a.m.
> > >  To: Juergen Schoenwaelder; Balázs Lengyel
> > >  Cc: NETMOD WG
> > >  Subject: Re: [netmod] for a future rfc6991bis
> > >
> > >  On 11/13/18, 9:07 AM, "netmod on behalf of Juergen
Schoenwaelder"
> > >   > >  j.schoenwael...@jacobs-university.de> wrote:
> > >
> > >  On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> > >  > Hello,
> > >  >
> > >  > In some cases I want a percentage without fractions. This could
be
> > >  > defined
> > >  > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100
in the
> > >  > range's
> > >  > argument.
> > >  >
> > >  > typedef percent-short {
> > >  > type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type
> > >  out
> > >  > all the 101 integer values :-)
> > >  > }
> > >  >
> > >
> > >  I guess we need to settle on a small number of percentage types
that
> > >  people find useful and then module authors hopefully find what
they
> > >  need. I am not sure that listing 101 numbers is a good pattern to
use
> > >  (although it does achieve what you want). For percentages that
have no
> > >  fraction, you likely want to derive from a base type that is
efficient
> > >  to encode for binary encodings such as CBOR.
> > >
> > >  Or simply define a type with a base type of unit8 type and a
range of
> > >  0-100.
> > >
> > >  Acee
> > >
> > >  /js
> > >
> > >  --
> > >  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
> > >
> > >  ___
> > >  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
> > >
> > >  ___
> > >  netmod mailing list
> > >  netmod@ietf.org
> > >  https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Balazs Lengyel   Ericsson Hungary Ltd.
> > > Senior Specialist
> > > Mobile: +36-70-330-7909  email:
balazs.leng...@ericsson.com
>
> --
> 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
>

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

Re: [netmod] for a future rfc6991bis

2018-11-30 Thread Juergen Schoenwaelder

This is already on my list (was already proposed by Balázs).

/js

On Fri, Nov 30, 2018 at 11:25:44AM +0100, Martin Bjorklund wrote:
> Balázs Lengyel  wrote:
> > Hello,
> > 
> > In a similar manner we found multiple uses for the
> > ietf-netconf-acm:node-instance-identifier. We
> > imported nacm just to reuse this type.
> > Anyone else interested?
> 
> Yes, this is a useful type that is not just NACM-specific.  We also
> use in various places.
> 
> 
> /martin
> 
> 
> > 
> > regards Balazs
> > 
> > On 2018. 11. 29. 12:03, Robert Wilton wrote:
> > 
> >  Hi Juergen,
> > 
> >  YANG library currently defines the type "revision-identifer". Is this a 
> > typedef that should
> >  logically migrate to rfc6991bis?
> > 
> >  Thanks,
> >  Rob
> > 
> >  On 14/11/2018 08:16, Ladislav Lhotka wrote:
> > 
> >  On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:
> > 
> >  Hi,
> > 
> >  Alex Campbell  wrote:
> > 
> >  Does a percentage really need a single standard type in the first
> >  place? How about "units percent;"?
> > 
> >  At this point, after hearing about how different modules have
> >  differing requirement on this type, I tend to agree.
> > 
> >  +1
> > 
> >  Or even "units %;"
> > 
> >  Lada
> > 
> >  /martin
> > 
> >  
> >  From: netmod  on behalf of Acee Lindem (acee)
> >  
> >  Sent: Wednesday, 14 November 2018 5:03 a.m.
> >  To: Juergen Schoenwaelder; Balázs Lengyel
> >  Cc: NETMOD WG
> >  Subject: Re: [netmod] for a future rfc6991bis
> > 
> >  On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder"
> >   >  j.schoenwael...@jacobs-university.de> wrote:
> > 
> >  On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> >  > Hello,
> >  >
> >  > In some cases I want a percentage without fractions. This could be
> >  > defined
> >  > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the
> >  > range's
> >  > argument.
> >  >
> >  > typedef percent-short {
> >  > type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type
> >  out
> >  > all the 101 integer values :-)
> >  > }
> >  >
> > 
> >  I guess we need to settle on a small number of percentage types that
> >  people find useful and then module authors hopefully find what they
> >  need. I am not sure that listing 101 numbers is a good pattern to use
> >  (although it does achieve what you want). For percentages that have no
> >  fraction, you likely want to derive from a base type that is efficient
> >  to encode for binary encodings such as CBOR.
> > 
> >  Or simply define a type with a base type of unit8 type and a range of
> >  0-100.
> > 
> >  Acee
> > 
> >  /js
> > 
> >  --
> >  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
> > 
> >  ___
> >  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
> > 
> >  ___
> >  netmod mailing list
> >  netmod@ietf.org
> >  https://www.ietf.org/mailman/listinfo/netmod
> > 
> > --
> > Balazs Lengyel   Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] for a future rfc6991bis

2018-11-30 Thread Martin Bjorklund

Balázs Lengyel  wrote:
> Hello,
> 
> In a similar manner we found multiple uses for the
> ietf-netconf-acm:node-instance-identifier. We
> imported nacm just to reuse this type.
> Anyone else interested?

Yes, this is a useful type that is not just NACM-specific.  We also
use in various places.


/martin


> 
> regards Balazs
> 
> On 2018. 11. 29. 12:03, Robert Wilton wrote:
> 
>  Hi Juergen,
> 
>  YANG library currently defines the type "revision-identifer". Is this a 
> typedef that should
>  logically migrate to rfc6991bis?
> 
>  Thanks,
>  Rob
> 
>  On 14/11/2018 08:16, Ladislav Lhotka wrote:
> 
>  On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:
> 
>  Hi,
> 
>  Alex Campbell  wrote:
> 
>  Does a percentage really need a single standard type in the first
>  place? How about "units percent;"?
> 
>  At this point, after hearing about how different modules have
>  differing requirement on this type, I tend to agree.
> 
>  +1
> 
>  Or even "units %;"
> 
>  Lada
> 
>  /martin
> 
>  
>  From: netmod  on behalf of Acee Lindem (acee)
>  
>  Sent: Wednesday, 14 November 2018 5:03 a.m.
>  To: Juergen Schoenwaelder; Balázs Lengyel
>  Cc: NETMOD WG
>  Subject: Re: [netmod] for a future rfc6991bis
> 
>  On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder"
>j.schoenwael...@jacobs-university.de> wrote:
> 
>  On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
>  > Hello,
>  >
>  > In some cases I want a percentage without fractions. This could be
>  > defined
>  > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the
>  > range's
>  > argument.
>  >
>  > typedef percent-short {
>  > type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type
>  out
>  > all the 101 integer values :-)
>  > }
>  >
> 
>  I guess we need to settle on a small number of percentage types that
>  people find useful and then module authors hopefully find what they
>  need. I am not sure that listing 101 numbers is a good pattern to use
>  (although it does achieve what you want). For percentages that have no
>  fraction, you likely want to derive from a base type that is efficient
>  to encode for binary encodings such as CBOR.
> 
>  Or simply define a type with a base type of unit8 type and a range of
>  0-100.
> 
>  Acee
> 
>  /js
> 
>  --
>  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
> 
>  ___
>  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
> 
>  ___
>  netmod mailing list
>  netmod@ietf.org
>  https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

2018-11-30 Thread Balázs Lengyel


  
  
Hello, 

In a similar manner we found multiple uses for the ietf-netconf-acm:node-instance-identifier.
  We imported nacm just to reuse this type.
  Anyone else interested?
regards Balazs

On 2018. 11. 29. 12:03, Robert Wilton
  wrote:

Hi
  Juergen,
  
  
  YANG library currently defines the type "revision-identifer".  Is
  this a typedef that should logically migrate to rfc6991bis?
  
  
  Thanks,
  
  Rob
  
  
  On 14/11/2018 08:16, Ladislav Lhotka wrote:
  
  On Wed, 2018-11-14 at 09:10 +0100, Martin
Bjorklund wrote:

Hi,
  
  
  Alex Campbell  wrote:
  
  Does a percentage really need a single
standard type in the first

place? How about "units percent;"?

  
  At this point, after hearing about how different modules have
  
  differing requirement on this type, I tend to agree.
  

+1


Or even "units %;"


Lada



  
  /martin
  
  
  
  

From: netmod  on behalf of
Acee Lindem (acee)



Sent: Wednesday, 14 November 2018 5:03 a.m.

To: Juergen Schoenwaelder; Balázs Lengyel

Cc: NETMOD WG
    
    Subject: Re: [netmod] for a future rfc6991bis


On 11/13/18, 9:07 AM, "netmod on behalf of Juergen
Schoenwaelder"

<netmod-boun...@ietf.org on behalf of

j.schoenwael...@jacobs-university.de> wrote:


 On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs
Lengyel wrote:

 > Hello,

 >

 > In some cases I want a percentage without
fractions. This could be

 > defined

 > using range, by specifying the numbers 0 | 1 | 2
... 99 | 100 in the

 > range's

 > argument.

 >

 > typedef percent-short {

 >   type percent { range 0 | 1 | 2 ... 99 | 100;
} // didn't type

out

 >   all the 101 integer values :-)

 > }

 >


 I guess we need to settle on a small number of
percentage types that

 people find useful and then module authors hopefully
find what they

 need. I am not sure that listing 101 numbers is a good
pattern to use

 (although it does achieve what you want). For
percentages that have no

 fraction, you likely want to derive from a base type
that is efficient

 to encode for binary encodings such as CBOR.


Or simply define a type with a base type of unit8 type and a
range of

0-100.


Acee






 /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-29 Thread Robert Wilton

On 29/11/2018 16:34, Juergen Schoenwaelder wrote:

Rob,

I have added this to my list of things to look at. Whether we do this
or not may also depend on how the final date solution will look like
and whether people feel it is worth to move this out of rfc6991bis,
i.e., such a YANG revision-identifer is useful for modules that do
not want to depend on rfc6991bis.

Thanks.  Sounds sensible to me.

Rob

/js

On Thu, Nov 29, 2018 at 11:03:45AM +, Robert Wilton wrote:

Hi Juergen,

YANG library currently defines the type "revision-identifer".  Is this a
typedef that should logically migrate to rfc6991bis?

Thanks,
Rob

On 14/11/2018 08:16, Ladislav Lhotka wrote:

On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:

Hi,

Alex Campbell  wrote:

Does a percentage really need a single standard type in the first
place? How about "units percent;"?

At this point, after hearing about how different modules have
differing requirement on this type, I tend to agree.

+1

Or even "units %;"

Lada

/martin

From: netmod  on behalf of Acee Lindem (acee)

Sent: Wednesday, 14 November 2018 5:03 a.m.
To: Juergen Schoenwaelder; Balázs Lengyel
Cc: NETMOD WG
Subject: Re: [netmod] for a future rfc6991bis

On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder"
 wrote:

  On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
  > Hello,
  >
  > In some cases I want a percentage without fractions. This could be
  > defined
  > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the
  > range's
  > argument.
  >
  > typedef percent-short {
  >   type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type
out
  >   all the 101 integer values :-)
  > }
  >

  I guess we need to settle on a small number of percentage types that
  people find useful and then module authors hopefully find what they
  need. I am not sure that listing 101 numbers is a good pattern to use
  (although it does achieve what you want). For percentages that have no
  fraction, you likely want to derive from a base type that is efficient
  to encode for binary encodings such as CBOR.

Or simply define a type with a base type of unit8 type and a range of
0-100.

Acee

  /js

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

___
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

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

Re: [netmod] for a future rfc6991bis

2018-11-29 Thread Juergen Schoenwaelder

Rob,

I have added this to my list of things to look at. Whether we do this
or not may also depend on how the final date solution will look like
and whether people feel it is worth to move this out of rfc6991bis,
i.e., such a YANG revision-identifer is useful for modules that do
not want to depend on rfc6991bis.

/js

On Thu, Nov 29, 2018 at 11:03:45AM +, Robert Wilton wrote:
> Hi Juergen,
> 
> YANG library currently defines the type "revision-identifer".  Is this a
> typedef that should logically migrate to rfc6991bis?
> 
> Thanks,
> Rob
> 
> On 14/11/2018 08:16, Ladislav Lhotka wrote:
> > On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > Alex Campbell  wrote:
> > > > Does a percentage really need a single standard type in the first
> > > > place? How about "units percent;"?
> > > At this point, after hearing about how different modules have
> > > differing requirement on this type, I tend to agree.
> > +1
> > 
> > Or even "units %;"
> > 
> > Lada
> > 
> > > 
> > > /martin
> > > 
> > > 
> > > > ____
> > > > From: netmod  on behalf of Acee Lindem (acee)
> > > > 
> > > > Sent: Wednesday, 14 November 2018 5:03 a.m.
> > > > To: Juergen Schoenwaelder; Balázs Lengyel
> > > > Cc: NETMOD WG
> > > > Subject: Re: [netmod] for a future rfc6991bis
> > > > 
> > > > On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder"
> > > >  > > > j.schoenwael...@jacobs-university.de> wrote:
> > > > 
> > > >  On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> > > >  > Hello,
> > > >  >
> > > >  > In some cases I want a percentage without fractions. This could 
> > > > be
> > > >  > defined
> > > >  > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in 
> > > > the
> > > >  > range's
> > > >  > argument.
> > > >  >
> > > >  > typedef percent-short {
> > > >  >   type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't 
> > > > type
> > > > out
> > > >  >   all the 101 integer values :-)
> > > >  > }
> > > >  >
> > > > 
> > > >  I guess we need to settle on a small number of percentage types 
> > > > that
> > > >  people find useful and then module authors hopefully find what they
> > > >  need. I am not sure that listing 101 numbers is a good pattern to 
> > > > use
> > > >  (although it does achieve what you want). For percentages that 
> > > > have no
> > > >  fraction, you likely want to derive from a base type that is 
> > > > efficient
> > > >  to encode for binary encodings such as CBOR.
> > > > 
> > > > Or simply define a type with a base type of unit8 type and a range of
> > > > 0-100.
> > > > 
> > > > Acee
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  /js
> > > > 
> > > >  --
> > > >  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
> > > > 
> > > > 
> > > > ___
> > > > 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

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

Re: [netmod] for a future rfc6991bis

2018-11-29 Thread Robert Wilton

Hi Juergen,

YANG library currently defines the type "revision-identifer".  Is this a 
typedef that should logically migrate to rfc6991bis?

Thanks,
Rob

On 14/11/2018 08:16, Ladislav Lhotka wrote:

On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:

Hi,

Alex Campbell  wrote:

Does a percentage really need a single standard type in the first
place? How about "units percent;"?

At this point, after hearing about how different modules have
differing requirement on this type, I tend to agree.

+1

Or even "units %;"

Lada

/martin

From: netmod  on behalf of Acee Lindem (acee)

Sent: Wednesday, 14 November 2018 5:03 a.m.
To: Juergen Schoenwaelder; Balázs Lengyel
Cc: NETMOD WG
Subject: Re: [netmod] for a future rfc6991bis

On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder"
 wrote:

 On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
 > Hello,
 >
 > In some cases I want a percentage without fractions. This could be
 > defined
 > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the
 > range's
 > argument.
 >
 > typedef percent-short {
 >   type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type
out
 >   all the 101 integer values :-)
 > }
 >

 I guess we need to settle on a small number of percentage types that
 people find useful and then module authors hopefully find what they
 need. I am not sure that listing 101 numbers is a good pattern to use
 (although it does achieve what you want). For percentages that have no
 fraction, you likely want to derive from a base type that is efficient
 to encode for binary encodings such as CBOR.

Or simply define a type with a base type of unit8 type and a range of
0-100.

Acee

 /js

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

___
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

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

Re: [netmod] for a future rfc6991bis

2018-11-14 Thread Martin Bjorklund

Hi,

Alex Campbell  wrote:
> Does a percentage really need a single standard type in the first
> place? How about "units percent;"?

At this point, after hearing about how different modules have
differing requirement on this type, I tend to agree.


/martin


> 
> 
> From: netmod  on behalf of Acee Lindem (acee)
> 
> Sent: Wednesday, 14 November 2018 5:03 a.m.
> To: Juergen Schoenwaelder; Balázs Lengyel
> Cc: NETMOD WG
> Subject: Re: [netmod] for a future rfc6991bis
> 
> On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder"
>  j.schoenwael...@jacobs-university.de> wrote:
> 
> On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> > Hello,
> >
> > In some cases I want a percentage without fractions. This could be
> > defined
> > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the
> > range's
> > argument.
> >
> > typedef percent-short {
> >   type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type out
> >   all the 101 integer values :-)
> > }
> >
> 
> I guess we need to settle on a small number of percentage types that
> people find useful and then module authors hopefully find what they
> need. I am not sure that listing 101 numbers is a good pattern to use
> (although it does achieve what you want). For percentages that have no
> fraction, you likely want to derive from a base type that is efficient
> to encode for binary encodings such as CBOR.
> 
> Or simply define a type with a base type of unit8 type and a range of
> 0-100.
> 
> Acee
> 
> 
> 
> 
> 
> /js
> 
> --
> 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
> 
> 
> ___
> 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-13 Thread Alex Campbell

Does a percentage really need a single standard type in the first place? How 
about "units percent;"?

From: netmod  on behalf of Acee Lindem (acee) 

Sent: Wednesday, 14 November 2018 5:03 a.m.
To: Juergen Schoenwaelder; Balázs Lengyel
Cc: NETMOD WG
Subject: Re: [netmod] for a future rfc6991bis

On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder" 

wrote:

On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> Hello,
>
> In some cases I want a percentage without fractions. This could be defined
> using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the 
range's
> argument.
>
> typedef percent-short {
>   type percent { range 0 | 1 | 2 ... 99 | 100; }  // didn't type out 
all the 101 integer values :-)
> }
>

I guess we need to settle on a small number of percentage types that
people find useful and then module authors hopefully find what they
need. I am not sure that listing 101 numbers is a good pattern to use
(although it does achieve what you want). For percentages that have no
fraction, you likely want to derive from a base type that is efficient
to encode for binary encodings such as CBOR.

Or simply define a type with a base type of unit8 type and a range of 0-100.

Acee

/js

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

___
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-13 Thread Acee Lindem (acee)

On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder" 

wrote:

On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> Hello,
> 
> In some cases I want a percentage without fractions. This could be defined
> using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the 
range's
> argument.
> 
> typedef percent-short {
>   type percent { range 0 | 1 | 2 ... 99 | 100; }  // didn't type out 
all the 101 integer values :-)
> }
>

I guess we need to settle on a small number of percentage types that
people find useful and then module authors hopefully find what they
need. I am not sure that listing 101 numbers is a good pattern to use
(although it does achieve what you want). For percentages that have no
fraction, you likely want to derive from a base type that is efficient
to encode for binary encodings such as CBOR.

Or simply define a type with a base type of unit8 type and a range of 0-100. 

Acee 

/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-13 Thread Juergen Schoenwaelder

On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> Hello,
> 
> In some cases I want a percentage without fractions. This could be defined
> using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the range's
> argument.
> 
> typedef percent-short {
>   type percent { range 0 | 1 | 2 ... 99 | 100; }  // didn't type out all 
> the 101 integer values :-)
> }
>

I guess we need to settle on a small number of percentage types that
people find useful and then module authors hopefully find what they
need. I am not sure that listing 101 numbers is a good pattern to use
(although it does achieve what you want). For percentages that have no
fraction, you likely want to derive from a base type that is efficient
to encode for binary encodings such as CBOR.

/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

Re: [netmod] for a future rfc6991bis

2018-11-13 Thread Balázs Lengyel


Hello,

In some cases I want a percentage without fractions. This could be 
defined using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in 
the range's argument.


typedef percent-short {
  type percent { range 0 | 1 | 2 ... 99 | 100; }  // didn't type out all 
the 101 integer values :-)
}

regards Balazs

On 2018. 11. 07. 9:34, Juergen Schoenwaelder wrote:

On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:


For the range, if the defintion can cover the our range(0..99.),
it will be acceptable.  In your suggestion below, does that mean the
base defintion is without range, while refined types can chosse the
range they like?

I was thinking loud. Let me detail somewhat more what was going on in
my head:

   We could define a percent type without the upper bound being
   whatever the decimal covers but fixing the precision of the
   fractional part. We could then narrow the upper bound via
   subtyping:

  typedef percent {
type decimal {
  fraction-digits 4;
  range "0..max";
}
  }

  typedef percent' {
type percent { range 0..100; }
  }

   If wanted flexibility on the fractional part, we could define
   percent with a fixed range and the largest number of fraction digits
   possible and then we could subtype this to obtain a precision that
   makes sense in the usage contexts (although it is not clear whether
   YANG 1.1 really allows this, if not this may be just due to nobody
   ever thinking about this before):

 typedef percent {
   type decimal {
 fraction-digits 16;
 range 0..100;
   }
 }

 typedef percent' {
   type percent { fraction-digits 4; }
 }

   An ideal solution would provide flexibility both on the range and
   the number of fraction digits but it seems this is impossible since
   these two properties (range and precision) interact.

So it seems we have to do something that is pragmatic and this likely
means fixing the fraction since subtyping the fractional part may not
be allowed by YANG or not be supported by implementations. The
question is then how we pick suitable fractions. I understand you want
4 digits.

/js


BR,
Amy

发件人: Juergen Schoenwaelder [j.schoenwael...@jacobs-university.de]
发送时间: 2018年11月6日 22:16
收件人: Yemin (Amy)
抄送: Qin Wu; Xufeng Liu; balazs.leng...@ericsson.com; NETMOD WG
主题: Re: [netmod] for a future rfc6991bis

Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
which is likely not generally useful. In fact, even 150% can be in
some contexts a perfectly sensible percentage. So we may need to
provide some flexibility here, i.e., having a base time where the
range can be refined and refined types with an upper limit set to 100%
for use in situations where this limit is sensible.

The more difficult aspect seems to be precision, I am not sure YANG
allows subtyping the fractional part. RFC 7950 seems to be silent
about this and in the general case this would not be meaningful. But
in this particular case, when the number range is limited, it would
actually be OK to allow this (but then we have to have a limit and
we can't set the upper limit to max).

/js

On Tue, Nov 06, 2018 at 02:21:33AM +, Yemin (Amy) wrote:

If the percentage is defined as following, as a author of 
draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
But it's better to include in RFC6991bis, as percentage is a generic and widely 
used item.

BR,
Amy

发件人: netmod [netmod-boun...@ietf.org] 代表 Qin Wu [bill...@huawei.com]
发送时间: 2018年11月6日 9:25
收件人: Xufeng Liu; balazs.leng...@ericsson.com
抄送: NETMOD WG
主题: Re: [netmod] for a future rfc6991bis


Another case would be :


“

typedef percentage {

   type decimal64 {

  fraction-digits 5;

  range "0..100";

  }

description "Percentage.";
}
”
Which is defined ietf-connectionless-oam.yang module.

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Xufeng Liu
发送时间: 2018年11月6日 3:49
收件人: balazs.leng...@ericsson.com
抄送: NETMOD WG 
主题: Re: [netmod] for a future rfc6991bis

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.";
 }
 description "Availability level of the link";
   }

Thanks,
- Xufeng

On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:

+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 
mailto:ie...@btconnect.com>> w

Re: [netmod] for a future rfc6991bis

2018-11-07 Thread Per Hedeland

On 2018-11-07 16:56, Qin Wu wrote:
> -®öö-
> Ñöº: netmod [mailto:netmod-boun...@ietf.org] ãh Per Hedeland
> Ñöô: 2018t117å 15:57
> 6öº: Juergen Schoenwaelder 
> : NETMOD WG 
> ;: Re: [netmod] for a future rfc6991bis
> 
> On 2018-11-07 09:34, Juergen Schoenwaelder wrote:
>> On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:
>>
>>> For the range, if the defintion can cover the our range(0..99.), 
>>> it will be acceptable.  In your suggestion below, does that mean the 
>>> base defintion is without range, while refined types can chosse the 
>>> range they like?
>>
>> I was thinking loud. Let me detail somewhat more what was going on in 
>> my head:
>>
>>We could define a percent type without the upper bound being
>>whatever the decimal covers but fixing the precision of the
>>fractional part. We could then narrow the upper bound via
>>subtyping:
>>
>>   typedef percent {
>> type decimal {
>>   fraction-digits 4;
>>   range "0..max";
>> }
>>   }
>>
>>   typedef percent' {
>> type percent { range 0..100; }
>>   }
>>
>>If wanted flexibility on the fractional part, we could define
>>percent with a fixed range and the largest number of fraction digits
>>possible and then we could subtype this to obtain a precision that
>>makes sense in the usage contexts (although it is not clear whether
>>YANG 1.1 really allows this, if not this may be just due to nobody
>>ever thinking about this before):
> 
> I believe it is quite clear that this is *not* allowed:
> 
>9.3.3.  Restrictions
> 
>   A decimal64 type can be restricted with the "range" statement
>   (Section 9.2.4).
> 
> --Per
> 
> [Qin]: Section 9.2.4 said:
> "
> If a range restriction is applied to a type that is
>already range-restricted, the new restriction MUST be equally
>limiting or more limiting, i.e., raising the lower bounds, reducing
>the upper bounds, removing explicit values or ranges, or splitting
>ranges into multiple ranges with intermediate gaps.
> "
> I am not sure the above example really violates the rule described above.

No, it's the example *below* - that Juergen was referring to above with
the "it is not clear whether YANG 1.1 really allows this" that I replied
to - that does. I.e. restricting a decimal64 type with a fraction-digits
statement is not allowed.

--Per

>>  typedef percent {
>>type decimal {
>>  fraction-digits 16;
>>  range 0..100;
>>}
>>  }
>>
>>  typedef percent' {
>>type percent { fraction-digits 4; }  <<<<<<<<<<<<<<
>>  }
>>
>>An ideal solution would provide flexibility both on the range and
>>the number of fraction digits but it seems this is impossible since
>>these two properties (range and precision) interact.
>>
>> So it seems we have to do something that is pragmatic and this likely 
>> means fixing the fraction since subtyping the fractional part may not 
>> be allowed by YANG or not be supported by implementations. The 
>> question is then how we pick suitable fractions. I understand you want
>> 4 digits.
>>
>> /js
>>
>>> BR,
>>> Amy
>>> 
>>> Ñöº: Juergen Schoenwaelder [j.schoenwael...@jacobs-university.de]
>>> Ñöô: 2018t116å 22:16
>>> 6öº: Yemin (Amy)
>>> : Qin Wu; Xufeng Liu; balazs.leng...@ericsson.com; NETMOD WG
>>> ;: Re: [netmod] for a future rfc6991bis
>>>
>>> Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%, 
>>> which is likely not generally useful. In fact, even 150% can be in 
>>> some contexts a perfectly sensible percentage. So we may need to 
>>> provide some flexibility here, i.e., having a base time where the 
>>> range can be refined and refined types with an upper limit set to 
>>> 100% for use in situations where this limit is sensible.
>>>
>>> The more difficult aspect seems to be precision, I am not sure YANG 
>>> allows subtyping the fractional part. RFC 7950 seems to be silent 
>>> about this and in the general case this would not be meaningful. But 
>>> in this particular case, when the number range is limited, it would 
>>> actually be OK to allow this (but then we have to have a limit and we 
>>> can't

Re: [netmod] for a future rfc6991bis

2018-11-07 Thread Qin Wu

-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Per Hedeland
发送时间: 2018年11月7日 15:57
收件人: Juergen Schoenwaelder 
抄送: NETMOD WG 
主题: Re: [netmod] for a future rfc6991bis

On 2018-11-07 09:34, Juergen Schoenwaelder wrote:
> On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:
> 
>> For the range, if the defintion can cover the our range(0..99.), 
>> it will be acceptable.  In your suggestion below, does that mean the 
>> base defintion is without range, while refined types can chosse the 
>> range they like?
> 
> I was thinking loud. Let me detail somewhat more what was going on in 
> my head:
> 
>We could define a percent type without the upper bound being
>whatever the decimal covers but fixing the precision of the
>fractional part. We could then narrow the upper bound via
>subtyping:
> 
>   typedef percent {
> type decimal {
>   fraction-digits 4;
>   range "0..max";
> }
>   }
> 
>   typedef percent' {
> type percent { range 0..100; }
>   }
> 
>If wanted flexibility on the fractional part, we could define
>percent with a fixed range and the largest number of fraction digits
>possible and then we could subtype this to obtain a precision that
>makes sense in the usage contexts (although it is not clear whether
>YANG 1.1 really allows this, if not this may be just due to nobody
>ever thinking about this before):

I believe it is quite clear that this is *not* allowed:

   9.3.3.  Restrictions

  A decimal64 type can be restricted with the "range" statement
  (Section 9.2.4).

--Per

[Qin]: Section 9.2.4 said:
"
If a range restriction is applied to a type that is
   already range-restricted, the new restriction MUST be equally
   limiting or more limiting, i.e., raising the lower bounds, reducing
   the upper bounds, removing explicit values or ranges, or splitting
   ranges into multiple ranges with intermediate gaps.
"
I am not sure the above example really violates the rule described above.

>  typedef percent {
>type decimal {
>  fraction-digits 16;
>  range 0..100;
>}
>  }
> 
>  typedef percent' {
>type percent { fraction-digits 4; }
>  }
> 
>An ideal solution would provide flexibility both on the range and
>the number of fraction digits but it seems this is impossible since
>these two properties (range and precision) interact.
> 
> So it seems we have to do something that is pragmatic and this likely 
> means fixing the fraction since subtyping the fractional part may not 
> be allowed by YANG or not be supported by implementations. The 
> question is then how we pick suitable fractions. I understand you want
> 4 digits.
> 
> /js
> 
>> BR,
>> Amy
>> ________
>> Ñöº: Juergen Schoenwaelder [j.schoenwael...@jacobs-university.de]
>> Ñöô: 2018t116å 22:16
>> 6öº: Yemin (Amy)
>> : Qin Wu; Xufeng Liu; balazs.leng...@ericsson.com; NETMOD WG
>> ;: Re: [netmod] for a future rfc6991bis
>>
>> Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%, 
>> which is likely not generally useful. In fact, even 150% can be in 
>> some contexts a perfectly sensible percentage. So we may need to 
>> provide some flexibility here, i.e., having a base time where the 
>> range can be refined and refined types with an upper limit set to 
>> 100% for use in situations where this limit is sensible.
>>
>> The more difficult aspect seems to be precision, I am not sure YANG 
>> allows subtyping the fractional part. RFC 7950 seems to be silent 
>> about this and in the general case this would not be meaningful. But 
>> in this particular case, when the number range is limited, it would 
>> actually be OK to allow this (but then we have to have a limit and we 
>> can't set the upper limit to max).
>>
>> /js
>>
>> On Tue, Nov 06, 2018 at 02:21:33AM +, Yemin (Amy) wrote:
>>> If the percentage is defined as following, as a author of 
>>> draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
>>> But it's better to include in RFC6991bis, as percentage is a generic and 
>>> widely used item.
>>>
>>> BR,
>>> Amy
>>> 
>>> Ñöº: netmod [netmod-boun...@ietf.org] ãh Qin Wu [bill...@huawei.com]
>>> Ñöô: 2018t116å 9:25
>>> 6öº: Xufeng Liu; balazs.leng...@ericsson.com
>>> : NETMOD WG
>>> ;: Re: [netmod] for a future rfc6991bis
>>>
>>>
>>> Another case would be :

Re: [netmod] for a future rfc6991bis

2018-11-07 Thread Per Hedeland


On 2018-11-07 09:34, Juergen Schoenwaelder wrote:

On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:


For the range, if the defintion can cover the our range(0..99.),
it will be acceptable.  In your suggestion below, does that mean the
base defintion is without range, while refined types can chosse the
range they like?


I was thinking loud. Let me detail somewhat more what was going on in
my head:

   We could define a percent type without the upper bound being
   whatever the decimal covers but fixing the precision of the
   fractional part. We could then narrow the upper bound via
   subtyping:

  typedef percent {
type decimal {
  fraction-digits 4;
  range "0..max";
}
  }

  typedef percent' {
type percent { range 0..100; }
  }

   If wanted flexibility on the fractional part, we could define
   percent with a fixed range and the largest number of fraction digits
   possible and then we could subtype this to obtain a precision that
   makes sense in the usage contexts (although it is not clear whether
   YANG 1.1 really allows this, if not this may be just due to nobody
   ever thinking about this before):


I believe it is quite clear that this is *not* allowed:

  9.3.3.  Restrictions

 A decimal64 type can be restricted with the "range" statement
 (Section 9.2.4).

--Per


 typedef percent {
   type decimal {
 fraction-digits 16;
 range 0..100;
   }
 }

 typedef percent' {
   type percent { fraction-digits 4; }
 }

   An ideal solution would provide flexibility both on the range and
   the number of fraction digits but it seems this is impossible since
   these two properties (range and precision) interact.

So it seems we have to do something that is pragmatic and this likely
means fixing the fraction since subtyping the fractional part may not
be allowed by YANG or not be supported by implementations. The
question is then how we pick suitable fractions. I understand you want
4 digits.

/js


BR,
Amy

Ñöº: Juergen Schoenwaelder [j.schoenwael...@jacobs-university.de]
Ñöô: 2018t116å 22:16
6öº: Yemin (Amy)
: Qin Wu; Xufeng Liu; balazs.leng...@ericsson.com; NETMOD WG
;: Re: [netmod] for a future rfc6991bis

Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
which is likely not generally useful. In fact, even 150% can be in
some contexts a perfectly sensible percentage. So we may need to
provide some flexibility here, i.e., having a base time where the
range can be refined and refined types with an upper limit set to 100%
for use in situations where this limit is sensible.

The more difficult aspect seems to be precision, I am not sure YANG
allows subtyping the fractional part. RFC 7950 seems to be silent
about this and in the general case this would not be meaningful. But
in this particular case, when the number range is limited, it would
actually be OK to allow this (but then we have to have a limit and
we can't set the upper limit to max).

/js

On Tue, Nov 06, 2018 at 02:21:33AM +, Yemin (Amy) wrote:

If the percentage is defined as following, as a author of 
draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
But it's better to include in RFC6991bis, as percentage is a generic and widely 
used item.

BR,
Amy

Ñöº: netmod [netmod-boun...@ietf.org] ãh Qin Wu [bill...@huawei.com]
Ñöô: 2018t116å 9:25
6öº: Xufeng Liu; balazs.leng...@ericsson.com
: NETMOD WG
;: Re: [netmod] for a future rfc6991bis


Another case would be :




typedef percentage {

   type decimal64 {

  fraction-digits 5;

  range "0..100";

  }

description "Percentage.";
}

Which is defined ietf-connectionless-oam.yang module.

-Qin
Ñöº: netmod [mailto:netmod-boun...@ietf.org] ãh Xufeng Liu
Ñöô: 2018t116å 3:49
6öº: balazs.leng...@ericsson.com
: NETMOD WG 
;: Re: [netmod] for a future rfc6991bis

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.";
 }
 description "Availability level of the link";
   }

Thanks,
- Xufeng

On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:

+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 
mailto:ie...@btconnect.com>> wrote:
 Original Message -
From: "Juergen Schoenwaelder" 
mailto:j.schoenwael...@jacobs-university.de>>
To: "Kent

Re: [netmod] for a future rfc6991bis

2018-11-07 Thread Juergen Schoenwaelder

On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:

> For the range, if the defintion can cover the our range(0..99.),
> it will be acceptable.  In your suggestion below, does that mean the
> base defintion is without range, while refined types can chosse the
> range they like?

I was thinking loud. Let me detail somewhat more what was going on in
my head:

  We could define a percent type without the upper bound being
  whatever the decimal covers but fixing the precision of the
  fractional part. We could then narrow the upper bound via
  subtyping:

 typedef percent {
   type decimal {
 fraction-digits 4;
 range "0..max";
   }
 }

 typedef percent' {
   type percent { range 0..100; }
 }

  If wanted flexibility on the fractional part, we could define
  percent with a fixed range and the largest number of fraction digits
  possible and then we could subtype this to obtain a precision that
  makes sense in the usage contexts (although it is not clear whether
  YANG 1.1 really allows this, if not this may be just due to nobody
  ever thinking about this before):

typedef percent {
  type decimal {
fraction-digits 16;
range 0..100;
  }
}

typedef percent' {
  type percent { fraction-digits 4; }
}

  An ideal solution would provide flexibility both on the range and
  the number of fraction digits but it seems this is impossible since
  these two properties (range and precision) interact.

So it seems we have to do something that is pragmatic and this likely
means fixing the fraction since subtyping the fractional part may not
be allowed by YANG or not be supported by implementations. The
question is then how we pick suitable fractions. I understand you want
4 digits.

/js

> BR,
> Amy
> 
> 发件人: Juergen Schoenwaelder [j.schoenwael...@jacobs-university.de]
> 发送时间: 2018年11月6日 22:16
> 收件人: Yemin (Amy)
> 抄送: Qin Wu; Xufeng Liu; balazs.leng...@ericsson.com; NETMOD WG
> 主题: Re: [netmod] for a future rfc6991bis
> 
> Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
> which is likely not generally useful. In fact, even 150% can be in
> some contexts a perfectly sensible percentage. So we may need to
> provide some flexibility here, i.e., having a base time where the
> range can be refined and refined types with an upper limit set to 100%
> for use in situations where this limit is sensible.
> 
> The more difficult aspect seems to be precision, I am not sure YANG
> allows subtyping the fractional part. RFC 7950 seems to be silent
> about this and in the general case this would not be meaningful. But
> in this particular case, when the number range is limited, it would
> actually be OK to allow this (but then we have to have a limit and
> we can't set the upper limit to max).
> 
> /js
> 
> On Tue, Nov 06, 2018 at 02:21:33AM +, Yemin (Amy) wrote:
> > If the percentage is defined as following, as a author of 
> > draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
> > But it's better to include in RFC6991bis, as percentage is a generic and 
> > widely used item.
> >
> > BR,
> > Amy
> > 
> > 发件人: netmod [netmod-boun...@ietf.org] 代表 Qin Wu [bill...@huawei.com]
> > 发送时间: 2018年11月6日 9:25
> > 收件人: Xufeng Liu; balazs.leng...@ericsson.com
> > 抄送: NETMOD WG
> > 主题: Re: [netmod] for a future rfc6991bis
> >
> >
> > Another case would be :
> >
> >
> > “
> >
> > typedef percentage {
> >
> >   type decimal64 {
> >
> >  fraction-digits 5;
> >
> >  range "0..100";
> >
> >  }
> >
> >description "Percentage.";
> >}
> > ”
> > Which is defined ietf-connectionless-oam.yang module.
> >
> > -Qin
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Xufeng Liu
> > 发送时间: 2018年11月6日 3:49
> > 收件人: balazs.leng...@ericsson.com
> > 抄送: NETMOD WG 
> > 主题: Re: [netmod] for a future rfc6991bis
> >
> > 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.";
> > }
> > description "Availability level of the link";
> >   }
> >
> > Thanks,
> > - Xufeng
> >
> > On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
> > mailto:balazs.leng...@ericsson.com>&

Re: [netmod] for a future rfc6991bis

2018-11-06 Thread Yemin (Amy)

Hi Juergen,

What we don't like in current RFC6991 is the type is uint8 which doesn't allow 
fraction. 
For the range, if the defintion can cover the our range(0..99.), it will be 
acceptable. 
In your suggestion below, does that mean the base defintion is without range, 
while refined types can chosse the range they like?

BR,
Amy

发件人: Juergen Schoenwaelder [j.schoenwael...@jacobs-university.de]
发送时间: 2018年11月6日 22:16
收件人: Yemin (Amy)
抄送: Qin Wu; Xufeng Liu; balazs.leng...@ericsson.com; NETMOD WG
主题: Re: [netmod] for a future rfc6991bis

Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
which is likely not generally useful. In fact, even 150% can be in
some contexts a perfectly sensible percentage. So we may need to
provide some flexibility here, i.e., having a base time where the
range can be refined and refined types with an upper limit set to 100%
for use in situations where this limit is sensible.

The more difficult aspect seems to be precision, I am not sure YANG
allows subtyping the fractional part. RFC 7950 seems to be silent
about this and in the general case this would not be meaningful. But
in this particular case, when the number range is limited, it would
actually be OK to allow this (but then we have to have a limit and
we can't set the upper limit to max).

/js

On Tue, Nov 06, 2018 at 02:21:33AM +, Yemin (Amy) wrote:
> If the percentage is defined as following, as a author of 
> draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
> But it's better to include in RFC6991bis, as percentage is a generic and 
> widely used item.
>
> BR,
> Amy
> 
> 发件人: netmod [netmod-boun...@ietf.org] 代表 Qin Wu [bill...@huawei.com]
> 发送时间: 2018年11月6日 9:25
> 收件人: Xufeng Liu; balazs.leng...@ericsson.com
> 抄送: NETMOD WG
> 主题: Re: [netmod] for a future rfc6991bis
>
>
> Another case would be :
>
>
> “
>
> typedef percentage {
>
>   type decimal64 {
>
>  fraction-digits 5;
>
>  range "0..100";
>
>  }
>
>description "Percentage.";
>}
> ”
> Which is defined ietf-connectionless-oam.yang module.
>
> -Qin
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Xufeng Liu
> 发送时间: 2018年11月6日 3:49
> 收件人: balazs.leng...@ericsson.com
> 抄送: NETMOD WG 
> 主题: Re: [netmod] for a future rfc6991bis
>
> 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.";
> }
> description "Availability level of the link";
>   }
>
> Thanks,
> - Xufeng
>
> On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
> mailto:balazs.leng...@ericsson.com>> wrote:
>
> +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 
> mailto:ie...@btconnect.com>> wrote:
>  Original Message -
> From: "Juergen Schoenwaelder" 
> mailto:j.schoenwael...@jacobs-university.de>>
> To: "Kent Watsen" mailto:kwat...@juniper..net>>
> Cc: mailto:netmod@ietf.org>>
> 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 NETC

Re: [netmod] for a future rfc6991bis

2018-11-06 Thread Juergen Schoenwaelder

Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
which is likely not generally useful. In fact, even 150% can be in
some contexts a perfectly sensible percentage. So we may need to
provide some flexibility here, i.e., having a base time where the
range can be refined and refined types with an upper limit set to 100%
for use in situations where this limit is sensible.

The more difficult aspect seems to be precision, I am not sure YANG
allows subtyping the fractional part. RFC 7950 seems to be silent
about this and in the general case this would not be meaningful. But
in this particular case, when the number range is limited, it would
actually be OK to allow this (but then we have to have a limit and
we can't set the upper limit to max).

/js

On Tue, Nov 06, 2018 at 02:21:33AM +, Yemin (Amy) wrote:
> If the percentage is defined as following, as a author of 
> draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
> But it's better to include in RFC6991bis, as percentage is a generic and 
> widely used item.
> 
> BR,
> Amy
> 
> 发件人: netmod [netmod-boun...@ietf.org] 代表 Qin Wu [bill...@huawei.com]
> 发送时间: 2018年11月6日 9:25
> 收件人: Xufeng Liu; balazs.leng...@ericsson.com
> 抄送: NETMOD WG
> 主题: Re: [netmod] for a future rfc6991bis
> 
> 
> Another case would be :
> 
> 
> “
> 
> typedef percentage {
> 
>   type decimal64 {
> 
>  fraction-digits 5;
> 
>  range "0..100";
> 
>  }
> 
>description "Percentage.";
>}
> ”
> Which is defined ietf-connectionless-oam.yang module.
> 
> -Qin
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Xufeng Liu
> 发送时间: 2018年11月6日 3:49
> 收件人: balazs.leng...@ericsson.com
> 抄送: NETMOD WG 
> 主题: Re: [netmod] for a future rfc6991bis
> 
> 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.";
> }
> description "Availability level of the link";
>   }
> 
> Thanks,
> - Xufeng
> 
> On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
> mailto:balazs.leng...@ericsson.com>> wrote:
> 
> +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 
> mailto:ie...@btconnect.com>> wrote:
>  Original Message -
> From: "Juergen Schoenwaelder" 
> mailto:j.schoenwael...@jacobs-university.de>>
> To: "Kent Watsen" mailto:kwat...@juniper..net>>
> Cc: mailto:netmod@ietf.org>>
> 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 20

Re: [netmod] for a future rfc6991bis

2018-11-05 Thread Yemin (Amy)

If the percentage is defined as following, as a author of 
draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
But it's better to include in RFC6991bis, as percentage is a generic and widely 
used item.

BR,
Amy

发件人: netmod [netmod-boun...@ietf.org] 代表 Qin Wu [bill...@huawei.com]
发送时间: 2018年11月6日 9:25
收件人: Xufeng Liu; balazs.leng...@ericsson.com
抄送: NETMOD WG
主题: Re: [netmod] for a future rfc6991bis


Another case would be :


“

typedef percentage {

  type decimal64 {

 fraction-digits 5;

 range "0..100";

 }

   description "Percentage.";
   }
”
Which is defined ietf-connectionless-oam.yang module.

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Xufeng Liu
发送时间: 2018年11月6日 3:49
收件人: balazs.leng...@ericsson.com
抄送: NETMOD WG 
主题: Re: [netmod] for a future rfc6991bis

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.";
}
description "Availability level of the link";
  }

Thanks,
- Xufeng

On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:

+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 
mailto:ie...@btconnect.com>> wrote:
 Original Message -
From: "Juergen Schoenwaelder" 
mailto:j.schoenwael...@jacobs-university.de>>
To: "Kent Watsen" mailto:kwat...@juniper..net>>
Cc: mailto:netmod@ietf.org>>
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 <https://www.jacobs-university.de/>
>
> ___
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod

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


___

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod

--

Balazs Lengyel   Ericsson Hungary Ltd.

Senior Specialist

Mobile: +36-70-330-7909  email: 
balazs.leng...@ericsson.com<mailto:balazs.leng...@ericsson.com>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

2018-11-05 Thread Qin Wu

Another case would be :


“

typedef percentage {

  type decimal64 {

 fraction-digits 5;

 range "0..100";

 }

   description "Percentage.";
   }
”
Which is defined ietf-connectionless-oam.yang module.

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Xufeng Liu
发送时间: 2018年11月6日 3:49
收件人: balazs.leng...@ericsson.com
抄送: NETMOD WG 
主题: Re: [netmod] for a future rfc6991bis

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.";
}
description "Availability level of the link";
  }

Thanks,
- Xufeng

On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:

+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 
mailto:ie...@btconnect.com>> wrote:
 Original Message -
From: "Juergen Schoenwaelder" 
mailto:j.schoenwael...@jacobs-university.de>>
To: "Kent Watsen" mailto:kwat...@juniper..net>>
Cc: mailto:netmod@ietf.org>>
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 <https://www.jacobs-university.de/>
>
> ___
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod

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


___

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod<https://www..ietf.org/mailman/listinfo/netmod>

--

Balazs Lengyel   Ericsson Hungary Ltd.

Senior Specialist

Mobile: +36-70-330-7909  email: 
balazs.leng...@ericsson.com<mailto:balazs.leng...@ericsson.com>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

2018-11-05 Thread Juergen Schoenwaelder

Apparently people have different needs concerning precision...

/js

On Mon, Nov 05, 2018 at 03:48:44PM -0500, Xufeng Liu wrote:
> 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.";
> }
> description "Availability level of the link";
>   }
> 
> Thanks,
> - Xufeng
> 
> On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
> wrote:
> 
> > +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  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 
> > listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Balazs Lengyel   Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> >
> >

> ___
> 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-05 Thread Xufeng Liu

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.";
}
description "Availability level of the link";
  }

Thanks,
- Xufeng

On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
wrote:

> +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  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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
> --
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>
>
___
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

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

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.
> > > > >
> > > > >
> > &

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 <https://www.jacobs-university.de/>


___
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 additio

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

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

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

Re: [netmod] for a future rfc6991bis

2018-11-01 Thread Qin Wu

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 <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/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

2018-11-01 Thread Acee Lindem (acee)

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 latitude, why not use DMS (Degree, Minute, 
Second)? 

I'd be happy to reach consensus on this but we're going to solve it in this 
Email thread. 

Thanks,
Acee

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2018年11月1日 22:18
收件人: Qin Wu ; Juergen Schoenwaelder 
; netmod@ietf.org
    主题: Re: [netmod] for a future rfc6991bis

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"  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 <https://www.jacobs-university.de/>
___
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-01 Thread Qin Wu

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
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2018年11月1日 22:18
收件人: Qin Wu ; Juergen Schoenwaelder 
; netmod@ietf.org
主题: Re: [netmod] for a future rfc6991bis

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"  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 <https://www.jacobs-university.de/>
___
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-01 Thread Acee Lindem (acee)

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"  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 <https://www.jacobs-university.de/>
___
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-01 Thread Juergen Schoenwaelder

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

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

Re: [netmod] for a future rfc6991bis

2018-11-01 Thread Qin Wu

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 <https://www.jacobs-university.de/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

2018-11-01 Thread Balázs Lengyel


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

  
  

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


-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

2018-10-31 Thread Ladislav Lhotka

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

Re: [netmod] for a future rfc6991bis

2018-10-30 Thread Joel Jaeggli



> On Oct 30, 2018, at 03:14, Juergen Schoenwaelder 
>  wrote:
> 
> 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.
>> 
> 
> 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”.

It would be slightly unfortunate I think if we were to define something that 
was obsolete at the time of definition. So yeah the union of all-ascii 
addresses and non-ascii addresses is in fact SMTPUTF8. To my mind that would be 
what you would specify, and that probably requires discussion.
> 
> /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-10-30 Thread Juergen Schoenwaelder

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

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

Re: [netmod] for a future rfc6991bis

2018-10-29 Thread Kent Watsen




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

Kent // contributor


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

Re: [netmod] for a future rfc6991bis

2018-10-29 Thread Juergen Schoenwaelder

On Mon, Oct 29, 2018 at 08:34:56PM +, 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?

/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] for a future rfc6991bis

2018-10-29 Thread Kent Watsen

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

46 matches

Mail list logo