Re: [Cellar] VINT_DATA of all ontes

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 07 June 2018 16:58 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E335130F6D for <cellar@ietfa.amsl.com>; Thu, 7 Jun 2018 09:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TU5vr13nDvGC for <cellar@ietfa.amsl.com>; Thu, 7 Jun 2018 09:58:37 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC3C130F5E for <cellar@ietf.org>; Thu, 7 Jun 2018 09:58:36 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E554520090; Thu, 7 Jun 2018 13:12:05 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 5A0153033; Thu, 7 Jun 2018 12:57:59 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5732B3032; Thu, 7 Jun 2018 12:57:59 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Dave Rice <dave@dericed.com>, cellar@ietf.org
In-Reply-To: <E1F0B7AD-52DC-4F05-A016-2D2D64C61E31@dericed.com>
References: <14348.1528336161@localhost> <E1F0B7AD-52DC-4F05-A016-2D2D64C61E31@dericed.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha1"; protocol="application/pgp-signature"
Date: Thu, 07 Jun 2018 12:57:59 -0400
Message-ID: <2581.1528390679@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/DKw_72XWqwyALjeK6kXWuwKxKr8>
Subject: Re: [Cellar] VINT_DATA of all ontes
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2018 16:58:42 -0000

Dave Rice <dave@dericed.com> wrote:
    >> Additionally,
    >> an "Element ID" with binary encoding of "1111 1111" is invalid since
    >> the "VINT_DATA" section is set to all one values, whereas an "Element
    >> ID" with binary encoding of "0100 0000 0111 1111" stores a
    >> semantically equal "VINT_DATA" and is the shortest possible
    >> "VINT" encoding.
    >> 
    >> It seems that there is a prohibition on VINT_DATA that is all ones.
    >> I can't find a place in section 6 that says this.

    > Just before your quote, I see:

    > "The VINT_DATA component of the Element ID MUST NOT be either defined
    > or written as either all zero values or all one values.”

Ah, my eyes missed that.

Could we split this into three paragraphs, and can we add some explanation of
why all zeros and all ones is forbidden?

    >> Is this a restriction on
    >> all VINT_DATA, or just ones used for Element ID?

Would the WG like to simply skip allocation of Element IDs values which
would be all ones in the appropriate encoding?  Clearly, one can go to the
next bigger VINT size and express it, but it seems like skipping that value
is simpler.  I believe that my suggested IANA Considerations text on
this value does that.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [