Subject: Re: [netmod] for a future rfc6991bis

From: tom petch <[email-masked]>
Date: Mon, 31 Dec 2018 12:29:34 +0000

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" <[email-masked]>
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 <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> on behalf of Acee Lindem
(acee)
> > >  <[email-masked]>
> > >  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"
> > >  <[email-masked] on behalf of
> > >  [email-masked]> wrote:
> > >
> > >  On Tue, Nov 13, 2018 at 01:33:01PM +0000, 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
> > >  [email-masked]
> > >  https://www.ietf.org/mailman/listinfo/netmod
> > >
> > >  _______________________________________________
> > >  netmod mailing list
> > >  [email-masked]
> > >  https://www.ietf.org/mailman/listinfo/netmod
> > >  _______________________________________________
> > >  netmod mailing list
> > >  [email-masked]
> > >  https://www.ietf.org/mailman/listinfo/netmod
> > >
> > >  _______________________________________________
> > >  netmod mailing list
> > >  [email-masked]
> > >  https://www.ietf.org/mailman/listinfo/netmod
> > >
> > >  _______________________________________________
> > >  netmod mailing list
> > >  [email-masked]
> > >  https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Balazs Lengyel                       Ericsson Hungary Ltd.
> > > Senior Specialist
> > > Mobile: +36-70-330-7909              email:
[email-masked]
>
> --
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 31 Dec 2018 13:47:56 +0100

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 31 Dec 2018 13:21:45 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    Tom,

    /js