Re: iSCSI: current UNH Plugfest

["Julian Satran" <Julian_Satran@il.ibm.com>]

Bob,

The spec already says MUST.  I don't agree that saying MUST twice is a 
good practice.

Julo




"Robert D. Russell" <rdr@mars.iol.unh.edu>
01-11-01 16:50
Please respond to "Robert D. Russell"

 
        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     ips@ece.cmu.edu
        Subject:        Re: iSCSI: current UNH Plugfest

 

Julian:

IMHO if we mean MUST then we MUST say MUST.

It is clear from the exchange between Anshul, Santosh and Robert
that we already have different interpretations of what
it means without MUST and hence we have interoperability problems.

In this particular case I agree with Anshul and Robert that the
standard should say MUST.  Santosh's argument that in an error
case the data gets lost does not seem to be relevant --
in error cases lots of information gets lost and recovery is
necessary to get that information back.  The spec provides for
this.  We should not be introducing interoperability problems
because of a situation that may arise in the rare case of an error,
especially when the spec already deals with recovery of that
information when the error is detected.

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774


On Thu, 1 Nov 2001, Julian Satran wrote:

> Anshul,
> 
> IMHO a single MUST in the paragraph is strong enough and covers all the 
> cases.
> 
> Julo
> 
> 
> 
> 
> "Anshul Chadda" <anshul.chadda@trebia.com>
> Sent by: owner-ips@ece.cmu.edu
> 31-10-01 19:34
> Please respond to "Anshul Chadda"
> 
> 
>         To:     <ips@ece.cmu.edu>
>         cc: 
>         Subject:        Re: iSCSI: current UNH Plugfest
> 
> 
> 
> Hello:
> As this issue has come up with setting CHECK CONDITION in the SCSI 
> Response. It is assumed that if CHECK CONDITION is set in the SCSI 
> Response PDU, then there has to be sense data accompanied with it. So as 

> far as I see it, it would help if the following sentence in the draft 
has 
> the MUST/must in there. In the current wording, i can think that if 
there 
> is no data segment in the SCSI Response PDU for a CHECK CONDITION, it is 

> still OK.
> 
> In draft 8, the sentence looks like the following: 
> -------------------------------------------------------
> 3.4.6 Data Segment - Sense and Response Data Segment
> iSCSI targets MUST support and enable autosense. If Status is CHECK 
> CONDITION (0x02), then the Data Segment contains sense data for the 
failed 
> command.
> -------------------------------------------------------
> 
> It can be changed to the following:
> 
> -------------------------------------------------------
> 3.4.6 Data Segment - Sense and Response Data Segment
> iSCSI targets MUST support and enable autosense. If Status is CHECK 
> CONDITION (0x02), then the target MUST have sense data in the data 
segment 
> for the failed command.
> -------------------------------------------------------
> I don't know if there is a reason that the draft has the wording in the 
> current way.  Apologies if this subject has already been discussed. 
> 
> Regards,
> Anshul
> 
> 
-----------------------------------------------------------------------------------------------------------------
> 
> 5. Some common error situations:
> 
>    1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02),
>       some targets are not including the SenseLength as the first 2
>       bytes in the data segment.  Although the format of the data 
segment
>       is clear from the diagram in section 3.4.6 on page 62 of draft 8
>       (page 63 of draft 8a), the last entry in the diagram for the SCSI
>       Response PDU on page 58 of draft 8 (page 59 of draft 8a) is
>       misleading because it mentions only the Sense Data and Response
>       Data and omits the Sense Length.  It would therefore be helpful
>       if the last entry in the diagram on page 58 were changed to 
> explicitly
>       reference the diagram on page 62, as in:
> 
>          Data Segment -- see section 3.4.6 (optional)
> 
> 
> 
> 
>