Re: [netmod] bit positions

Lada,

RFC 7950 says:

   The "position" statement, which is optional, takes as an argument a
   non-negative integer value that specifies the bit's position within a
   hypothetical bit field.  The position value MUST be in the range 0 to
   4294967295, and it MUST be unique within the bits type.

Neither the XML nor the JSON encoding rulse uses the position
property.  I believe the interpretation of the position field is going
to be protocol specific. DNS may do things in its own way, a CBOR
encoding of bits may do a different thing.

/js

On Wed, Dec 19, 2018 at 12:58:48PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> I ran into a problem when trying to translate IANA registry "DNSKEY Flags" [1]
> into a YANG "bits" type. Each bit is the registry has an assigned number (0-15), 
> so it seems natural to specify this number as the position of each bit in YANG.
> 
> However, it turns out that each bit contributes to the numeric value of the
> entire bit field with a value of 2^(15-n) where n is the bit number. For
> example, if bits ZONE (number 7) and SEP (15) are set, then the value of the
> flags field, which also appears in the DNSKEY resource record, is
> 
>   257 = 2^8 + 2^0
> 
> My question is: Although it is not specified in RFC 7950, was the intention that
> bit of position n contributes with 2^n?
> 
> Thanks, Lada
> 
> [1] https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml
> 
> -- 
> 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/>