Subject: Question about ErrorRecoveryLevel

From: Bill Studenmund <[email-masked]>
Date: Mon, 15 Jul 2002 11:55:18 -0700 (PDT)

I have a question about within-command and within-connection recovery and
ErrorRecoveryLevel. Mainly what does ErrorRecoveryLevel 1 imply. I think
the answer is that it implies either one (or both) of within-command and
within-connection recovery methods are supported. Is that correct?

i.e. A, B, or A & B. ?

Thus if I have within-command recovery I can operate at ErrorRecoveryLevel
1 even w/o having within-connection recovery.

Take care,

Bill

---

From: Parthi <[email-masked]>
Date: Tue, 16 Jul 2002 09:18:02 +0530

> within-connection recovery methods are supported. Is that correct?

A & B is  correct .

Error RecoveryLevel  1 implies  Digest failure recovery.

Digest failure recovery is  consist of two recovery classes,
Within-Connection recovery class and Within-Command recovery class.

> Bill

Thanks,
Parthi

--
http://san.hcltech.com

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 16 Jul 2002 11:38:24 -0700 (PDT)

> Within-Connection recovery class and Within-Command recovery class.

Well, besides the grammar error you're quoting from the spec, that quote
doesn't answer the question. That text essentially gave rise to my
question. :-)

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.

Take care,

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 16 Jul 2002 15:04:15 -0700

> level 1 MUST consist of both within-connection and within-command

[ The error in grammar is already fixed in the working version. ]

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 -

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 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.

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 16 Jul 2002 17:04:58 -0700 (PDT)

> [ The error in grammar is already fixed in the working version. ]

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

> explicit text, I suggest we add the following at the end of the last para of

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

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: "Mallikarjun C." <[email-masked]>
Date: Tue, 16 Jul 2002 17:25:27 -0700

Comments in text.
--
Mallikarjun

Mallikarjun Chadalapaka

> support, or does it imply at least one and maybe both?

Both.  It is clear to me by the way the terminology is defined ( note the "and"
in 5.13).  I thought your question had to do with implementation expectations.

> Is this supposed to be "and"?

Okay, "and" may be clearer (the "or" was used because only one of
the levels can be picked by the reponder).

> levels" to the end of the paragraph?

I don't see the need.  If I'm accepting X, then I am promising to employ 
X in the session operation.  OTOH, if I'm offering X, it means that I'm
promising to settle for any Y, where 0<=Y<=X, that the other side would
return in the response.

IMO, the point that the functionality is hierarchical doesn't need to be made 
everywhere.