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

["John Hufferd" <hufferd@us.ibm.com>]

Lets see if we can avoid rehashing the issues around Boolean values.  This
has been gone over and over on this list, and does not need to be redone in
the last call.  Likewise the issues around Irrelevant.

There may or may not be value around the rest of your statements, but lets
not visit again  Boolean or Irrelevant .

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Martins Krikis <mkrikis@yahoo.com>@ece.cmu.edu on 04/23/2002 06:29:41 PM

Sent by:    owner-ips@ece.cmu.edu


To:    ips@ece.cmu.edu
cc:
Subject:    Re: iSCSI: Questions regarding text parameter 'Reject' and
       'Irrelevant'  usage




--- Julian Satran <Julian_Satran@il.ibm.com> wrote:
> Luben,
>
> I hope I cleared this.
> The may reject is only for the responder - the
> originator expects a good
> selection (according to the rules) or reject and
> will end the negotiation
> otherwise.

So let's suppose originator sent a key with a
list of values and received a Reject in response.

May the originator now send the same key again?

May the responder now offer the same key again?

Should the originator now send the same key again?

Should the responder now offer the same key again?

If they may/should and end up with another Reject
for the same key, may/should they do it again?

Assuming the key still hasn't been answered
with a non-reserved value, should it prevent
either  party from setting the T/F bits and thus
signaling readiness to end the negotiation sequence?

None of this is clear to me.

> That is the exact meaning of the text.  I did look
> it again over and I may
> add words but it seems that the text is clear as it
> is.

Here are a couple of things that I personally would
change:

  "All negotiations are stateless and explicit"

We all know they are far from stateless.

Explicit? Well, I would not allow boolean
responses to be omitted under certain conditions.
It just complicates the logic necessary to figure
out whether I can signal readiness to complete the
sequence or whether I'm missing some boolean response.

  "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 could be interpreted to say that one value
which cannot be used is enough to fail the whole
list. However, simply replacing "all" with "any"
won't make things clearer either. It would be
best to rewrite this part and to not mention the
previously undefined "options" either...

  "it MAY use the constant "Reject""

The MAY part is not helpful, as many have pointed
out. The less choices there are, the clearer things
will become and the less room for unexpected
surprises.

  "The selection of a value not admissible under
  selection rules is considered a negotiation
  failure and is handled accordingly"

In list negotiations the selection rule seems to
be "pick the first value that you support". If so,
then should responding with Reject, Irrelevant
or NotUnderstood be considered as "value admissible"
or "value not admissible"? I.e., by interpreting
the reserved words as not admissible, we could
already treat them as failure, yet we shouldn't...

"Handled accordingly" could provide a reference
to a better explanation of how the handling should
be done.

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

Let's take InitialR2T: function OR, default Yes.
Suppose the responder desires to turn this to No.
Suppose the offering party sends a No. Now, in the
absence of the knowledge of this offer of No, the
responder would be forced to stick with the default
Yes, right? So according to the quotation above,
the value to respond with is OR(No, Yes) = Yes.
This way we can't ever turn it to No, even if both
sides want it.

  "An offer of a value not admissible MAY..."

This is after boolean negotiations. Was it meant for
boolean or for anything? And what is "not admissible"?
Illegal value according to iSCSI standard or simply
unwelcome value by the receiver?

  "However the negotiation is not considered as failed
  if the response is Irrelevant"

Does it mean that it is considered as failed if the
response is Reject?

All the questions I asked above about Reject apply
again here... i.e., may/should each of the parties
offer this key again and should the current state
of this key allow signalling readiness to complete
the sequence?

Why not disallow Irrelevant to simplify things?
Make the response be mandatory. Let each side deside
for themselves whether it is of any use, but
negotiation should be completed for it.
We aren't considering any operational parameters
dependent on each other anymore, are we? So why
the Irrelevant---for being extra nice during security
negotiation?

Thanks for considering these concerns,

   Martins Krikis, Intel Corp.

Disclaimer: These opinions are mine and
            may not reflect those of my employer.


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