RE: iSCSI 4.1 & 4.2

[pat_thaler@agilent.com]

I agree. Negotiations are not stateless. At a minimum there is the state of
the latest value plus knowledge of whether that value has been negotiated
yet.

Pat

-----Original Message-----
From: Mallikarjun C. [mailto:cbm@rose.hp.com]
Sent: Monday, April 29, 2002 10:12 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI 4.1 & 4.2


Julian,

> All negotiations are stateless and explicit (i.e., the result MUST be....

I suggest it's time to change the `stateless' language.  Besides the
reasons I already offered in an earlier posting (
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09731.html ),
there are several references to "reset the negotiation" in section 4.5
and elsewhere.  I presume that the attribute being reset here is
the "state" of the negotiation.

Instead, an alternative formulation strawman in my earlier posting may
be considered.

> Specifically, the two cases in which responses are OPTIONAL are:

I would strongly recommend getting rid of this special case.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com



----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Saturday, April 27, 2002 9:38 AM
Subject: iSCSI 4.1 & 4.2


> Here are the rephrased 4.1 & 4.2 for better context:
>
> Text Format
> The initiator and target send a set of key=value pairs encoded in UTF-8
> Unicode. All the text keys and text values specified in this docu-ment are
> to be presented and interpreted in the case they appear in this document.
> They are case sensitive.
>
> The following character symbols are used in this document for text items:
>
> (a-z, A-Z) - letters
> (0-9) - digits
> " " (0x20) - space
> "." (0x2e) - point
> "-" (0x2d) - minus
> "+" (0x2b) - plus
> "@" (0x40) - commercial at
> "_" (0x5f) - underscore
> "=" (0x3d) - equal
> ":" (0x3a) - colon
> "/" (0x2f) - solidus or slash
> "[" (0x5b) - left bracket
> "]" (0x5d) - right bracket
> null(0x00) - null separator
> "," (0x2c) - comma
> "~" (0x7e) - tilde
>
> A key is key-name followed by "=". The term key is used frequently in this
> document with the meaning of key-name.
>
> A value is whatever follows the = that follows the key-name up to a null
> separator - that separates one key value from the next
>
> The following definitions will be used in the rest of this document:
>
> key-name: a string defined by the regular expression
> "[A-Z][a-zA-Z0-9.-+@_]*"
>
> text-value: a string defined by the regular expression
> "[][a-zA-Z0-9.-+@_/\[\]=]*"
>
> boolean-value: a string defined by the regular expression
> "Yes|No"
>
> hex-constant: unsigned hexadecimal constant described by regu-lar
> expression "0[xX][0-9a-zA-Z]+"
>
> base-64-constant: unsigned base-64 constant described by regu-lar
> expression "0b[A-Za-z0-9+/=]+"
>
> regular-numerical-value :  an unsigned integer less than 2**64 encoded as
> a decimal constant, hex constant, or base-64 con-stant
>
> large-numerical-value :  an unsigned integer larger than 2**64-1 encoded
> as a hex constant, or base-64 constant
>
> numerical-value: a regular-numerical-value or a large numeri-cal-value
>
> numeric-range: two numerical-values separated by a tilde
>
> simple-value: text-value, boolean-value, numeric-value or a numeric range.
>
> list-of-values: a sequence of text-values separated by comma
>
>
> Key names MUST NOT exceed 63 bytes.  If not otherwise specified, the
> maximum length of a simple-value (not its encoded representation) is 255
> bytes not including the delimiter (comma or null).
>
> Any iSCSI target or initiator MUST support receiving at least 16384 bytes
> of key=value data in a negotiation sequence except when indicat-ing
> support for very long authentication items such as public key
> cer-tificates in which case they MUST support receiving at least 64
> kilobytes of key=value data.
>
> Text Mode Negotiation
> During login, and thereafter, some session or connection parameters are
> negotiated through an exchange of textual information.
>
> The initiator starts the negotiation through a Text/Login request and
> indicates when it is ready for completion (by setting to 1 and keeping to
> 1 the F bit in a Text Request or the T bit in the Login Request).
>
> The general format of text negotiation is:
>
> Originator-> <key>=<valuex>
> Responder-> <key>=<valuey>|NotUnderstood|Irrelevant|Reject
>
> The originator can either be the initiator or the target and the responder
> can either be the target or initiator, respectively. Target requests are
not limited to respond to key=value
pairs as offered
> by the initiator. The target may offer key=value pairs of its own.
>
> All negotiations are stateless and explicit (i.e., the result MUST be
> based only on newly exchanged values). There is no such thing as implicit
> offers. If an explicit offer is not made then a reply cannot be expected.
>
> The value offered can be an numerical-value, a numerical-range defined by
> lower and upper value - both integers separated by tilde, a a text-value,
> a boolean-value (Yes or No), or a list of comma sepa-rated text-values. A
> range MAY ONLY be offered if it is explicitly allowed for a key. A
> selected value can be an numerical-value, a text-value or a boolean-value.
>
> In list negotiation, the originator sends a list of values (which may
> include "None") for each key in its order of preference.
>
> The responding party answers with the first value that it supports and is
> allowed to use for the specific originator selected from the orig-inator
> list.
>
> The constant "None" MUST always be used to indicate a missing func-tion.
> However, None is a valid selection only if it is explicitly offered.
>
> If a responder does not understand any particular value in a list it MUST
> ignore it. If a responder does not support, does not understand or is not
> allowed to use all of the offered options with a specific originator, it
> MAY use the constant "Reject".  The selection of a value not admissible
> under the selection rules is considered a negoti-ation failure and is
> handled accordingly.
>
>
> For simple-value negotiations, the responding party MUST respond with the
> required key. The value it selects, based on the selection rule specific
> to the key, becomes the negotiation result. For a numerical range the
> value selected must be an integer within the offered range or "Reject" (if
> the range is unacceptable).  An offer of a value not admissible MAY be
> answered with the constant "Reject". The selection of a value not
> admissible under the selection rules is considered a negotiation failure
> and is 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 with which to respond 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.
>
> An offer of a value not admissible MAY be answered with the constant
> "Reject". The selection of a value not admissible under the selection
> rules is considered a negotiation failure and is handled accordingly.
>
> If a specific key is not relevant for the current negotiation, the
> responder may answer with the constant "Irrelevant" for all types of
> negotiation.  However the negotiation is not considered as failed if the
> response is Irrelevant.
>
> Any other key not understood by the responder may be ignored by the
> responder without affecting the basic function. However, the Text Response
> for a key not understood MUST be key=NotUnderstood.
>
> The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are
> reserved and must only be used as described here.
>
> Some basic key=value pairs are described in Chapter 11. All keys in
> Chapter 11, except for the X- extension format, MUST be supported by iSCSI
> initiators and targets and MUST NOT be answered with NotUnder-stood.
>
> Manufacturers may introduce new keys by prefixing them with X- fol-lowed
> by their (reversed) domain name. For example the company owning the domain
> acme.com can issue:
>
> X-com.acme.bar.foo.do_something=3