[netmod] bit positions

Ladislav Lhotka <lhotka@nic.cz> Wed, 19 December 2018 11:58 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8DC130DFD for <netmod@ietfa.amsl.com>; Wed, 19 Dec 2018 03:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-4odM-ewYA1 for <netmod@ietfa.amsl.com>; Wed, 19 Dec 2018 03:58:51 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFCD128BCC for <netmod@ietf.org>; Wed, 19 Dec 2018 03:58:51 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 5F14060527 for <netmod@ietf.org>; Wed, 19 Dec 2018 12:58:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1545220729; bh=ahEtZf683MkFbD0kI3qYKk9lShx2zcTReHkoai4Rirk=; h=From:To:Date; b=CKdr7JU78Hasiz3EDiVvjDAZnPHwgqhfxNO/Pnvr0cKif3JfNtwfxHgZlKF7LAhM4 ZR0EbRM+tQD5jd+YKA2GAebACVpn4KUQvGphJgwDbQHJJk60iNM139szA3s8CHKu+a lIKmWzf983gVr56M/E8IvcN6fpxhtOeamGiVXBWk=
Message-ID: <0e6b0f62bbea33615a77d909dfde7098372f889b.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: NETMOD WG <netmod@ietf.org>
Date: Wed, 19 Dec 2018 12:58:48 +0100
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/rLKUseStqatmDVzjlMZFEfxN2w0>
Subject: [netmod] bit positions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 11:58:54 -0000

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