[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
- [netmod] bit positions Ladislav Lhotka
- Re: [netmod] bit positions Juergen Schoenwaelder
- Re: [netmod] bit positions Ladislav Lhotka
- Re: [netmod] bit positions Juergen Schoenwaelder
- Re: [netmod] bit positions Ladislav Lhotka