|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: v15 R2T and DATA-OUT
Paul,
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 |