Re: [netmod] for a future rfc6991bis

[Juergen Schoenwaelder <[e-mail]>]

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 +0000, 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" <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> on behalf of Acee Lindem
> (acee)
> > > >  <[e-mail]>
> > > >  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"
> > > >  <[e-mail] on behalf of
> > > >  [e-mail]> 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: [phone] Campus Ring 1 | 28759 Bremen | Germany
> > > >  Fax: [phone] <https://www.jacobs-university.de/>
> > > >
> > > >  _______________________________________________
> > > >  netmod mailing list
> > > >  [e-mail]
> > > >  https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > >  _______________________________________________
> > > >  netmod mailing list
> > > >  [e-mail]
> > > >  https://www.ietf.org/mailman/listinfo/netmod
> > > >  _______________________________________________
> > > >  netmod mailing list
> > > >  [e-mail]
> > > >  https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > >  _______________________________________________
> > > >  netmod mailing list
> > > >  [e-mail]
> > > >  https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > >  _______________________________________________
> > > >  netmod mailing list
> > > >  [e-mail]
> > > >  https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > > --
> > > > Balazs Lengyel                       Ericsson Hungary Ltd.
> > > > Senior Specialist
> > > > Mobile: [phone]              email:
> [e-mail]
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>