RE: Problem with use of NotUnderstood in negotiations

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Fri, 9 Aug 2002, Bart Crane wrote:

> -----Original Message-----
> From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
> Sent: Friday, August 09, 2002 1:05 PM
> To: bcrane@iready.com; ips@ece.cmu.edu
> Subject: RE: Problem with use of NotUnderstood in negotiations
>
>
> Bart,
>
> So the question is, in what order does a device do the checking.
>
> There are many possibilites for handling a received key that is
> unknown and comes in with the value unknown:
>
> A) Check key
>        if key unknown, send key=NotUnderstood
>          else ...process key=value pair
>
> B) Check key
>        if key unknown
>          if value=NotUnderstood silently drop (or close connection)
>            else send key=NotUnderstood
>
> I expect case A is more likely to get implemented in the absence
> of an explicit statement. There would normally be no need to
> examine the value of a key when one doesn't understand the key.
> In this case, the receiver never does a test that detects the
> apparent protocol violation of making an offer with a value
> NotUnderstood.
>
> So, if we want to stop the loop that Bill has found, we should
> put in an explicit requirement to test the value for NotUnderstood
> before responding to a key with NotUnderstood.
>
> [Bart Crane]
> Sec. 4.2 stating that "None", "Reject", "Irrelevant" and "NotUnderstood"
> are reserved implies that they do need to be tested.  The proposed
> rule also implies that they be tested.
>
> My interpretation is that these values must not be used, except in
> the way that the spec defines their use.
>
> The spec defines their use ONLY as a response to an iSCSI-defined key.

The problem is that we're actually discussing what to do with an
iSCSI-undefined key.

The spec seems to assume (quite reasonably) that keys one side doesn't
understand are there because the other side offered them and thus the
other side understands them. By just sending back "NotUnderstood",
negotiations can experiment some to see what keys are available.

This is a case where neither side understands the key.

> So, their being used as the initial value to any key is prohibited.

?? In the scenario I describe, neither side believes it offered the key.

> Thus, there is no need to add another rule regarding not-responding to
> keys with NotUnderstood as a value, because a key with that value is
> a protocol error.
>
> This could be made more explicit, but there does not seem to be any
> ambiguity.

There obviously is ambiguity. The fact we're having this discussion is
proof. :-)

I'd support saying this case is a protocol error, since it means something
neither side understands got into the stream (and chances are an offer got
removed). But I think adding an explicit direction as to what to do is
needed.

Take care,

Bill