Subject: RE: iSCSI: Login Request error

From: [email-masked]
Date: Wed, 22 May 2002 11:20:45 -0600

Luben,

I have also pointed out some of these problems of clarity and consistancy before in shorter messages about the point. However, that hasn't resulted in a change to the draft so I went into more depth this time and fairly few people are responding on this point. Your response reads to me as either defensive or hostile which I don't understand since I think we want the same thing - for the negotiation text to become simpler and non-contradictory.

Sincerely,
Pat

-----Original Message-----
From: Luben Tuikov [mailto:[email-masked]]
Sent: Tuesday, May 21, 2002 7:20 PM
To: THALER,PAT (A-Roseville,ex1)
Cc: iSCSI; Parthi; Bill Studenmund; Mike Donohoe; Julian Satran
Subject: Re: iSCSI: Login Request error

Dear Pat,

You are not mentioning anything new, see this message
dated Apr 22, 2002:
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09751.html

Short message straight to the point is often more helpful.

Long time ago I envisoned there be a simple negotiation
procedure representable as a finite automata,
one for the target and another for the initiator,
both complementing each other (i.e. no contradictions).

I've referred in my past posts about this as ``decision
trees'' -- but no one paid attention.

Furthermore, I'd like those automata (describing the
negotiation process) to be deterministic -- i.e.
simple and no MAY's --- that would make them easily
predictable.

Regarging your post: thank you for agreeing, even in
parenthesis, that there is INCONSISTENCY in the draft.
This was the _main_ point, not quoting the draft.

Please also note that exactly the SAME problem exists
in section 4.2.2. (which you quote as solution).
And then you mention that there would be a loop (A-ha!).
Which is what I proved in my earlier post (to which you
replied). As you can see the logic (contradictory)
in both sections is the _same_.

Anyway, I've mentioned loops before, but no one
paid attention.

This message from Apr 22, 2002, cc to you from me,
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09751.html
shows the loop in negotiations, and mentions
decision trees (I've mentioned them elsewhere as well).

Anyway, the main point which has to be resolved
is inconsitencies (contradictions) in the draft.

Regars,
Luben

P.S. Another thing, which I've brought up before:
Using context free grammar (EBNF) for
the values of the login/text operational keys.
Q: if someone volunteers their time, would this
be accepted in the draft? Julian?

---

From: Martins Krikis <[email-masked]>
Date: Wed, 22 May 2002 11:59:18 -0700 (PDT)

Pat, Luben,

I think we're fighting an uphill battle here...

I've been complaining about some of the same
things, and, as Luben said, nobody cared. I get 
the feeling that there is a bigger wish to get the
draft "out" despite the ambiguities and problems in
both the negotiation protocol and its description,
than to change a single thing "this late".
I think there is also an assumption (that I don't
hold) that having choices in the negotiation 
protocol allows more freedom to implementations
and thus simplifies them.

Luben was asking whether EBNF would be used
if submitted. I personally doubt it, since 
perfectly reasonable regular expressions were 
dropped.

And there is probably little point asking the
phylosophical questions. I still don't see the
value of Irrelevant, allowing Reject-ed keys
to be renegotiated, allowing not Reject-ing
"inadmissible" values, allowing omission of
boolean values, base64 for anything but binary
strings, and many other "features". But I'll
probably receive email telling me to "move on"
just for mentioning this stuff here again...
Or the best explanation will be "we talked about
it here, but nobody objected too strongly".

Anyway, I'm behind you in your efforts and looks
like I should resume some of my own battles
(no-renegotiation rule unclear).

Good luck,

  Martins Krikis, Intel Corp.

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

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 22 May 2002 14:59:46 -0700 (PDT)

> than to change a single thing "this late".

I hope there isn't. If we let out a sucky protocol, we're stuck with it.

> and thus simplifies them.

I agree with you; let's make things explicit. It does make things easier.
:-)

> just for mentioning this stuff here again...

Well, I'm not trying to tell you to move on. :-)

We agree about base64 - it's great for binary strings, but not numbers.

I'm not sure about renegotiating REJECTED keys. I think it'd depend on
what the likely reasons for rejection are, and how likely they will be
different the second time.

I guess irrelevant makes sense for things like negotiating marker spacing
when you don't support markers.

> (no-renegotiation rule unclear).

:-)

Take care,

Bill

---

From: Martins Krikis <[email-masked]>
Date: Wed, 22 May 2002 16:55:37 -0700 (PDT)

--- Bill Studenmund <[email-masked]>

> different the second time.

Aha! :-) (Pat has actually already described almost
word by word what I was planning to say about any
reasons given, but I'll do the same anyway...)
So we have to look at what the reasons could be.

Junk value on binary key? Why was it sent in the
first place? Inadmissible numerical value, string
literal, or range sent? Again, why should the
responder cut any slack to such initiators and let
them try again? A list sent consisting of values 
that are not agreeable to the responder? If there
are more values that the originator could offer,
why weren't they included in the first request?
The only understandable reason I can imagine is
for trying out numeric ranges, one after another
in the order of preference. But if this is the
reason for allowing renegotiations, then we'd be
better off introducing lists of ranges, a thing that
has been discussed here, but was decided as yet
unnecessary. So this could not be the reason.

There is a somewhat risky use for sending
a junk value however---it can simply be used to let
the other side pick something w/o restrictions. But
there is no guarantee that the other side will not
Reject it and consider the whole negotiation
sequence failed with that (which in my understanding
(and I could dig up the relevant messages on the
list) is also a valid behavior).

> when you don't support markers.

But we don't have any dependencies between parameters
anymore, and that includes the marker-related keys.
It is quite possible to view them as independent.
It is alright to negotiate the marker interval but
not turn on the use of markers.
(By using 0 as a special interval value, we 
could also eliminate the boolean marker keys,
but that's unimportant).

Anyway, thanks for keeping the discussion up!

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