Re: [storm] What if a SCSI Response PDU has GOOD status and a DataSegment?

[WG chair hat OFF]

Here's a little more background.  There's an open issue in T10
about whether sending sense data with GOOD status can just be
done, vs. whether the target ought to know in advance that
the initiator is prepared for this.  

In keeping with the IETF advice to be "conservative in what
is sent and liberal in what is accepted", if T10 decides not
to address this at the SCSI level, then it'll be reasonable
to define an iSCSI negotiation key to indicate that the
initiator is prepared to accept (in the sense of "tolerate",
i.e., won't cause an error or worse, rather than any promise
to "process" or "understand") sense data for GOOD status.

In addition (as Ralph suggests), it may make sense (pun intended)
to define this key to cover all status values, not just GOOD,
even though only GOOD is currently under discussion in T10.

Thanks,
--David

> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] 
> On Behalf Of Ralph Weber
> Sent: Tuesday, November 24, 2009 7:14 PM
> To: storm@ietf.org
> Subject: [storm] What if a SCSI Response PDU has GOOD status 
> and a DataSegment?
> 
> One of the questions that T10 has been wrestling with lately
> concerns a case where their equivalent of the iSCSI Response
> PDU contains a status other than CHECK CONDITION and sense
> data in a Data Segment.
> 
> What will initiators do if handed one of these beasts?
> 
> Note: GOOD is the current favorite doppelganger for CHECK
> CONDITION, but BUSY et al. should be considered too when
> thinking about what initiators might do.
> 
> The current belief in T10 is that initiators most likely
> will ignore any Data Segment found in a Response PDU with
> GOOD status. This is based on the notion that initiators
> do not squander the extra cycles needed to validate entire
> format of a Response PDU.
> 
> What do the implementers of iSCSI initiators think?
> 
> All the best,
> 
> .Ralph
> 
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm
> 
> 