RE: iSCSI - long key values

["Julian Satran" <Julian_Satran@il.ibm.com>]

Stephen,

We don't want regular values to extend beyond 255 bytes (no good reason to
allow this).
As such we have 2 limits a) the value length limit AND b) the text block
limit.
I am not sure that we have to worry about the text block limit except if we
are forced into shorter blocks by the framing mechanism.  The block
spanning mechanism enables us to avoid the first limit (and even here we
don't have a good mechanism as bookmarks are target driven and we have to
invent another mechanism for initiator driven bookmarks.

It looks like the second solution I've suggested works in both directions
and is "scalable" while the first needs an additional mechanism to scale
beyond a block.

Julo


                                                                                               
                    "Wheat, Stephen                                                            
                    R"                      To:     Julian Satran/Haifa/IBM@IBMIL,             
                    <stephen.r.wheat@        ips@ece.cmu.edu                                   
                    intel.com>              cc:                                                
                                            Subject:     RE: iSCSI - long key values           
                    19-09-01 18:06                                                             
                    Please respond to                                                          
                    "Wheat, Stephen                                                            
                    R"                                                                         
                                                                                               
                                                                                               




Julian,

Maybe I'm missing something, but I think the new "value extension"
discussion is around how to send very long "values" in a list of key=value
pairs.  IF we may have key=value pairs arbitrarily span PDUs, then the
sending of a long value is done simply by sending one text response PDU
after another, some may have nothing but a 4KB "value" component of a
key=value pair.  The concatenation of the individual "value" components is
then done on the Initiator side, through the process of concatenating the
text responses (in order, of course).

So, am I missing something here?

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, September 18, 2001 9:31 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI - long key values


Stephen,

It is still on the "to consider list".

How would that affect the individula value "extension" that we are
considering now?

Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 18-09-2001 17:57:36

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI - long key values



Julian,

Almost a month ago, we had a thread on values spanning PDU boundaries.

See: "Re: Target record not to span PDUs?"

Anyway, that thread discussion ended without conclusion.  I believe Robert
Snively's and my proposal to allow records to span PDUs is still valid;
I'll
let Robert speak for himself.

Furthermore, I believe that the proposal would thus avoid this problem you
are now addressing, with far less complexity.

Please reconsider this proposal.

Stephen


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, September 17, 2001 11:26 PM
To: ips@ece.cmu.edu
Subject: iSCSI - long key values


Dear colleagues,

Ofer brought recently to my attention that some security key values are
likely to exceed our stated limit
of 255 bytes for a value.  A good example may be a certificate (or chained
certificate).

We have to enable those to be in the Login phase.

To handle this we might want to consider the following options (but not
only those):

   enable a "long hexadecimal coding" that should indicate a "long" value
   (e.g. use 0L instead of 0x) and raise the limit for those keys to
   something longer (say 3072 bytes?)
   enable "concatenated" values and indicate them through a "coding scheme"
   as follows:
     the value "0sxx" indicates a name suffix (as in "key = 0s08" means
     that the keys "key00" , "key01" etc) have to be concatenated
     use the "suffixed keys" to "build the value"
   use a named key coding (as in "0Nname" in a value means that you have to
   use later get=value to get a "binary response" containing the whole
   binary object)


I  think that option 2 (limited to a 3 digit prefix?) covers well what we
need and offers some extension space and option 1 is probably good enough
for certificates.

Comments?

Julo