RE: iSCSI: Decimal encoding - why 64 bits ?

[Black_David@emc.com]

Replying to a couple of messages on this topic.

--- Use of decimal for binary items

> There was NEVER a discussion about forbidding decimal for binary items.

Ok, that's why it's now under discussion in WG Last Call.

> It would be counterproductive to forbid them as they are so widely
> used in programming.

The request to forbid them seems to have evolved into a request to
more carefully classify binary items into those that can ordinarily
be expected to fit in 64 bits (decimal format ok) and those that will
generally not fit (decimal format not ok, even if a particular value
fits).  This is consistent with our restriction of base-64 to large
binary items.  As Pat Thaler wrote:

> 4.1
> binary-value includes regular-binary-value and large-binary-value.
> regular-binary-value is for strings less than 64 bits and allows decimal
> encoding. (It says less than 64 and decimal encoded binary strings are
> always in bytes so the largest decimal encoded binary would be 56 bits.)
> 
> 10.4 SRP: N,g,s,A,B,M and H(A | M | K) are binary-values
> 10.5 CHAP: C and R are binary-values

The only ones of these that should routinely fit in 64 bits are SRP's
g (usually a small integer, even though it's mathematically a member of
a very large binary field - I think Paul Koning missed the fact that
generators tend to be single-digit numbers) and s (doesn't need to be
a large number to get the job done).  If any of the others happen to
fit in 64 bits, that's a hint that something may be wrong with security
(e.g., CHAP's C and R should be 128 bits - if either has 64 bits of
leading zeroes, something's probably wrong).  On this basis, I'm
inclined to agree with Pat that:

> Normally, the values defined as binary-values for SRP and CHAP would be
> 64 bits or longer anyway, but someone could send short keys and encode
> them in decimal according to the current draft. This should be eliminated.

I would make an exception to allow decimal for SRP's g and possibly SRP's
s for the sort of convenience reason that Julian gave above ("widely
used in programming").

I'd recommend this change to large-binary-value with the exception of
SRP's g and possibly SRP's s as the way forward.

--- 64 vs. 32 bits

> I went back to the mailing list - and there was a clear consensus to keep
> it to 64 bits (my original proposal was unlimited and  I suggested rhen
128
> to alleviate concerns about conversion difficulty for unlimited numbers).

That matches what I recall from mailing list discussion, 32 bits was not
considered at the time.

> The issue was raised without checking the libraries:

[... snip ...]

> I don't know about Windmills - but I assume that most modern development
> environments are supporting 64bit integers.

I suspect the response to this is that not everyone is using a "modern
development environment" ... ;-)

> Are we going to take for granted any assertion made on the list?

Yes and no.  When someone working on an implementation reports that some
aspect of the protocol spec is causing difficulty, we should at least
believe that the person is in fact having some difficulty.  Whether we
should accept arbitrary proposals to remove difficulty is a different
question (iSCSI is not a simple protocol - some things are going to
be difficult/tricky to implement - TANSTAAFL*).

On this particular issue, I don't see support for or the need to reduce
the upper limit on size of numbers that can be encoded in decimal from
64 bits to 32 bits, but the US holiday is starting to get in the way
of list discussion.  What this would mean for implementers is that the
string decoding logic must be able to handle decimal representations of
integers that fit in 64 bits, but an implementation may restrict the
allowed ranges of the values (negotiated for keys) to fit in 32 bits.
This roughly matches what Mark Bakke described:

> For what it's worth, none of the numeric values for iSCSI that
> can be retrieved or set via the MIB require more than 32 bits
> (other than counters, but I doubt we would ever send a counter
> during negotiation :-).  The allowable ranges just didn't need
> more than that.
> 
> Anyway, I haven't seen a need to provide support for 64-bit
> values in our implementation yet, since none of the numeric
> keys can have values that high.

Allowing decimal values to go up to 64 bits in size strikes me
as a reasonable "future-proofing" measure - in 20/20 hindsight, I
would think that the SNMP folks wish they'd put 64 bit support into
SMIv1/SNMPv1 even if there had been little use for it at the time.

So, this change (64 to 32 bits) does not need to be made now, but I
will be watching the mailing list early next week just in case some
people who care about this have already signed off for the US holiday
and have additional input to contribute.

Thanks,
--David

p.s. * TANSTAAFL = There Ain't No Such Thing As A Free Lunch
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------