Subject: RE: [Ips] iSCSI: clarification? data-in PDU->command status bit

From: "brown, david1 (eng)" <[email-masked]>
Date: Wed, 31 Mar 2004 17:28:23 -0500

The language in the iSCSI spec is clear.  The last paragraph of section 3.2
says that there is no difference between a status and a response.  The last
paragraph of 3.5.1.5 says that you don't send a response when the data-in
PDU contains a status.  

Besides, if the developer thought for even a moment about why something
called StatSN was counting something called a Response PDU, he or she would
realize that sending a separate response would mangle the StatSN count.  If
the developer thought about the logic behind phase collapse, he or she might
realize that the status/response is bundled in with the data PDU in order to
avoid the need to send it separately.

Even if we assume the developer made the mistake despite reading the specs
carefully, that doesn't mean the specs are at fault.  It looks like the
developer ran through at least two red lights and two yellow lights; that
doesn't mean a fifth light would help.

Besides, such an amendment to the spec at this stage would set a bad
precedent.  Should we alter the spec each time some device in beta-test
violates the spec, as long as the developer says it's just a
misunderstanding?

If you could find one other person on this mailing list who honestly
misunderstood the implications of sending status with a data PDU, it would
strengthen the argument considerably.

DJ Brown

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of William
Studenmund
Sent: Wednesday, March 31, 2004 5:00 PM
To: Julian Satran
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit

On Mar 31, 2004, at 9:33 AM, Julian Satran wrote:

> read the errata - julo

Uhm, Julian, this whole thread has been in response to the errata. I fail to
see how "read the errata" will change my mind.

"If Status is sent with the data it MUST not be sent again  with a SCSI
Response PDU as this would violate SCSI rules (a single ...."

David's concern is confusion over "with  a SCSI Response PDU". You (and I
and DLB and most of the folks on the list) know that means you don't send a
PDU; you just removed the need. A few people new to the spec, though, seem
to think you still need to send the SCSI Response PDU, just that it isn't
carrying SCSI status. Or something like that.

Adding a "MUST" will make things clear.

I'd suggest (if we can still make the change) something like:

"If Status is sent with the data it MUST not be sent again (SCSI Response
PDU MUST not be sent) as this would violate SCSI rules (a single ...."

Take care,

Bill

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

---

From: William Studenmund <[email-masked]>
Date: Wed, 31 Mar 2004 18:09:41 -0800

> paragraph of 3.5.1.5 says that you don't send a response when the 

We must have a different idea of what clear means. Note also that we
were talking about section 10.7.3, not section 3.2 or 3.5.

> doesn't mean a fifth light would help.

"Fault" is far stronger a term than I had in mind. I do not think the 
spec is at "fault,"
I think there is a point where it can be made more clear. A number of 
other
persons have agreed.

> violates the spec, as long as the developer says it's just a

Note: this moment is our last chance to change the spec. After the 
author's
"48 hours" is done, the iSCSI RFC is done. Any changes require a new
RFC.

I see no problem with making a minor, clarifying change at this point 
in time.
After all, I thought that was the point.

I think that any change should be considered on a case-by-case basis. 
The
fact that one change was or wasn't made should not impact other changes.
And if the change makes the spec clearer, in general, why wouldn't we 
do it?

[I do concede that we may want to not make the change now just to 
reduce the
number of changes, but that is a different criteria :-)  ]

> strengthen the argument considerably.

I don't think that criteria is a good one. My concern with it is that 
it requires
persons on this list to share the confusion. I'm more concerned with 
people
who aren't on the list. The persons who will be using iSCSI in one, 
two, three,
or ten years. _I_ am not confused on this point (no SCSI Command 
Response
needed with phase-collapsed read), however I can see a place (mentioned
before) where someone could, unluckily, come away with an incorrect 
understanding.
Given that, I can see how either proposed change would improve clarity.

Take care,

Bill