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