|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: v15 R2T and DATA-OUTPaul, It would also be a bad idea to add too many words to the protocol. The protocol is clear about field consistency. Julo Paul Koning <ni1d@arrl.net> To: rod.harrison@windriver.com Sent by: cc: ips@ece.cmu.edu owner-ips@ece.cmu Subject: RE: iSCSI: v15 R2T and DATA-OUT .edu 07/25/2002 05:35 PM Excerpt of message (sent 24 July 2002) by Rod Harrison: > > OK, it's been a long day. Let me try this one more time. > > I was write (almost) first time but I meant DATA-OUT instead of > DATA-IN. Here's what I meant to say ... > > There is a potential inconsistency in the description of the use of > the LUN field in DATA-OUT and R2T in the working v15 draft. > > 9.7.3 Target Transfer Tag, for DATA-OUT last paragraph says ... > > "If the Target Transfer Tag is provided, then the LUN field MUST hold > a valid value and be consistent with whatever was specified with the > command;" > > 9.8.5 Target Transfer Tag, for R2T says ... > > "The Target Transfer Tag and LUN are copied in the outgoing data PDUs > and are used by the target only." > > Potentially a target could return a different LUN field in the R2T, > for perhaps some funky LUN mapping or other internal reason expecting > it to be copied to the DATA-OUT as per the R2T text. I think that's a very bad idea and should not be permitted. If someone wants to do LUN mapping, that's fine, so long as it's transparent to the initiator. To map a LUN and then let the mapped number leak out to the initiator is broken. > I think we need to indicate what is expected of the initiator if the > LUN field in the R2T does not match the LUN in the command PDU. Given that the subject was brought up I tend to agree that the spec should say something. I would prefer it to say that this is a protocol error. paul
Home Last updated: Tue Jul 30 10:39:09 2002 11481 messages in chronological order |