Subject: RE: iSCSI: Decimal encoding - why 64 bits ?

From: "Julian Satran" <[email-masked]>
Date: Tue, 2 Jul 2002 22:23:16 +0300

It was never supposed to be removed. Many values are passed around as 
decimal.
We can't make any progress if we keep hitting the same things 
again-and-again after a decent consensus has been reached.
And none of you has brought an argument that was not heard and dismissed 
before.

Remember we moved from unlimited length decimal to 64 bit to alleviate 
implementer fears.

Julo

Bill Studenmund <[email-masked]>
07/02/2002 10:03 PM
Please respond to Bill Studenmund

        To:     "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
        cc:     "LEMAY,KEVIN (A-Roseville,ex1)" <[email-masked]>, Julian 
Satran/Haifa/IBM@IBMIL, <[email-masked]>
        Subject:        RE: iSCSI: Decimal encoding - why 64 bits ?

On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote:

> Bill,

> The decimal encoding is not just for numbers. It is also allowed for
> binary-values. Both CHAP and SRP exchange items that are identified as
> binary-values. In general these will be longer than 64 bits, but in
> cases where they are 64 bits or less the decimal encoding is currently
> allowed so we would have to support it.

I thought we had a big discussion about this, and we decided that decimal
was only used for numbers, hex for numbers and binary, and base64 only for
binary items. ??

Doh! I just looked in -14, and the text doesn't reflect that
understanding. Hmmm.

> The issue is that currently decimal encoding is allowed for
> binary-values and numbers less than 64 bits. There is little need for
> it over 32 bits. We have two other entirely adequate representations
> for those numbers. Why have something in there that causes extra code
> for no benefit?

All I can say is I thought it was removed. :-|

Take care,

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 2 Jul 2002 14:22:53 -0700 (PDT)

> again-and-again after a decent consensus has been reached.

The question is does the draft reflect the concensus that all the
discussion participants thought they achieved?

At least one other person had the same impression I did about the past
discussion. i.e. we thought we HAD achieved concensus, and yet the draft
does not reflect that discussion.

> And none of you has brought an argument that was not heard and dismissed

When were these arguements dismissed? While I recall a lot of disagreement
on points, I don't recall a sound dismissal on technical grounds.

> Remember we moved from unlimited length decimal to 64 bit to alleviate

Julian, those fears were for something else. Those fears were for how do
you deal with extended-precision math when reading a large number.

These concerns are that decimal encoding of binary strings suffers from
many of the problems that base64 had for numbers - the need to perform
arithmetic to byte-string conversion (i.e. hotns() and htonl() & friends).

Now that the text explicitly states that the string size is in whole
bytes, things aren't as weird as before. But it's still messy. I'll post a
seperate message on this.

Take care,

Bill

---

From: "Julian Satran \(Actcom\)" <[email-masked]>
Date: Fri, 5 Jul 2002 06:45:31 +0300

If you fear about extended precision arithmetic you should carefully look at
what key=values are.
Precluding the use of large numerical values by forbidding their encoding is
not a good way of considering this - we have also base64 for large numbers
(and hex) and if you have to have a use for larger numbers you have to have
the arithmetic to handle it.

As for the second subject - forbidding the use decimals for binary strings -
we never discussed it or agreed on this.

I wonder how natural it will feel for somebody to have and IP address
encoded exclusively in hex, or a TargetPortalGroup appearing as decimal in a
directory and having to be transliterated.

Julo

---

From: Martins Krikis <[email-masked]>
Date: Fri, 5 Jul 2002 06:54:52 -0700 (PDT)

--- "Julian Satran (Actcom)"

> the arithmetic to handle it.

Julian,

If this hadn't come up so late, I would even
challenge you to find anybody besides yourself
who is "for large-numerical-values"---my feeling
from reading this list is that people preferred
to just have "binary values" (of arbitrary length)
instead.

> we never discussed it or agreed on this.

Many people mentioned it and are still doing it.
The rest ignored the issue and keep doing it.
 
> directory and having to be transliterated.

These are very bad examples. TargetPortalGroupTag
is defined as a numerical-value, so decimal is
perfectly fine for it, it is given in decimal in
all examples in the draft and I certainly would
expect to find it in decimal.

As for the IP addresses, I'm not an IPv6 expert,
but I expect it to be given as an ASCII string 
(and not a binary value/item in some encoding), 
just like an IPv4 address.
Speaking about the latter, we are used to seeing
the octets of this address in decimal, not the
address itself. If you insist on encoding the 
address as a whole (i.e., the 32-bit binary value
that it is), well, please tell me, which is
more natural (although, I agree that both are
awkward): 3228845671 or 0xc0744667? You may want
to feed them to a "host" command, and you should
recognize these addresses. Both get resolved on
my home box. Such tricks used to even work in some
browsers.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
            be those of my employer.

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

---

From: Paul Koning <[email-masked]>
Date: Fri, 5 Jul 2002 10:37:40 -0400

> the arithmetic to handle it.

There are no numbers in the draft that come even close to 32 bits (the
biggest is about 24 bits) so any possible future use of 64 bit
integers is entirely speculative.
 
> we never discussed it or agreed on this.

I thought we had, but it doesn't really matter if we discussed it in
the past; we're discussing it now.
 
> directory and having to be transliterated.

What does this have to do with the subject that we're discussing?
Those aren't integers bigger than 32 bits.

The two areas that are being argued about are:

1. Integer-type attributes that require 64 bits rather than 32 bits.
   Such attributes do not currently exist.  We could let the rules say
   that such attributes, if/when they appear in the future, can be 
   encoded in decimal.  That doesn't affect any current
   implementations because there are no such attributes at present.

2. Bitstring attributes, as found in crypto variables.  Those are
   either always, or almost always, much larger than 2^64.  The
   request from a significant number of people is to disallow decimal
   encoding for those attributes even in the very rare case that the
   value encoded is < 2^64.
   I support that change because allowing the decimal encoding there
   adds no value at all and only complicates code to no purpose.

      paul

---

From: Bill Studenmund <[email-masked]>
Date: Mon, 8 Jul 2002 15:38:43 -0700 (PDT)

> directory and having to be transliterated.

Well, we'll find out with IPv6 addresses, as the only representation of
them I've seen is for them to be in hex. :-)

As to TargetPortalGroup, why is it a binary string? Yes, you mentioned in
another note that it has no ordering ("greater" and "lesser" don't make
sense), so it's not a number like say ErrorRecoveryLevel (where ordering
is important).

But is its in-memory representation really important? Does it matter if a
host represents the value from "TargetPortalGroupTag=1" internally as
00 01 (BE 16 bits) or 01 00 (LE 16 bits) or 00 00 00 01 (BE 32 bits) or
01 00 00 00 (LE 32 bits)? I don't think so. As long as the value is
interpreted right (the initiator sends the right ascii representation, and
the target ties an ascii representation to the right device) I really
don't see how the internal representation matters. So thus I don't see why
it's a binary string, as internal representation is the heart of a binary
string. :-)

Take care,

Bill