IETF Logo Mail Archive

Re: [Roll] capability handling

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 08 May 2020 18:05 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740223A0F18 for <roll@ietfa.amsl.com>; Fri, 8 May 2020 11:05:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ky8Erxw-dtKu for <roll@ietfa.amsl.com>; Fri, 8 May 2020 11:05:31 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8427B3A0F14 for <roll@ietf.org>; Fri, 8 May 2020 11:05:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 57A1138991 for <roll@ietf.org>; Fri, 8 May 2020 14:03:29 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FAlZQ7MzqiCd for <roll@ietf.org>; Fri, 8 May 2020 14:03:28 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9EFCD3898E for <roll@ietf.org>; Fri, 8 May 2020 14:03:28 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 91D284E7 for <roll@ietf.org>; Fri, 8 May 2020 14:05:29 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <BM1PR01MB40200BA596F107A09BD89DC6A9A20@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
References: <BM1PR01MB402011EE18D8BE1C70A15AE4A9A50@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>, <31727.1588874478@localhost> <BM1PR01MB40200BA596F107A09BD89DC6A9A20@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 08 May 2020 14:05:29 -0400
Message-ID: <25184.1588961129@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/7uYNF36gAVa4QK2fqo3OadorLkE>
Subject: Re: [Roll] capability handling
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2020 18:05:34 -0000

Rahul Jadhav <nyrahul@outlook.com> wrote:
    > There was ​another point we discussed during the interim in context to
    > Capability Indicators: How to arrange the Indicator bits?  a. Using
    > left to right b. Or using right to left (currently in the draft [1])

    > If we use right to left then we can give every bit a number, for e.g.,
    > currently the 'T' bit is 0x1. The length can be set accordingly i.e. if
    > the indicators are less than 8 bits then the length will be one.  This
    > is simpler to handle in implementation as well. Thoughts?

(1) If we number from right to left, can we expand the field to be as many octets
    are we like?  So len=3 is just an example?  Don't transmit zero bytes.

(2) If we number from left to right, then we could number them "bit 0" through
    "bit 7" of byte 0 through 255.

The IANA considerations for this might be a bit weird either way.
I guess there is a maximum number of octets that we can get into the field
anyway, so we declare it to be a field with that many bits and ask IANA to
allocate contiguously.

The effect is the same: we don't transmit bytes which are zeros, it's just
whether we consider those zeros on the left or right.

I think that (2) might easier to code because the offset of each flag will
not move as the structure gets longer, and it doesn't confuse people into
thinking they need 64-bit ints, which then fail on capability #65. (actually #64)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email