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

Scott Burleigh <Scott.Burleigh@jpl.nasa.gov> Thu, 26 May 2005 15:57 UTC

Received: from nmta3.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.108]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4QFvjV07563; Thu, 26 May 2005 08:57:45 -0700
Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta3.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4QFvdZX009495; Thu, 26 May 2005 08:57:40 -0700
Received: from [137.79.22.227] (dhcp-79-22-227.jpl.nasa.gov [137.79.22.227]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4QFvdS4007650; Thu, 26 May 2005 08:57:39 -0700
Message-ID: <4295F1AF.5020607@jpl.nasa.gov>
Date: Thu, 26 May 2005 08:56:31 -0700
From: Scott Burleigh <Scott.Burleigh@jpl.nasa.gov>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org
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> <20050526002442.GE28634@pisco.cs.berkeley.edu>
In-Reply-To: <20050526002442.GE28634@pisco.cs.berkeley.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: dhcp-79-22-227.jpl.nasa.gov [137.79.22.227]
X-Source-Sender: Scott.Burleigh@jpl.nasa.gov
X-AUTH: Internal IP
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/>

Michael Demmer wrote:

>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?
>
I don't much care one way or another.  Do we really think we're likely 
to need to represent numbers bigger than (2*68) - 1 in SDNVs?  If so, 
what convinces us that we're likely to need 16 bytes but not equally 
likely to need 128 bytes?  Certainly we can use an encoding scheme like 
this, or lots of others (for example, 1 2 4 8 16 32 64 128), but the 
fact that we can doesn't necessarily mean we should.  What's the 
rationale for this particular system?

Scott