Re: Section 4.1 clarifications

[Mark Bakke <mbakke@cisco.com>]

Julian Satran wrote:
> 
> And you where not very successful as many management tools have already their own representation.
> Limiting the maximum decimal integer is the best practical solution now.

Limiting the max decimal integer is a step in the right direction.
So how about 32 bits for our decimal integer limit?  Remember,
iSCSI should be supportable by a fairly simple device; management
tools have a lot more processing power and code space available
to convert decimal and hex numbers; make them to the work if
they wan to represent it in a different way.  Besides, I have
*never* seen a user interface for anything that represents something
larger than 32 bits as decimal; it just doesn't make sense.

--
Mark



> 
> Julo
> 
>   Mark Bakke <mbakke@cisco.com>
>                                         To:        Paul Koning <ni1d@arrl.net>
>   Sent by: mbakke@cisco.com             cc:        Julian Satran/Haifa/IBM@IBMIL,
>                                 michael.krueger@windriver.com, ips@ece.cmu.edu
>   04/25/2002 11:48 PM                   Subject:        Re: Section 4.1 clarifications
>   Please respond to Mark Bakke
> 
> 
> Paul Koning wrote:
> >
> > >>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:
> >
> >  Julian> Michael, The integer representation was discussed a long time
> >  Julian> ago on the list and it was decided that decimal should be
> >  Julian> allowed as it might be copied from some human readable
> >  Julian> tables. I would hate to make this type of changes this late.
> >
> > Was it ever the intent that things like Diffie-Hellman parameters
> > could be expressed in decimal?  That seems like a VERY VERY bad idea;
> > where is someone going to find a function that converts a decimal
> > string to a bignum?
> >
> > Decimal is fine for any parameter that's a "normal size" integer,
> > i.e., a 32 bit or even -- probably -- a 64 bit integer.  But bignums
> > should only ever be expressed in hex or base64.
> 
> I agree.
> 
> We tried to bring this up last summer.  Each key should specify
> one and only one format, whether that's hex, base64, decimal,
> whatever, that it MUST use, and leave it at that.  There is absolutely
> no reason why an implementation should be able to choose to send
> decimal for a key today, and hex tomorrow.  That way, there would
> have been no need to parse "0x" in front of hex strings, etc.
> It would have kept this a lot simpler, and I don't see a good reason
> why anyone would want more flexibility than this.  Also, the
> ability to use either upper or lower case for hex is a bit
> unnecessary, but at least this shouldn't cause too much trouble.
> 
> Anyway, we already have a little section for each key specifying
> what it does, and who can sent it.  It would be little trouble,
> and probably greatly benefit interoperability, to just specify
> for each text key which format its value uses, and stick with
> it.  Why make life any harder for the receiver than it has to
> be?
> 
> >
> >        paul
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054