Subject: Re: iSCSI - an improved text for 4.1 & 4.2

From: "Julian Satran" <[email-masked]>
Date: Sat, 11 May 2002 01:06:23 +0300

Comments in text - Julo

Martins Krikis <[email-masked]>
Sent by: [email-masked]
05/11/2002 01:06 AM
Please respond to Martins Krikis

        To:     [email-masked]
        cc: 
        Subject:        Re: iSCSI - an improved text for 4.1 & 4.2

> +++ 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".
+++ i will check +++
>       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"?
+++ target qualifies requests +++
>       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. 
+++ selection of an admisible value is out of context here it was meant 
only for simple values+++
>       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

---

From: Martins Krikis <[email-masked]>
Date: Fri, 10 May 2002 15:43:29 -0700 (PDT)

--- Julian Satran <[email-masked]> wrote:

> >       Target requests are not
> >       limited to respond to

But targets don't send requests, they send responses.

Anyway, I'm done commenting on these sections.
Thanks very much for addressing all the isssues.

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

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Mother's Day is May 12th!
http://shopping.yahoo.com