RE: iSCSI: Question about ErrorRecoveryLevel

[Black_David@emc.com]

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:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 16, 2002 9:56 PM
To: Bill Studenmund
Cc: Mallikarjun C.; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; 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 <wrstuden@wasabisystems.com> Sent by: owner-ips@ece.cmu.edu 07/17/2002 03:04 AM

To:        "Mallikarjun C." <cbm@rose.hp.com>         cc:        Parthi <pamanick@npd.hcltech.com>, <ips@ece.cmu.edu>         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.