Subject: iSCSI - revised 2.2.4

From: "Julian Satran" <[email-masked]>
Date: Fri, 5 Oct 2001 15:05:40 +0300

Here is a revised (complete) part 2.2.4 based on recent agreed changes:

1.1.1   Text Mode Negotiation

During login and thereafter some session or connection parameters are 
negotiated through an exchange of textual information.

All negotiations are stateless - i.e. the result MUST be based only on 
newly exchanged values.

The general format of text negotiation is:

Originator-> <key>=<valuex>
Responder-> <key>=<valuey>|reject|NotUnderstood

The value can be a number, a single literal constant a Boolean value (yes 
or no) or a list of comma separated literal constant values.

In literal list negotiation, the originator sends for each key a list of 
options (literal constants which may include "none") in its order of 
preference.

The responding party answers with the first value from the list it 
supports and is allowed to use for the specific originator.

The constant "none" MUST always be used to indicate a missing function. 
However, none is a valid selection only if it is explicitly offered. 

If a target is not supporting, or not allowed to use with a specific 
originator, any of the offered options, it may use the constant "reject". 
The constants "none" and "reject" are reserved and must be used only as 
described here.  Any key not understood is answered with "NotUnderstood".

For numerical and single literal negotiations, the responding party MUST 
respond with the required key and the value it selects, based on the 
selection rule specific to the key, becomes the negotiation result. 
Selection of a value not admissible under the selection rules is 
considered a protocol error and handled accordingly. 

For Boolean negotiations (keys taking the values yes or no), the 
responding party MUST respond with the required key and the result of the 
negotiation when the received value does not determine that result by 
itself.  The last value transmitted becomes the negotiation result.  The 
rules for selecting the value to respond with are expressed as Boolean 
functions of the value received and the value that the responding party 
would select in the absence of knowledge of the received value.
 
Specifically, the two cases in which responses are OPTIONAL are:

- The Boolean function is "AND" and the value "no" is received. The 
outcome of the negotiation is "no".
- The Boolean function is "OR" and the value "yes" is received. The 
outcome of the negotiation is "yes".

Responses are REQUIRED in all other cases, and the value chosen and sent 
by the responder becomes the outcome of the negotiation.

The value "?" with any key has the meaning of enquiry and should be 
answered with the current value or "NotUnderstood".

The target may offer key=value pairs of its own. Target requests are not 
limited to matching key=value pairs as offered by the initiator.  However, 
only the initiator can initiate the negotiation start (through the first 
Text request) and completion (by setting to 1 and keeping to 1 the F bit 
in a Text request).

Comments ?

Julo

---

From: Paul Koning <[email-masked]>
Date: Fri, 5 Oct 2001 11:16:56 -0400

Excerpt of message (sent 5 October 2001) by Julian Satran:
> ...

Julian,

I'm agreeing with Santosh here -- there's extra complexity for the
boolean case that just adds code without any benefit.  More code ==
more bugs.  The rule should be the same for all cases -- responder
sends back the result of the negotiation, always, no exceptions.

That way, the half page of rules quoted above reduces to simply the
following: 

   The responding party MUST respond with the required key and the
   value it selects, based on the selection rule specific to the key,
   becomes the negotiation result.  Selection of a value not
   admissible under the selection rules is considered a protocol error
   and handled accordingly.

No exception cases, no variations for different data types.

   paul