Subject: RE: iSCSI: Question about ErrorRecoveryLevel

From: [email-masked]
Date: Tue, 16 Jul 2002 22:02:03 -0400

One more clarification - in the meeting on Monday (report/results)
coming to the list shortly the rough consensus in the room was:
 
- If an implementation wants to support only one of the mechanisms
    required at ERL1, it's ok to negotiate ERL 0 (can't negotiate
    1 because that would require both mechanisms) and then try
    the mechanism of interest, but the implementation MUST be prepared
    for the attempt to fail because the other party doesn't support it.
 
Thanks,
--David

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, July 16, 2002 9:56 PM
To: Bill Studenmund
Cc: Mallikarjun C.; [email-masked]; [email-masked]; Parthi
Subject: Re: iSCSI: Question about ErrorRecoveryLevel

Bill - Yes ERL 1 implies both and at the end of the chapter the classes
associated with the level are clearly stated. Julo 

	Bill Studenmund <[email-masked]> 
Sent by: [email-masked] 

07/17/2002 03:04 AM 

        To:        "Mallikarjun C." <[email-masked]> 
        cc:        Parthi <[email-masked]>, <[email-masked]> 
        Subject:        Re: iSCSI: Question about ErrorRecoveryLevel 

On Tue, 16 Jul 2002, Mallikarjun C. wrote:

> > Every where within-command and within-connection recovery is discussed,
> > each of them is described as optional. The quote above doesn't say that
> > level 1 MUST consist of both within-connection and within-command
> > recovery.
>
> [ The error in grammar is already fixed in the working version. ]

Cool, I still haven't grabbed -15 yet.

> The reason MUST language was not used is because the text in question is
> defining the terminology, but is not phrased in such a way as to place
requirements
> on implementations.  It is similar to several terminology descriptions in
chapter 2.
>
> My intent when I wrote that text was - because the negotiation of the
> ErrorRecoveryLevel follows the regular negotiation rules (i.e. don't
originate
> a proposal that you cannot support, and the result function is "minimum"),
no
> additional MUST/SHOULD/MAY language is necessary.  But if you recommend
> explicit text, I suggest we add the following at the end of the last para
of
> text in 5.13 -

That though doesn't answer my question. :-) The main question is does
ErrorRecoveryLevel 1 imply both within-command and within-connection
support, or does it imply at least one and maybe both?

If anything, the fact that ErrorRecoveryLevel 1 implies all of 0, and 2
implies all of 1 and 0, is clear in the draft now.

> When a defined value of ErrorRecoveryLevel is proposed by an
> originator in a text negotiation, the originator MUST support the
> functionality defined for the ErrorRecoveryLevel or functionality
                                                  ^^
Is this supposed to be "and"?

> corresponding to any defined value numerically less than the proposed.
> When a defined value of ErrorRecoveryLevel is returned by a responder
> in a text negotiation, the responder MUST support the functionality
> corresponding to the ErrorRecoveryLevel it is accepting.

If "and" is appropriate, then shouldn't we add, "and all numerically lower
levels" to the end of the paragraph?

I'm happy with ErrorRecoveryLevel 1 == both within-connection and
within-command recovery. I'm also happy with ErrorRecoveryLevel 1 ==
within-command, within-connection, or both (and ErrorRecoveryLevel 2 being
both). I just think with the amount of, "optional," used in conjunction
with error recovery that it's not clear which case we want.

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 17 Jul 2002 10:38:47 -0700 (PDT)

>     for the attempt to fail because the other party doesn't support it.

Thanks. That addresses the other half of my confusion.

Take care,

Bill