|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI - long key valuesJulian, 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
Home Last updated: Wed Sep 19 17:17:16 2001 6603 messages in chronological order |