RE: Target Behavior Clarifications (with corrections)

 

________________________________

From: William Studenmund [mailto:[email protected]] 
Sent: Tuesday, April 18, 2006 2:00 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [Ips] Target Behavior Clarifications (with corrections)


 <snip> 

	2) What should the target behavior be if the initiator sends it
more data than MaxBurstLength?

	3) What should the target behavior be if the initiator sends
more data than FirstBurstLength?

	<JC> I have two options here:

	

	a)    As per the spec: The target reports the "Incorrect amount
of data" condition if during data output the total data length to output
is greater than FirstBurstLength and the initiator sent unsolicited
non-immediate data but the total amount of unsolicited data is different
than FirstBurstLength. The target reports the same error when the amount
of data sent as a reply to an R2T does not match the amount requested.
(0B/0C/0D - Write Error, Incorrect Amount of Data). This should work.

	

	The only issue here is that the definition of the sense code
does not match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR
- NOT ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI says.


I'd say go with what the RFC says. 
<PAT> When we wrote that, IMO, we were mainly addressing the case where
the initiator didn't send enough data because when the command starts we
need to know how much unsolicited data there will be so we can construct
the first R2T. There really is no reason that the initiator should be
sending more than was requested. I have no problem with deciding to do
b) instead of a).


	

	

	b)    Treat this as a really bad error and assume that I have an
initiator that does not play well and drop the session and kill the
command.

	

	

	I am leaning towards (b). Help!!!

I think (a) is enough. Actually, I think it's not (a) or (b), but (a) or
(a) and (b); I think you really need to do the processing in (a). Even
if you slam the session down, there are internal processing consequences
of (a). :-)

Take care,

Bill

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips