[dtn-security] Re: [dtn-dev] Re: SDNV-new

Michael Demmer <demmer@cs.berkeley.edu> Thu, 26 May 2005 00:24 UTC

Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4Q0OhV01791; Wed, 25 May 2005 17:24:43 -0700
Received: from demmer by pisco with local (Exim 4.50) id 1Db6B0-0005ls-M9; Wed, 25 May 2005 17:24:42 -0700
Date: Wed, 25 May 2005 17:24:42 -0700
From: Michael Demmer <demmer@cs.berkeley.edu>
To: Scott Burleigh <Scott.Burleigh@jpl.nasa.gov>
Cc: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org
Message-ID: <20050526002442.GE28634@pisco.cs.berkeley.edu>
References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <20050525172205.GD14911@pisco.cs.berkeley.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20050525172205.GD14911@pisco.cs.berkeley.edu>
User-Agent: Mutt/1.4.2i
Subject: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: dtn-security-admin@mailman.dtnrg.org
Errors-To: dtn-security-admin@mailman.dtnrg.org
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: dtn-security@mailman.dtnrg.org
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>

In talking with Kevin a bit about this, I'm gonna propose a slight
modification to my original proposal. 

For the three bits that in my original proposal indicated that there
were 1-8 value bytes to follow, I'd say we should recast their meaning
to be:

0:   1 byte to follow
1:   2 bytes to follow
2:   3 bytes to follow
3:   4 bytes to follow
4:   6 bytes to follow
5:   8 bytes to follow
6:  12 bytes to follow
7:  16 bytes to follow

Basically, we drop the 5 byte and 7 byte encodings in favor of adding
a 12 byte and a 16 byte case. 

We still use the low-order nibble of the discriminator byte as the
high order bits of the value.

Thoughts?

-m