"Rob Wilton \(rwilton\)" <[email protected]> wrote:
> [As an individual contributor]
>
> > -----Original Message-----
> > From: netmod <[email protected]> On Behalf Of Juergen
> > Schoenwaelder
> > Sent: 22 April 2020 23:09
> > To: Robert Varga <[email protected]>
> > Cc: [email protected]
> > Subject: Re: [netmod] "uint24" in rfc6991-bis?
> >
> > On Wed, Apr 22, 2020 at 11:17:26PM +0200, Robert Varga wrote:
> > > Hello,
> > >
> > > a number of IETF protocols-and-whatnots are operating on unsigned
> > > 24bit (or 3-octet) entities. For example:
> > >
> > > https://tools.ietf.org/html/rfc7471#section-4.1.5
> > > https://tools.ietf.org/html/rfc7471#section-4.4.5
> > > SRGB range start/length in https://tools.ietf.org/html/rfc8669
> >
> > For these use cases, it might be also a good idea to define types that
> > capture the additional semantics. SRGB seems to consist of two 24-bit
> > values - I can't tell whether it makes sense to model this 6-octet
> > value
> > as two 3-octet values in YANG.
> >
> > > I wonder whether it would make sense to provide something like:
> > >
> > > type uint24 {
> > > type uint32;
> > > range 0..16777215;
> > > }
> > >
> > > in ietf-inet-types as a common base type for such definitions.
> >
> > If we add such a definition, it likely should go into ietf-yang-types.
> [RW]
>
> I would find this type somewhat confusing in the sense that it mixing
> the underlying YANG datatype with the range of the value space,
I agree.
> e.g., I don't think of uint8 as
> type uint8 {
> type uint32;
> range 0..255;
> }
>
> because the encoding is allowed to be different. Perhaps having a
> slightly different name would help avoid possible confusion with the
> built in types?
Then the question is if it really is so common so that we need a type
in ietf-yang-types for this.
/martin
>
> Regards,
> Rob
>
>
> >
> > /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 protected]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod