ExpDataSN overload

[Martins Krikis <mkrikis@yahoo.com>]

Dear list members,

I've just noticed that ExpDataSN is used to denote
a lot of different things (all references w.r.t.
to draft 11):

1) the total number of Data-In PDUs that a target
   has sent to complete a SCSI (read-like) command
   (2.5.1.2, 9.4.7, 6.6, E.9.2);

2) next concecutive input DataSN number expected by
   the initiator for the referenced command in
previous
   execution, used in TASK REASSIGN
   (6.1.2, 9.5.4);

3) internal target variable used to track the next
   DataSN Expected from the initator or something
   like that
   (6.2).

Regarding use 1: this is the most widespread, and
there is nothing to object, except perhaps that the
name ExpDataSN doesn't convey the exact meaning---
"TotalDataPDUs" or "NumDataPDUs" or something like
that. Anyway, I can live with this.

Regarding use 2: the name conveys the meaning, but
I don't like the wording of this spot in 6.1.2:
"... for example taking advantage of ExpDataSN in 
the iSCSI command PDU for read commands...". The
problem is that "read commands" don't have ExpDataSN
in the PDU, it's the "Task Management Function
Request"
PDUs that do. Task Management Function Request PDUs
are, of course, "iSCSI command PDUs", but the whole
thing makes it too easy to make the mistake of
remembering (the ill-named) ExpDataSN field in 
SCSI Response PDU, at which point nothing makes sense
anymore, because that's the other meaning of
ExpDataSN.
I would appreciate if somebody could rephrase the
sentence. I'll even volunteer:

"In reassigning connection allegiance for a command,
the targets SHOULD continue the command from its
current state. For example, when reassigning read
commands, the targets SHOULD take advantage of the
ExpDataSN field provided by the Task Management
Function Request PDU (which must be set to zero
if there was no data transfer) and bring the command
to completion by sending (or resending) the status."

Regarding use 3: I don't understand this. The last
two sentences of 6.2 seem to be talking about
Data-Out PDUs, therefore uses 1 and 2 of ExpDataSN
(that are both Data-In PDU related) don't apply
here. I'm concluding that these sentences are 
making some (unwelcome) assumptions about target
implementation details (e.g., ExpDataSN in the role
of a variable used to track the DataSN of the next
Data-Out PDU that a target expects to receive for
this command). If so, I would like such assumptions
dropped and no MUSTs (and MAYs) imposed on a target
implementation. If I'm wrong, somebody please explain
to me what was meant here.

"Bonus" :-) problem:

While we're at 6.1.2, the start of the 3rd paragraph
also got me thinking and browsing the draft for 
quite a while. I don't like the "This is true even
when the CmdSN can be reliably ascertained..."
phrase. The problem is, I don't see how it could not
be reliably determined for rejected PDUs. My thinking
is that the only way to not be able to reliably
determine CmdSN is in the case of header digest
errors.
But in this case, the PDU must be silently dropped,
and not be answered with a Reject PDU. Am I wrong
somewhere? If not, can we change the sentence I
mentioned to something that explains that for rejected
PDUs, the target will necessarily have a good CmdSN,
but still must not use it"? 

Help on these issues will be much appreciated.

  Martins Krikis, Intel Corp.

Disclaimer: These opinions are mine only and
            may not reflect those of my employer.





__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/