SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: Section 4.1 clarifications



    >>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:
    
     Julian> And you where not very successful as many management tools
     Julian> have already their own representation.  Limiting the maximum
     Julian> decimal integer is the best practical solution now.
    
    Management tools are completely irrevent to this issue.  We're talking
    about the encoding of bignums in the iSCSI protocol.  How, or whether,
    those things are encoded in management protocols is a completely
    separate discussion.
    
    (Then again, if you look in MIBs you will find these things encoded as
    octet strings, i.e., binary strings -- not as integers.)
    
     Julian> Julo
    
    
    
    
     Julian> Mark Bakke <mbakke@cisco.com> Sent by: mbakke@cisco.com
     Julian> 04/25/2002 11:48 PM Please respond to Mark Bakke
    
     
     Julian> To: Paul Koning <ni1d@arrl.net> cc: Julian
     Julian> Satran/Haifa/IBM@IBMIL, michael.krueger@windriver.com,
     Julian> ips@ece.cmu.edu Subject: Re: Section 4.1 clarifications
    
     
    
     Julian> 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.
    
     Julian> I agree.
    
     Julian> We tried to bring this up last summer.  Each key should
     Julian> specify one and only one format, whether that's hex, base64,
     Julian> decimal, whatever, that it MUST use, and leave it at that.
     Julian> There is absolutely no reason why an implementation should be
     Julian> able to choose to send decimal for a key today, and hex
     Julian> tomorrow.  That way, there would have been no need to parse
     Julian> "0x" in front of hex strings, etc.  It would have kept this a
     Julian> lot simpler, and I don't see a good reason why anyone would
     Julian> want more flexibility than this.  Also, the ability to use
     Julian> either upper or lower case for hex is a bit unnecessary, but
     Julian> at least this shouldn't cause too much trouble.
    
     Julian> Anyway, we already have a little section for each key
     Julian> specifying what it does, and who can sent it.  It would be
     Julian> little trouble, and probably greatly benefit
     Julian> interoperability, to just specify for each text key which
     Julian> format its value uses, and stick with it.  Why make life any
     Julian> harder for the receiver than it has to be?
    
     >>  paul
    
     Julian> -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054
    
    
    
     Julian> <br><font size=2 face="sans-serif">And you where not very
     Julian> successful as many management tools have already their own
     Julian> representation.</font> <br><font size=2
     Julian> face="sans-serif">Limiting the maximum decimal integer is the
     Julian> best practical solution now.</font> <br> <br><font size=2
     Julian> face="sans-serif">Julo</font> <br> <br> <br> <table
     Julian> width=100%> <tr valign=top> <td> <td><font size=1
     Julian> face="sans-serif"><b>Mark Bakke
     Julian> &lt;mbakke@cisco.com&gt;</b></font> <br><font size=1
     Julian> face="sans-serif">Sent by: mbakke@cisco.com</font> <p><font
     Julian> size=1 face="sans-serif">04/25/2002 11:48 PM</font> <br><font
     Julian> size=1 face="sans-serif">Please respond to Mark Bakke</font>
     Julian> <br> <td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp;
     Julian> &nbsp; </font> <br><font size=1 face="sans-serif">&nbsp;
     Julian> &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Paul
     Julian> Koning &lt;ni1d@arrl.net&gt;</font> <br><font size=1
     Julian> face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp;
     Julian> &nbsp; &nbsp; &nbsp;Julian Satran/Haifa/IBM@IBMIL,
     Julian> michael.krueger@windriver.com, ips@ece.cmu.edu</font>
     Julian> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp;
     Julian> &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: Section 4.1
     Julian> clarifications</font> <br> <br><font size=1
     Julian> face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table> <br>
     Julian> <br><font size=2 face="Courier New">Paul Koning wrote:<br>
     Julian> &gt; <br> &gt; &gt;&gt;&gt;&gt;&gt; &quot;Julian&quot; ==
     Julian> Julian Satran &lt;Julian_Satran@il.ibm.com&gt; writes:<br>
     Julian> &gt; <br> &gt; &nbsp;Julian&gt; Michael, The integer
     Julian> representation was discussed a long time<br> &gt;
     Julian> &nbsp;Julian&gt; ago on the list and it was decided that
     Julian> decimal should be<br> &gt; &nbsp;Julian&gt; allowed as it
     Julian> might be copied from some human readable<br> &gt;
     Julian> &nbsp;Julian&gt; tables. I would hate to make this type of
     Julian> changes this late.<br> &gt; <br> &gt; Was it ever the intent
     Julian> that things like Diffie-Hellman parameters<br> &gt; could be
     Julian> expressed in decimal? &nbsp;That seems like a VERY VERY bad
     Julian> idea;<br> &gt; where is someone going to find a function that
     Julian> converts a decimal<br> &gt; string to a bignum?<br> &gt; <br>
     Julian> &gt; Decimal is fine for any parameter that's a &quot;normal
     Julian> size&quot; integer,<br> &gt; i.e., a 32 bit or even --
     Julian> probably -- a 64 bit integer. &nbsp;But bignums<br> &gt;
     Julian> should only ever be expressed in hex or base64.<br> <br> I
     Julian> agree.<br> <br> We tried to bring this up last
     Julian> summer. &nbsp;Each key should specify<br> one and only one
     Julian> format, whether that's hex, base64, decimal,<br> whatever,
     Julian> that it MUST use, and leave it at that. &nbsp;There is
     Julian> absolutely<br> no reason why an implementation should be able
     Julian> to choose to send<br> decimal for a key today, and hex
     Julian> tomorrow. &nbsp;That way, there would<br> have been no need
     Julian> to parse &quot;0x&quot; in front of hex strings, etc.<br> It
     Julian> would have kept this a lot simpler, and I don't see a good
     Julian> reason<br> why anyone would want more flexibility than
     Julian> this. &nbsp;Also, the<br> ability to use either upper or
     Julian> lower case for hex is a bit<br> unnecessary, but at least
     Julian> this shouldn't cause too much trouble.<br> <br> Anyway, we
     Julian> already have a little section for each key specifying<br>
     Julian> what it does, and who can sent it. &nbsp;It would be little
     Julian> trouble,<br> and probably greatly benefit interoperability,
     Julian> to just specify<br> for each text key which format its value
     Julian> uses, and stick with<br> it. &nbsp;Why make life any harder
     Julian> for the receiver than it has to<br> be?<br> <br> &gt; <br>
     Julian> &gt; &nbsp; &nbsp; &nbsp; &nbsp;paul<br> <br> -- <br> Mark
     Julian> A. Bakke<br> Cisco Systems<br> mbakke@cisco.com<br>
     Julian> 763.398.1054<br> </font> <br>
     Julian> <br>
    
    


Home

Last updated: Fri Apr 26 12:18:21 2002
9810 messages in chronological order