RE: iSCSI - long key values

[Robert Snively <rsnively@Brocade.COM>]

I agree with Stephen.

> -----Original Message-----
> From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com]
> Sent: Tuesday, September 18, 2001 7:58 AM
> To: 'Julian Satran'; ips@ece.cmu.edu
> 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
> 
>