RE: iSCSI: keys/parameter dependence

["Julian Satran" <Julian_Satran@il.ibm.com>]

Bob,

Some comments in text.

Regards,
Julo


                                                                                                                                               
                      "Robert D.                                                                                                               
                      Russell"                 To:       Julian Satran/Haifa/IBM@IBMIL                                                         
                      <rdr@io.iol.unh.e        cc:                                                                                             
                      du>                      Subject:  RE: iSCSI: keys/parameter dependence                                                  
                                                                                                                                               
                      06/03/2002 04:41                                                                                                         
                      PM                                                                                                                       
                      Please respond to                                                                                                        
                      "Robert D.                                                                                                               
                      Russell"                                                                                                                 
                                                                                                                                               
                                                                                                                                               



Julian:

I must not be understanding what people mean by "batching",
a term that does not appear in the standard but which
is apparently not prevented by the standard.

So let me ask the question as follows:

In draft 12-95 section 4.2.1 "List negotiations" it says:

  "The responding party MUST respond with the same key and select first
  value that it supports (and is allowed to use for the specific
  originator) selected from the originator list."

As an aside, I believe the English in this should be changed slightly
(without changing the intent) to read:

  "The responding party MUST respond with the same key and the first
  value that it supports (and is allowed to use for the specific
  originator) selected from the originator's list."

+++ thanks - fixed +++

Also in draft 12-95 section 4.2.2 "Simple-value negotiations" it says:

  "For simple-value negotiations, the responding party MUST respond with
  the same key."

For both of these quotes I have the same question  -- when MUST this
response be given?  My interpretation is that it MUST be sent as soon
as possible (which would be on the next PDU sent by the responder
after receiving a PDU with C bit set to 0).  Is this correct?

+++ not necessarily - although this is the way many will do it +++

If my interpretation is not correct, then exactly when MUST the response
be sent -- i.e., how long can the responder delay before it MUST respond
to a key (obviously it must respond to the PDU, but I mean only the
offered keys here).

For example, having just received a large number of new offers in a PDU
with the C bit set to 0, can the responder then send back the appropriate
response PDU with no response keys, and continue doing so until
what?

+++ I think we don't need an additional rule for forcing a negotiation to
close>
We can leave this to implementers. It does not look like we will have an
interoperability issue here.
The initiator has the F bit to signal when he thinks he is done and I
assume it will give up
if the target keeps sending empty PDUs.
We may want to add a rule about not sending an excessive number of empty
PDUs when the received C is 0 "

+++


If the answer to this last example is "yes", then I have another:
When a responder gets a large numer of new offers in a PDU with the C
bit set to 0, can it send back no responses but rather a disjoint set of
new offers (i.e., keys that were not sent to it)?

+++ yes +++

Another way to ask my general question is the following -- can a
responder to an offer of a key=value delay sending its response to that
key indefinitely?

+++ not indefinitely +++

I believe this was discussed on the mailing list a long time ago,
and that my interpretation was confirmed then, but I cannot find
anything in the current wording of the standard which says this.

+++ I don't recall a discussion in this specific terms and in this respect
we never changed the draft +++

Regardless of which interpretation is correct,
it would be very helpful to state it in the standard --
otherwise we will certainly have some people choosing the other
interpretation -- it appears to be already happening!

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774