Re: iSCSI - an improved text for 4.1 & 4.2

[Martins Krikis <mkrikis@yahoo.com>]

> +++ well we must be a funny sort of computer geeks if we assume that the
> rest of the text is understandable but here we have an issue. How about the
> following text:

I never said that the rest^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H

:-)

And I am a fairly typical geek, not of the funny sort...
Seriously, though, I've deleted most everything, except where I have
something more to say.

>          hex-constant: hexadecimal constant encoded as a string start-ing

typo, late in the paragraph (not quoted here), "eading" should be "leading".

>          base64-constant: base64 constant encoded as a string starting
>            with "0b" or "0B" followed by 1 or more digits or letters or
>            plus or slash or equal. The encoding is done according to
>            [RFC2045]. base64-constants are used to encode numerical
>            val-ues or binary strings. When used to encode numerical values
>            the excesive use of leading 0s prior to encoding - encoded as
>            "A" - is discouraged. When used to encode binary strings
>            base64-constants have an implicit byte-length that includes 6
>            bits for every character of the constant excluding trailing
>            equals (i.e., a base64-constant of n base64 characters with m
>            trailing equals has a byte-length of ((the integer part of)
>            ((n+3)*3/4) - m).

Do the n base64 characters include the m equals or not? Either way,
I don't think the formula is right, but I'm too lazy to look up the RFC.
I do know however, that the RFC makes it perfectly unambiguous what the
encoded string is, so giving this formula may not be necessary.
If it is given then I think "the integer part of n*3/4" would do,
"where n is the number of base64 digits excluding the trailing equals, 
if any".

>       The originator or declarer can either be the initiator or the target
>       and the responder can either be the target or initiator,
>       respec-tively. 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.

Shouldn't "Target requests" be changed to "Targets"?

>       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 anyone of the offered options with a
>       spe-cific originator, it MAY use the constant "Reject" or it respond
>       with an admissible value.  The selection of a value not offered is
>       consid-ered a negotiation failure and is handled as a protocol
>       error.

I don't think the word "anyone" (which may have been meant as "any one"?)
was any improvement, but I'll let the native english speakers object to this.
In order to really put it unambiguously the whole sentence has to be redone
(and I did offer a suggestion); just a one word change will not suffice, IMHO.
(And I think "options" should be "values".)

The phrase "or it respond with an admissible value" is new,
has an extra word "it", and is inapropriate here. After all, if the
responder could not use any of the offered values, yet instead of using
Reject it chose another "admissible" value, then this value is clearly
not from the offered list of values and therefore the next sentence
classifies it as a negotiation failure and a protocol error. I don't think
the specification should give instructions using "MAY" on how to create
protocol errors. 

>       For simple-value negotiations, the responding party MUST respond
>       with the same key. 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 (e.g., not within the specified bounds)
>       MAY be answered with the constant "Reject" or the responder MAY
>       select an admissible value. 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.

Why exactly is it allowed to tolerate an offer that is not admissible?
It looks like the originator that sends complete garbage may be treated
better than an originator that sends an admissible value that is not
good for the responder. I guess what I'm saying mostly applies to ranges.
This is not very important, just a weird "feature" the purpose of which
I don't really get.

Thanks,

  Martins Krikis, Intel Corp.

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