Subject: iSCSI: Decimal encoding - why 64 bits ?

From: "LEMAY,KEVIN (A-Roseville,ex1)" <[email-masked]>
Date: Mon, 1 Jul 2002 15:01:23 -0600

Julian,

Why does decimal encoding support 64 bit values instead of only 32 bits?

For implementations running on 32bit machines, supporting 64 bit decimal encoding will not be fun. Sure, it can be done in software, but is it really needed?

All of the operational parameters fit in 32 bits. The only possible use for 64 bits is in authentication or vendor specific keys. Hex and base64 encoding make more sense for these cases for the long authentication keys and hex and base64 encoders/decoders must be provided by a compliant implementation anyway.

Could we restrict the decimal encoding to 32 bits and make binary values use only hex and base 64?

Thanks,

Kevin

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 2 Jul 2002 08:30:36 +0300

There was a long debate and 64 bit was deemed a decent compromise.
As for 32bit machines - you should have no difficulty in doing that on a 
32bit machine (or even a 16 bit machine).

Julo

"LEMAY,KEVIN (A-Roseville,ex1)" <[email-masked]>
Sent by: [email-masked]
07/02/2002 12:01 AM
Please respond to "LEMAY,KEVIN (A-Roseville,ex1)"

        To:     "'Satran, Julian'" <[email-masked]>, [email-masked]
        cc: 
        Subject:        iSCSI: Decimal encoding - why 64 bits ?

Julian,

For implementations running on 32bit machines, supporting 64 bit decimal 
encoding will not be fun. Sure, it can be done in software, but is it 
really needed?

All of the operational parameters fit in 32 bits. The only possible use 
for 64 bits is in authentication or vendor specific keys. Hex and base64 
encoding make more sense for these cases for the long authentication keys 
and hex and base64 encoders/decoders must be provided by a compliant 
implementation anyway.

Could we restrict the decimal encoding to 32 bits and make binary values 
use only hex and base 64?

Thanks,

Kevin

---

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

There was NO such consensus.  Julo

Bill Studenmund <[email-masked]>
07/02/2002 10:18 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,
>
> I also thought that the result of the reflector discussion was
> agreement that decimal would only be used for numbers and not be used
> for strings that are sometimes longer than the 64 bit limit like CHAP
> and SRP strings. That seems to be partially implemented in that the
> Kerbos and SPKM sections call for large-binary-values, but it was done
> incompletely.

I looked at the list archive, and
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10319.html
is a comment by David indicating he saw concensus for not using base64 for
numbers.

I didn't find the thread part where I thought we agreed that we would
use decimal only for numbers (and not for small binary strings).

??

Take care,

Bill

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 3 Jul 2002 08:23:30 +0300

Paul argued for base64 not being allowed for numbers and we felt badly
about it because numbers might be needed in some cryptography context
(i.e., some binary item plus ordering). That is why base64 stayed in for
large numbers.
There was NEVER a discussion about forbidding decimal for binary items.  It
would be counterproductive to forbid them as they are so widely used in
programming.

Julo

                      Bill Studenmund                                                                                                       
                      <wrstuden@wasabis        To:       <[email-masked]>                                                              
                      ystems.com>              cc:       Julian Satran/Haifa/IBM@IBMIL, <[email-masked]>                                   
                      Sent by:                 Subject:  RE: iSCSI: Decimal encoding - why 64 bits ?                                        
                      [email-masked]                                                                                                     
                      .edu                                                                                                                  

                      07/03/2002 12:01                                                                                                      
                      AM                                                                                                                    
                      Please respond to                                                                                                     
                      Bill Studenmund                                                                                                       

On Tue, 2 Jul 2002 [email-masked] wrote:

> Easy does it.  First of all - if someone will go find the mail
> thread that discussed this (I also recall a discussion of
> numbers vs. binary items) I'll take a look at it and make a
> WG chair determination of what was or was not concluded.

Ok, I found some of the confusion.

Here's one of Paul's notes at the end of the thread I was remembering:

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10302.html

In it he says that he'd like base64 ot be used only for binary strings
(not numbers). He also goes on to say, "For all other integer parameters
-- which are 64 bit or smaller integers -- permit only hex and decimal.'

In http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10303.html, I agreed
with both points above.

In http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10304.html, Shawn
agrees with both myself and Paul, and talks about base64.

In http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10319.html, you (David)
indicated you saw concensus for the base64 part of Paul's comments.

My concusion was that I though we were all agreeing with both parts. I
think we definitely got base64, but not so sure about
no-decimal-binary-strings.

> Kevin's comment that decimal ought to be limited to 32 bits
> is still valid at this point - a reference to prior discussions
> without specifics isn't enough to dismiss it.  My rough
> recollection of the discussion partially matches Julian's -
> we reduced the required size to 64 bits from unlimited on
> the assumption that platforms could cope with this ... and
> now Kevin has raised the issue that two platforms he
> considers important don't cope well with 64 bit arithmetic.
> I don't recall discussion of whether to limit to 32 bits vs.
> 64 bits.
>
> For now, this issue is open.

I think this issue is a seperate one. I am fine with 64 bits (as I don't
see us needing more than 32 with the present draft) or 32 bits.

Take care,

Bill

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 3 Jul 2002 08:16:32 +0300

David,

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).

The issue was raised without checking the libraries:

In Gnu 64bit integers are fully supported
In Windows - here is the quote from MSDN:

     long-suffix unsigned-suffix(subscript: opt)                            
                                                                            
     unsigned-suffix : one of                                               
                                                                            
     u U                                                                    
                                                                            
     long-suffix : one of                                                   
                                                                            
     l L                                                                    
                                                                            
     64-bit integer-suffix :                                                
                                                                            
     i64                                                                    
                                                                            
     To specify integer constants using octal or hexadecimal notation,      
     use a prefix that denotes the base. To specify an integer constant     
     of a given integral type, use a suffix that denotes the type.          
                                                                            
     To specify a decimal constant, begin the specification with a          
     nonzero digit. For example:                                            

     int i = 157;   // Decimal constant                                     
     int j = 0198;  // Not a decimal number; erroneous octal constant       
     int k = 0365;  // Leading zero specifies octal constant, not decimal   

     To specify an octal constant, begin the specification with 0,          
     followed by a sequence of digits in the range 0 through 7. The         
     digits 8 and 9 are errors in specifying an octal constant. For         
     example:                                                               

     int i = 0377;   // Octal constant                                      
     int j = 0397;   // Error: 9 is not an octal digit                      

     To specify a hexadecimal constant, begin the specification with 0x     
     or 0X (the case of the "x" does not matter), followed by a sequence    
     of digits in the range 0 through 9 and a (or A) through f (or F).      
     Hexadecimal digits a (or A) through f (or F) represent values in the   
     range 10 through 15. For example:                                      

     int i = 0x3fff;   // Hexadecimal constant                              
     int j = 0X3FFF;   // Equal to i                                        

     To specify an unsigned type, use either the u or U suffix. To          
     specify a long type, use either the l or L suffix. For example:        

     unsigned uVal = 328u;             // Unsigned value                    
     long lVal = 0x7FFFFFL;            // Long value specified              
                                       //  as hex constant                  
     unsigned long ulVal = 0776745ul;  // Unsigned long value               

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

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

Julo

                      [email-masked]                                                                                                     
                      om                       To:       Julian Satran/Haifa/IBM@IBMIL, [email-masked]                                     
                                               cc:                                                                                          
                      07/02/2002 10:36         Subject:  RE: iSCSI: Decimal encoding - why 64 bits ?                                        
                      PM                                                                                                                    
                      Please respond to                                                                                                     
                      Black_David                                                                                                           

Thanks,
--David
 -----Original Message-----
 From: Julian Satran [mailto:[email-masked]]
 Sent: Tuesday, July 02, 2002 3:23 PM
 To: [email-masked]
 Subject: RE: iSCSI: Decimal encoding - why 64 bits ?

 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                                                         
   <wrstuden@wasabisystem         To:        "THALER,PAT                   
   s.com>                 (A-Roseville,ex1)" <[email-masked]>      
                                  cc:        "LEMAY,KEVIN                  
                          (A-Roseville,ex1)" <[email-masked]>,    
   07/02/2002 10:03 PM    Julian Satran/Haifa/IBM@IBMIL, <[email-masked]> 
   Please respond to Bill                                                  
   Studenmund                     Subject:        RE: iSCSI: Decimal       
                          encoding - why 64 bits ?                         

 > 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: "John Hufferd" <[email-masked]>
Date: Wed, 3 Jul 2002 22:09:10 -0700

I agree on the future proofing via support for allowing decimal values to
go up to 64 bits.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

[email-masked]@ece.cmu.edu on 07/03/2002 07:06:54 AM

To:    Julian Satran/Haifa/IBM@IBMIL
cc:    [email-masked]
Subject:    RE: iSCSI: Decimal encoding - why 64 bits ?

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

> 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 ...]

> 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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Robert Snively <[email-masked]>
Date: Thu, 4 Jul 2002 09:31:02 -0700

I would agree with Martins' statement:

> I'd like to disagree about the programming part,
> but more importantly, why don't we reinstate 
> the original request to forbid using decimal for
> binary items? It is not a very useful way
> of representing even short binary items because
> there is no way to express the number of leading
> 0-bytes, for example. In case there is a vote on
> this, I'm against using decimal for binary items.
> 

and cast my vote with his.

---

From: [email-masked]
Date: Sat, 6 Jul 2002 20:23:53 -0600

Elizabeth,

None of the examples given use the binary-value value type defined in 4.1. To iSCSI they are all text-values. The issue a number of us have is with binary value (where iSCSI has to convert the value to binary). The only place binary-value is used is in the SRP and CHAP keys. There are at least three ways to address this (in order of my preference, highest first):

1. Change the binary value definition to the current definition for large-binary-value, delete large-binary-value and regular-binary-value from the text formats and change occurrences of large-binary-value to binary-value.

2. Change the upper limit on regular-binary-value to 32 bits.

3. Change SRP and CHAP keys to use large-binary-value.

Regards,
Pat

-----Original Message-----
From: Elizabeth G. Rodriguez [mailto:[email-masked]]
Sent: Saturday, July 06, 2002 8:31 AM
To: 'Julian Satran (Actcom)'; 'Robert Snively'; 'Martins Krikis';
[email-masked]
Cc: [email-masked]

Given these examples, I believe that restricting decimal encoded binary
strings is not an option.

Elizabeth Rodriguez

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Julian Satran (Actcom)
Sent: Saturday, July 06, 2002 1:25 AM
To: Robert Snively; 'Martins Krikis'; [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI: Decimal encoding - why 64 bits ?

You may want to add to the list port-numbers, domain specific name
formats
(yes some domains mainly phone systems use decimal encodings).

A search for decimal encoded binary strings in the RFC domain gave well
over
one-hundred results.

Julo
----- Original Message -----
From: "Robert Snively" <[email-masked]>
To: "'Martins Krikis'" <[email-masked]>; "Julian Satran (Actcom)"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, July 06, 2002 2:37 AM
Subject: RE: iSCSI: Decimal encoding - why 64 bits ?

> The most common example would probably be the
> IP address, which is a binary value.
> It is often presented
> as four separate decimal numbers for no reason
> I can think of, except perhaps a feeling that
> hexadecimal numbers were somehow less user
> friendly for inexperienced users.
>
> See RFC 0790 and RFC 0791.
>
> Bob
>
> > From: Martins Krikis [mailto:[email-masked]]
> > Sent: Friday, July 05, 2002 7:42 AM
> > To: Julian Satran (Actcom); [email-masked]
> > Cc: [email-masked]
> > Subject: Re: iSCSI: Decimal encoding - why 64 bits ?
> >
> >
> >
> > --- "Julian Satran (Actcom)"
> > <[email-masked]> wrote:
> > > Martins - you have a very good point - and we
> > > considered briefly to forbid
> > > decimal from the outset but many of the team felt
> > > that this  would be a bad
> > > idea as values get copied from a context to another.
> > > And the we looked at
> > > coding for other RFCs and we found decimal
> > > everywhere - addresses,
> > > identifiers, ports etc., and thought it would be a
> > > bad idea to forbid them
> > > in iSCSI
> >
> > Julian,
> >
> > I cannot find a single post on this mailing list
> > saying that forbidding decimal encoding for binary
> > items would be a bad idea. I did find several (and
> > quoted 4) that actually recommended dropping decimal
> > encoding for binary items. Lately there have been
> > many more such posts. All those other RFCs, I
> > suspect, are actually dealing with numbers. I have
> > no objections to using decimal encoding for numbers
> > (that is things, that normally fit in your
> > machine's registers and are treated as numerical,
> > not as bit-strings). You have yet to provide an
> > example of something that is clearly a binary
> > string (and not used as a number) and is being
> > commonly encoded in decimal. If you find such a
> > thing, can you tell us what's the scheme for telling
> > how many null-bytes this binary string starts with?
> >
> > 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: [email-masked]
Date: Sat, 6 Jul 2002 20:22:56 -0600

Elizabeth,

Regards,
Pat

-----Original Message-----
From: Elizabeth G. Rodriguez [mailto:[email-masked]]
Sent: Saturday, July 06, 2002 8:31 AM
To: 'Julian Satran (Actcom)'; 'Robert Snively'; 'Martins Krikis';
[email-masked]
Cc: [email-masked]

Elizabeth Rodriguez

-----Original Message-----

Julo

---

From: "Julian Satran" <[email-masked]>
Date: Sun, 7 Jul 2002 07:49:15 +0300

That is not completely correct. Port numbers are 16 bit binary strings. 
TPGT are 16 bit strings.
Over 100 FCs use decimal encoding for binary fields.
I addition once you have the decimal-to-binary conversion it makes to 
sense to forbid it.
Elizabeth is correct we should not do what Pat suggests.

Julo

[email-masked]
Sent by: [email-masked]
07/07/2002 05:22 AM
Please respond to pat_thaler

        To: 
        cc:     [email-masked]

Elizabeth,

None of the examples given use the binary-value value type defined in 4.1. 
To iSCSI they are all text-values. The issue a number of us have is with 
binary value (where iSCSI has to convert the value to binary). The only 
place binary-value is used is in the SRP and CHAP keys. There are at least 
three ways to address this (in order of my preference, highest first):

1. Change the binary value definition to the current definition for 
large-binary-value, delete large-binary-value and regular-binary-value 
from the text formats and change occurrences of large-binary-value to 
binary-value.

Regards,
Pat

-----Original Message-----
From: Elizabeth G. Rodriguez [mailto:[email-masked]]
Sent: Saturday, July 06, 2002 8:31 AM
To: 'Julian Satran (Actcom)'; 'Robert Snively'; 'Martins Krikis';
[email-masked]
Cc: [email-masked]

Elizabeth Rodriguez

-----Original Message-----

Julo

---

From: "Julian Satran" <[email-masked]>
Date: Sun, 7 Jul 2002 17:06:24 +0300

Paul,

there are two subjects that we are discussing:

1-size of numbers 64bit vs 32 bit
2-decimal encoding for bit strings

The 2 subjects are somewhat orthogonal.

Elizabeth was referring to the second subject.

julo

Paul Koning <[email-masked]>
Sent by: [email-masked]
07/07/2002 04:11 PM
Please respond to Paul Koning

        To:     [email-masked]
        cc:     [email-masked]
        Subject:        RE: iSCSI: Decimal encoding - why 64 bits ?

> strings is not an option.

Why not?  I don't see that phone numbers have any relevance to the
discussion.  And port numbers (just like IP addresses) are not 64 bit
values, which is what we were talking about.

                     paul

---

From: Robert Snively <[email-masked]>
Date: Wed, 10 Jul 2002 17:56:59 -0700

The thing that keeps me wondering is:

	given a nice well-behaved binary number,
	represented in hex as FF FF FF FF,
	it sure is a pain to represent it as:
	4 294 967 295

This simply does not make sense to me.  Anything
over 8 bits is suspect as a decimal encoded binary
number, and frankly I don't like such numbers over
3 bits.

Bob