Re: iSCSI 4.1 & 4.2

[Martins Krikis <mkrikis@yahoo.com>]

The new text does not seem to have benefited at all
from the concerns
expressed just days ago in the thread named "iSCSI:
Questions regarding
text parameter 'Reject' and 'Irrelevant' usage".
Luckily David Black
already picked on many of those issues, so I'll just
repeat what I still
see as not addressed.

> text-value: a string defined by the regular
statement
> "[][a-zA-Z0-9.-+@_/\[\]=]*"

Why is each of the square brackets mentioned twice in
the character class?

> All negotiations are stateless and explicit...

We should get rid of boolean value omission. Otherwise
let's not call
it "explicit". Most everybody objects to calling it
"stateless", so
that should go, too.

> In list negotiation, the originator sends a list of
values 
> (which may include "None") for each key in its order
of preference.

Can we drop "for each key" here? We're already
concentrating on
one particular key here, I presume, one that allows
list negotiations.

> If a responder does not support, does not understand
> or is not allowed to use all of the offered options
with a specific
> originator...

This sentence can easily be parsed not the way it was
intended, because
of the word "all". (I don't have to be able to use
"all" of the offered
text-values, being able to use one suffices!). 

"Options" have not been defined.

> The selection of a
> value not admissible under the selection rules is
considered a
> negoti-ation failure and is handled accordingly.

Need a clarification of what is "not admissible under
the selection rules".

Need a clarification on "handled accordingly".

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

What's a "required key"? Has to respond with the same
key? 
Then this should have been the case for all kinds of
negotiations, including
list negotiations above and all the other kinds below.
Can we specify
so higher up or drop this sentence altogether, since
we seem to be focusing
on values, not on keys here and this is certainly not
a simpe-value specific
thing?

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

If we cannot require explicit Boolean negotiations,
let's at least fix
the wording here. I consider it logically incorrect,
please see
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09755.html

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

Is it considered "failed" if the response is "Reject"?
What value should each party settle on for this key? 
May this key appear again in the same negotiation
sequence?

I'll repeat again that I think the use of Irrelevant
should be disallowed
(no parameter dependencies currently in the
operational stage anyway).

In general, I'd like the text to address the questions
posted in the
above mentioned thread. Namely, which keys may be
repeated?
The ones answered with Reject? The ones answered with
Irrelevant?
Any others? If there are situations when the key may
be offered again
in the same negotiation sequence, can we have an
explanation of why this
is a good thing (so far I don't see the point)?

   Martins Krikis, Intel Corp.

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



__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com