Re: iSCSI: Questions regarding text parameter 'Reject' and 'Irrelevant' usage

[Martins Krikis <mkrikis@yahoo.com>]

Yes, we have to make everything explicit. I was
actually a fairly happy camper and didn't worry
much about Reject or Irrelevant because I treated
such responses as finished negotitations (concluding
with default values) and didn't allow any repeats
of such keys. Julian's comment about allowing
previously Reject-ed keys to be repeated turned
everything upside down. The problem for me is not
so much that now infinite negotiations are possible,
but that now I feel that going the easy way and not
tolerating Reject-s (i.e., failing the whole
negotiation sequence) is somehow "wrong" and that I
should try to do more. But doing more means tracking
a lot more state for the key, especially in the
harder case where one does not keep resending this
key as if nothing happened, yet is ready to receive
it again, and is also happy to finish the sequence
despite this key ending in a Reject...

And the way I see it, the only reason to allow
repeating Reject-ed keys is to offer new 
number-ranges, because:

  if Reject was used for a list, and now the offering
  party has other values to offer, they should have
  been included in the first offer.

  If Reject was used on a string, and now there are
  other values to offer, perhaps the type should be
  "list" and all those values should have been sent to
  begin with (and I don't think we have parameters
  that would candidate for this).

  If Reject was used on a number, well, it should not
  have been outside the acceptable range to begin with
  and since the other side had some desired number it
  really should have applied the appropriate selection
  function to both numbers, resulting in a number...

  If Reject was used on a boolean, well, the offer
  should not have been anything except Yes/No to begin
  with.

And if the need for Reject is really to allow
multiple number-ranges to be negotiated in the
right order of preference. we're better off 
introducing lists of ranges.

Alright, I might be missing something here, but if
so, then I think the draft could include a
justification why allowing Reject-ed values to be
repeated is a valuable feature that cannot be easily
achieved by other means.

And whether I'm missing something or not, it should
say that Reject-ed keys ARE EXEMPT from the rule
that says that no side should attempt to negotiate
a parameter more than once during a negotiation
sequence...

I also don't see a reason to allow repeat of keys
answered with Irrelevant. If key B seems irrelevant
to the responder at some point, there must be some
already negotiated key A which makes B irrelevant,
and this is not going to change in this negotiation
sequence, so no point repeating B, it will still be
irrelevant. 

Yet, my current feeling is that just as with
Reject we are supposed to allow a repeat of keys 
that were called Irrelevant. That requires more 
state than tracking the other keys which end up 
with normal values.

The draft should tell whether "Irrelevant-ed"
keys are exempt from the "no-renegotiation rule"
or not. I am still not clear on the issue, despite
the fact that I tried to ask in my previous message.

NotUnderstood should not be repeated either (key
cannot become understood), but since keys I don't
understand will not prevent me from signalling
readiness to complete the sequence, I don't plan to
track the unknown keys for repetition, so I don't
care as much here.

Anyway, the point is that we could prohibit
repetitions of keys that are answered with Reject,
Irrelevant or NotUnderstood and that would already
make things simpler. Less state to track, no
possibility of infinite negotiations.

Thanks for considering this,

  Martins Krikis, Intel Corp.
Disclaimer: these opinions are mine and may not
            be those of my employer.


__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/