Re: iSCSI - an improved text for 4.1 & 4.2

[Martins Krikis <mkrikis@yahoo.com>]

Adding regular expressions, where possible, would
have benefited the draft, IMHO. More comments follow.

> key-name:  a string of one or more characters consisting of letters, digits,
> point, minus, plus, commercial at, and underscore, A key-name MUST begin with
> a capital letter an must not exceed 63 characters.

I believe it should be "dot" instead of "point".

> iSCSI-local-name-value:  an UTF-8 string terminated by the null character that
> terminates the key=value pair; no null charac-ters are allowed in the
> string. This encoding is to be used for localized (internationalized) aliases.

Very strangely this definition starts mentioning the
terminator when others didn't. And null characters
aren't allowed in any other kind of values either,
are they? If so, how do we know where the value
really ends?

> boolean-value:  the strings "Yes" or "No".

"string".

> decimal-constant:  an unsigned decimal number - a string of 1 or more digits
> starting with a non-zero digit. This encoding is not used for numerical values
> equal or greater than 2**64.

We just disallowed the 0 itself.

> base-64-constant:  unsigned base-64 constant encoded as a string starting with
> "0b" or "0B" followed by 1 or more digits or letters or plus or slash or
> equal.
> regular-numerical-value :  an unsigned integer less than 2**64 encoded as a
> decimal-constant, hex constant, or base-64 con-stant. For base-64 encoding the
> encoding is done according to [RFC2045].

How the encoding is done would be better put higher
up with the base-64-constant definition, then it would
not need to be repeated again and again.

> numeric-range:  two numerical-values separated by a tilde.

Why not mention here that the values must come in non-decreasing order?

> regular-binary-value :  a binary string less than 64 bits encoded as a decimal
> constant, hex constant or base-64 con-stant. For base-64 encoding the encoding
> is done according to [RFC2045]. The length of the string is either specified
> by the key definition or is implied by the encoding as the mini-mum number of
> bytes that can hold the encoded string.

The last sentence is ambiguous, IMHO, and incorrect
no matter how understood. If, encoded as  
as a hex constant, the value is 0x000f, what is its
length when decoded? 6 bytes ("0x000f" w/o '\0') 
or 1 byte (containing bits 00001111)? The answer
that I think we want is 2 bytes... The problem is that
not knowing what the string is, we can't tell
how many bytes are required to hold it. Some other
description will be necessary, I'm afraid.

> simple-value:  text-value, iSCSI-name-value, boolean-value, numeric-value, a
> numeric-range or a binary-value.

iSCSI-local-name-value seems to be missing.

> All negotiations are explicit (i.e., the result MUST be based only on newly
> exchanged or declared values). There are no implicit offers. If an explicit
> offer is not made then a reply cannot be expected. Con-servative design
> requires also that default values should not be relied upon when use of some
> other value has serious consequences.

Negotiations are not explicit due to the boolean omission "feature".
Offers are explicit, negotiations aren't.

> None, Reject or Irrelevant are legitimate negotiation options where allowed
> but their excessive use is discouraged.

Why is the use of "None" discouraged? In fact, "None" is not very
special after all---it is only allowed in a response, if offered...

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

If I don't support "all", but support at least one of the offered values,
I should answer with something I support and not with Reject. 
"Options" have not been defined or used before. Alright, I'm not a
native English speaker myself, but I'll volunteer:

  If each of the offered values is not understood or not supported,
  or the responder is not allowed to use it with the specific originator,
  it MAY use the constant "Reject".

And I would prefer a MUST instead of MAY.

> The selection of a value not admissible under the
> selection rules is considered a nego-tiation failure and is handled as a
> protocol error. The selection rules are key-specific.

It was just said above (I didn't quote it) that the selection rule is
to pick the first value supported. Thus, I'm not sure why here the
rule is key-specific.

> For simple-value negotiations, the responding party MUST respond with the same
> key. 

We forgot to mention the same for list negotiations.

> The value it selects, based on the selection rule spe-cific 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" or the responder MAY select an admissible value.

What was meant here by "value not admissible"? Outside the legal range
of values or simply outside the range that the responder supports?

> The
> selection, by the responder, of a value not admissible under the selection
> rules is considered a negotiation failure and is handled accordingly. The
> selection rules are key-specific.

Rules again are key-specific, when it was just said that the rule is
to pick a value from the range (or Reject, or, well, that part was not
clear), but they don't seem to be key-specific again...

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

I've mentioned this numerous times, nobody seems to care. IMO, there
is a logic flay here:

InitialR2T: function OR, default Yes.

I -> T: No

Target wants "No", too. However, in the 
"absence of the knowledge of the received value", it would have
been forced to stick with the default "Yes". 

According to the quoted sentence above, the target must reply
with OR(No, Yes) = Yes. Thus:

T -> I: Yes

Congratulations. Both parties wanted "No", but due to logic errors in
the specification were forced to settle with "Yes".

Am I right or wrong?

Besides, this sentence is in the context of value omissions, so it
should not be talking about the value to respond anyway.

I'll volunteer for a fix-up (for the whole boolean negotiation part,
until the word "Specifically"):

  For boolean negotiations (keys taking the values Yes or No), 
  the negotiation result is determined by applying the key-specific
  boolean function to the value received and the value that the
  responding party would have offered, had it been the first to do so.
  The respoponding party MUST respond with the same 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.

Thanks for your attention to these issues,



    Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not be those of my employer.