Subject: RE: iSCSI: Confusing wording in description of Status-Class

From: [email-masked]
Date: Wed, 29 May 2002 11:00:24 -0600

Julian,
 
I agree that there are valid reasons to chose not to follow redirection and not complete the connection. Therefore the
must should stay lower case. For instance, if the TargetAddress indicated an external domain one might not
choose to follow it or the TargetAddress might be a port to which one already has a connection open.
 
Regards,
Pat

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, May 29, 2002 9:36 AM
To: Paul Koning
Cc: [email-masked]; [email-masked]
Subject: Re: iSCSI: Confusing wording in description of Status-Class

I will say exception but not MUST as you may not to follow redirection before consulting an oracle :-) (only partly joking). 

Julo 

	Paul Koning <[email-masked]> 
Sent by: [email-masked] 

05/29/2002 07:14 PM 
Please respond to Paul Koning 

        To:        [email-masked] 
        cc:         
        Subject:        iSCSI: Confusing wording in description of Status-Class 

We have run into misinterpretations of the description of Status-Class
(section 9.13.5).  As written, it can be misread to say that
Redirection (Status-Class = 1) is an error, and initiators can treat a
redirection response from a target by failing the I/O rather than by
following the redirection pointer.

The current wording is:

    A non-zero Status-Class indicates an exception. In this case, Status-
    Class is sufficient for a simple initiator to use when handling 
    errors, without having to look at the Status-Detail.  The Status-
    Detail allows finer-grained error recovery for more sophisticated 
    initiators, as well as better information for error logging.
    ...
      1 - Redirection - indicates that the initiator must take further 
           action to complete the request. This is usually due to the 
           target moving to a different address. ...

I would propose the following rewording:

    A non-zero Status-Class indicates an exception. In this case, Status-
    Class is sufficient for a simple initiator to use when handling 
    exceptionss, without having to look at the Status-Detail.  The Status-
    Detail allows finer-grained exception handling for more sophisticated 
    initiators, as well as better information for error logging.
    ...
      1 - Redirection - indicates that the initiator MUST take further 
           action to complete the request. This is usually due to the 
           target moving to a different address. ...

The wording changes are: replace "error" by "exception" in the first
paragraph, since redirects are not errors, and use "MUST" rather than
"must" in the description of redirect.

      paul

---

From: Paul Koning <[email-masked]>
Date: Wed, 29 May 2002 13:44:25 -0400

>>>>> "pat" == pat thaler <[email-masked]> writes:

 pat> Julian, I agree that there are valid reasons to chose not to
 pat> follow redirection and not complete the connection. Therefore
 pat> the must should stay lower case. For instance, if the
 pat> TargetAddress indicated an external domain one might not choose
 pat> to follow it or the TargetAddress might be a port to which one
 pat> already has a connection open.
 
Thanks, that explanation helps.  What I was looking for was agreement
that simply saying "Redirect is an error, I don't ever do redirect, I
just fail the I/O" is not right.

     paul 
 
> -----Original Message----- From: Julian Satran

> I will say exception but not MUST as you may not to follow
> redirection before consulting an oracle :-) (only partly
> joking).

> Julo

 pat> Paul Koning <[email-masked]> Sent by: [email-masked]

 pat> 05/29/2002 07:14 PM Please respond to Paul Koning

 pat> To: [email-masked] cc: Subject: iSCSI: Confusing wording in
 pat> description of Status-Class

 pat> We have run into misinterpretations of the description of
 pat> Status-Class (section 9.13.5).  As written, it can be misread to
 pat> say that Redirection (Status-Class = 1) is an error, and
 pat> initiators can treat a redirection response from a target by
 pat> failing the I/O rather than by following the redirection
 pat> pointer.

 pat> The current wording is:

 pat> A non-zero Status-Class indicates an exception. In this case,
 pat> Status- Class is sufficient for a simple initiator to use when
 pat> handling errors, without having to look at the Status-Detail.
 pat> The Status- Detail allows finer-grained error recovery for more
 pat> sophisticated initiators, as well as better information for
 pat> error logging.  ...  1 - Redirection - indicates that the
 pat> initiator must take further action to complete the request. This
 pat> is usually due to the target moving to a different address. ...

 pat> I would propose the following rewording:

 pat> A non-zero Status-Class indicates an exception. In this case,
 pat> Status- Class is sufficient for a simple initiator to use when
 pat> handling exceptionss, without having to look at the
 pat> Status-Detail.  The Status- Detail allows finer-grained
 pat> exception handling for more sophisticated initiators, as well as
 pat> better information for error logging.  ...  1 - Redirection -
 pat> indicates that the initiator MUST take further action to
 pat> complete the request. This is usually due to the target moving
 pat> to a different address. ...

 pat> The wording changes are: replace "error" by "exception" in the
 pat> first paragraph, since redirects are not errors, and use "MUST"
 pat> rather than "must" in the description of redirect.

 pat> paul

 pat> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 pat> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html;
 pat> charset=iso-8859-1">

 pat> <META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
 pat> <BODY> <DIV><SPAN class=155254816-29052002><FONT face=Arial
 pat> size=2>Julian,</FONT></SPAN></DIV> <DIV><SPAN
 pat> class=155254816-29052002><FONT face=Arial
 pat> size=2></FONT></SPAN>&nbsp;</DIV> <DIV><SPAN
 pat> class=155254816-29052002><FONT face=Arial size=2>I agree that
 pat> there are valid reasons to chose not to follow redirection and
 pat> not complete the connection. Therefore the</FONT></SPAN></DIV>
 pat> <DIV><SPAN class=155254816-29052002><FONT face=Arial size=2>must
 pat> should stay lower case. For instance, if the TargetAddress
 pat> indicated an external domain one might not</FONT></SPAN></DIV>
 pat> <DIV><SPAN class=155254816-29052002><FONT face=Arial
 pat> size=2>choose to follow it or the TargetAddress might be a port
 pat> to which one already has a connection open.</FONT></SPAN></DIV>
 pat> <DIV><SPAN class=155254816-29052002><FONT face=Arial
 pat> size=2></FONT></SPAN>&nbsp;</DIV> <DIV><SPAN
 pat> class=155254816-29052002><FONT face=Arial
 pat> size=2>Regards,</FONT></SPAN></DIV> <DIV><SPAN
 pat> class=155254816-29052002><FONT face=Arial
 pat> size=2>Pat</FONT></SPAN></DIV> <DIV><SPAN
 pat> class=155254816-29052002><FONT face=Arial
 pat> size=2></FONT></SPAN>&nbsp;</DIV> <DIV><SPAN
 pat> class=155254816-29052002><FONT face=Arial
 pat> size=2></FONT></SPAN>&nbsp;</DIV> <DIV
 pat> class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
 pat> size=2>-----Original Message-----<BR><B>From:</B> Julian Satran
 pat> [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May
 pat> 29, 2002 9:36 AM<BR><B>To:</B> Paul Koning<BR><B>Cc:</B>
 pat> [email-masked]; [email-masked]<BR><B>Subject:</B> Re:
 pat> iSCSI: Confusing wording in description of
 pat> Status-Class<BR><BR></FONT></DIV><BR><FONT face=sans-serif
 pat> size=2>I will say exception but not MUST as you may not to
 pat> follow redirection before consulting an oracle :-) (only partly
 pat> joking).</FONT> <BR><BR><FONT face=sans-serif size=2>Julo</FONT>
 pat> <BR><BR><BR> <TABLE width="100%"> <TBODY> <TR vAlign=top> <TD>
 pat> <TD><FONT face=sans-serif size=1><B>Paul Koning
 pat> &lt;[email-masked]&gt;</B></FONT> <BR><FONT face=sans-serif
 pat> size=1>Sent by: [email-masked]</FONT> <P><FONT
 pat> face=sans-serif size=1>05/29/2002 07:14 PM</FONT> <BR><FONT
 pat> face=sans-serif size=1>Please respond to Paul Koning</FONT>
 pat> <BR></P> <TD><FONT face=Arial size=1>&nbsp; &nbsp; &nbsp; &nbsp;
 pat> </FONT><BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp;
 pat> &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;[email-masked]</FONT>
 pat> <BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; cc:
 pat> &nbsp; &nbsp; &nbsp; &nbsp;</FONT> <BR><FONT face=sans-serif
 pat> size=1>&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp;
 pat> &nbsp;iSCSI: Confusing wording in description of
 pat> Status-Class</FONT> <BR><BR><FONT face=Arial size=1>&nbsp;
 pat> &nbsp; &nbsp; &nbsp;</FONT></TR></TBODY></TABLE><BR><BR><FONT
 pat> face="Courier New" size=2>We have run into misinterpretations of
 pat> the description of Status-Class<BR>(section 9.13.5). &nbsp;As
 pat> written, it can be misread to say that<BR>Redirection
 pat> (Status-Class = 1) is an error, and initiators can treat
 pat> a<BR>redirection response from a target by failing the I/O
 pat> rather than by<BR>following the redirection pointer.<BR><BR>The
 pat> current wording is:<BR><BR>&nbsp; &nbsp; A non-zero Status-Class
 pat> indicates an exception. In this case, Status-<BR>&nbsp; &nbsp;
 pat> Class is sufficient for a simple initiator to use when handling
 pat> <BR>&nbsp; &nbsp; errors, without having to look at the
 pat> Status-Detail. &nbsp;The Status-<BR>&nbsp; &nbsp; Detail allows
 pat> finer-grained error recovery for more sophisticated <BR>&nbsp;
 pat> &nbsp; initiators, as well as better information for error
 pat> logging.<BR>&nbsp; &nbsp; ...<BR>&nbsp; &nbsp; &nbsp; 1 -
 pat> Redirection - indicates that the initiator must take further
 pat> <BR>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;action to complete
 pat> the request. This is usually due to the <BR>&nbsp; &nbsp; &nbsp;
 pat> &nbsp; &nbsp; &nbsp;target moving to a different
 pat> address. ...<BR><BR>I would propose the following
 pat> rewording:<BR><BR>&nbsp; &nbsp; A non-zero Status-Class
 pat> indicates an exception. In this case, Status-<BR>&nbsp; &nbsp;
 pat> Class is sufficient for a simple initiator to use when handling
 pat> <BR>&nbsp; &nbsp; exceptionss, without having to look at the
 pat> Status-Detail. &nbsp;The Status-<BR>&nbsp; &nbsp; Detail allows
 pat> finer-grained exception handling for more sophisticated
 pat> <BR>&nbsp; &nbsp; initiators, as well as better information for
 pat> error logging.<BR>&nbsp; &nbsp; ...<BR>&nbsp; &nbsp; &nbsp; 1 -
 pat> Redirection - indicates that the initiator MUST take further
 pat> <BR>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;action to complete
 pat> the request.  This is usually due to the <BR>&nbsp; &nbsp;
 pat> &nbsp; &nbsp; &nbsp; &nbsp;target moving to a different
 pat> address. ...<BR><BR>The wording changes are: replace "error" by
 pat> "exception" in the first<BR>paragraph, since redirects are not
 pat> errors, and use "MUST" rather than<BR>"must" in the description
 pat> of redirect.<BR><BR>&nbsp; &nbsp; &nbsp;
 pat> paul<BR><BR></FONT><BR><BR></BODY></HTML>