Subject: RE: iSCSI: keys/parameter dependence

From: "Julian Satran" <[email-masked]>
Date: Sat, 1 Jun 2002 09:14:25 +0300

I think we can leave it to individual keys and say only that dependencies 
and how to handle them are specified with keys.

Julo

[email-masked]
Sent by: [email-masked]
06/01/2002 03:02 AM
Please respond to pat_thaler

        To:     John Hufferd/San Jose/IBM@IBMUS, [email-masked]
        cc:     [email-masked], [email-masked]
        Subject:        RE: iSCSI: keys/parameter dependence

John,

The part that might cause interoperability problems is different 
interpretations of which parameters action or acceptance is dependent on
others. For instance, does the sentence mean that InitialR2T should be 
sent
before FirstBurstSize and that FirstBurstSize doesn't need a response when 

the response to InitialR2T was Yes? 

If the sentence is left in, then it should be clarified by adding 
something 
such as:
"The definition of a key specifies whether the key is dependent on any 
other 
keys."
and if any of our current keys are dependent, add to those keys
"This key is dependent on <key names>."
If none are currently dependent, it would be reasonable to add to 11 
"Currently,
no Login/Text Operational keys are dependent."

Pat

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Friday, May 31, 2002 2:38 PM
To: Martins Krikis
Cc: Mike Donohoe; [email-masked]'
Subject: Re: iSCSI: keys/parameter dependence

I do not see a problem with the Text, the previous key=value pairs are 
ones
that were in previous PDUs or key=value pairs that were scanned previous 
to
the current pair being scanned.  It is not clear that we have to write any
thing else to help people understand the concept of previous.  I think we
are straining at a nat here, and it is not worth the effort.

I do not see the problem.

.
.
.
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: [email-masked]

Martins Krikis <[email-masked]>@ece.cmu.edu on 05/31/2002 01:15:26 PM

Sent by:    [email-masked]

To:    Mike Donohoe <[email-masked]>, "[email-masked]'"
       <[email-masked]>
cc:
Subject:    Re: iSCSI: keys/parameter dependence

--- Mike Donohoe <[email-masked]> wrote:

> From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83):
>
> Whenever parameter action or acceptance are
> dependent on other parameters,
> the dependent parameters MUST be sent after the
> parameters on
> which they depend. If they are sent within the same
> command, a
> response for a parameter might imply responses for
> others.

I've been ignoring this paraghaph having been
convinced that there are no dependencies among
the operational parameters (those allowed to be
used in the operational stage of login), and that
any dependencies for security parameters would
be naturally observed by security protocols (i.e.,
first send me this, I'll send you that, now
send this, etc.).

However, I think you raised some good questions.
I think this paragraph should be removed.
Here are the reasons:

"(sent) after" isn't defined. It is unclear
whether "in higher numbered bytes within the
same PDU" qualifies as "after" or whether only
"in a PDU sent at a later time" would. It's
probably irrelevant, since due to the introduction
of the C-bit, parameters can be accumulated and
processed one "batch" at a time, without any
specific order within the "batch" and they will
quite likely not be processed PDU by PDU.
Therefore, the text about them being sent in
"the same command" is likely irrelevant, too,
since many implementation simply won't check that.

But what's really dangerous here is that an
implementation that perceives some parameters
as dependent may take the "might imply" text
as an endorsement for sending back less key=value
pairs than was received, which could make the
other side never commit due to missing responses.
We certainly don't want to allow for such a
non-interoperability in the specification.

So, could we please get rid of this whole
paragraph?

Thanks,

Martins Krikis, Intel Corp.

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

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

---

From: "John Hufferd" <[email-masked]>
Date: Sun, 2 Jun 2002 09:57:25 -0700

I think Robert  makes a good point here.

But let me also use this as a platform to again warn about last minute
changes to any spec that has been worked over for a long time with long
forgotten reasons for why decisions were made, even why compromises were
reached.

Changes made at this point should be the absolute minimum, and avoided if
at all possible.  The probability of unforeseen impacts are the greatest
for any changes made at the end of a design process.  And what we are doing
here is not an exception to this rule.

For us to have gone this far for this corner case, at this late stage,
demonstrates that many of us are permitting last minute flaps to push us
into acquiescence in order to get to last call.

We of course need to make changes to things that are broken, but sometimes,
if it only fails when someone does unnatural acts, then perhaps we should
not care to fix that in this go around, and instead let the vendors that do
that suffer from the consequences of pushing the envelope.  Any such
thoughts like this are contrary to the way engineers like us think,
however, we constantly live with this as our products get close to ship
time.

I am NOT advocating this as a blanket position, just a thought rigor that
we should each factor in.  I think we should also be thinking about what we
should put into the next revision of the spec., and perhaps start
accumulating various thoughts that might be approprate for that, and then
as we think of changes ask ourselves, if the new thoughts need to be in
this spec or in a follow on draft.

.
.
.
John L. Hufferd

"Robert D. Russell" <[email-masked]>@ece.cmu.edu on 06/02/2002 02:27:44
AM

To:    [email-masked]
cc:

Julian:

The following paragraph from an e-mail from Martins Krikis
made me realize that the definition of the new C bit
is not correct, because it goes much further
than is necessary to solve the "split key" problem,
and as a result, it opens up a whole new set of problems,
complicates what was previously a simple situation, and
breaks a lot of already running and tested code.

> since many implementation simply won't check that.

I don't believe the intention of the recent discussion
that led to the introduction of the C bit was, in fact,
to allow "batching" or to throw out "ordering" of the
sending of keys.  However, the definition in Draft 12-95
sections 9.10.2  and 9.11.2 seems to now allow batching:
(I agree with John Huffered that Martins' comments about
"ordering" are not correct in any case.)

Section 9.10.2 C (Complete) Bit:
"When set to 1, indicates that the text (set of key=value pairs) in
this Text Request is not complete (it will be continued on a
subsequent Text Request); otherwise, it indicates that this
Text Request ends a set of key=value pairs."

(Section 9.11.2 is the same, but with Response substituted for Request.)

The problem I see with this definition of the C bit is that
the sending side can force the receiving NOT to process
a PDU containing key=value pairs, even if all those key=value
pairs are complete within the PDU.  Therefore, the receiver
is forced to save this PDU (and any number of following PDUs)
until the sender finally sends C = 0.  In the worst case, the
sender could send one key=value pair per PDU with the C bit set
to 0 and the receiver could not reply to any of these until it
got one with C bit set to 1.
As the e-mail from Martins indicates, some people are already
taking this to mean that parameter negotiations will "normally"
be batched.  Up until the introduction of the C bit, PDUs and keys
in them were always processed as received, and most code already does
this, since it is the most logical and efficient way to do it.
We should still encourage this as the "normal" way of negotiating.

I believe the problem we were trying to solve by introducing
the C bit was the one where a key was split over a PDU boundary
-- we were not trying to redesign the negotiation mechanism,
which was discussed on the mailing list long ago and has been
working in a lot of running code for the past two plugfests.

Could we therefore please change the definition of the C bit in
section 9.10.2 to read:
"When set to 1, indicates that the text in this Text Request
contains a single key=value pair, and that pair is incomplete
within this PDU."

(Section 9.11.2 should have the same change, but with Response
instead of Request)

I believe this corresponds more closely with the description
in section 4.2 Text Mode Negotiation, where the C bit (flag) is
clearly tied to the idea of split keys only:
"Key=value" pairs may span PDU boundaries.  An initiator or target
having sent partial key=value text within a PDU indicates that more
text follows by setting the C flag bit in the Text Request or
Text Response to 1."

Perhaps an additional sentence could also be added to this:
"The following PDUs should only contain text that completes
the partial key=value text until after a PDU with C set to 1
has been sent, at which time new key=value pairs can be sent
in the next PDU."

I'm not happy about seeing such a major change (C flag bit)
introduced so late in the process to solve an "almost" non-existant
problem (split keys).  It is "almost" non-existand because of
the following considerations (some of which were already
mentioned on the list and are just summarized here):
During the login process, the PDU size is 8192 bytes.
Therefore, except for the long keys during negotiation
that follows a chosen AuthMethod, there is never a need to split
keys across pdu boundaries during login --
even if you negotiate every possible login key
(except those special keys that occur in security protocols)
to its maximum length, you do not reach the total of 8192 bytes.
It is not even close!  Therefore, there is no need for any
implication that the C bit should appear during this process.
When those long security keys are needed, the negotiation process is
in a 1 key over, 1 key back exchange mode, so there is no "batching"
possible and the split key should in fact be the only key in the pdu.
Finally, during text exchanges, there only 6 keys that can be
legally sent (plus the X-extension key): SendTargets, TargetName,
TargetAlias, TargetAddress, InitiatorAlias, and MaxRecvPDULength.
None of these can legally have a value greater than 255 bytes,
which is well less than the minimum PDU size (512 bytes).
So there is no need to split keys over boundaries during text
negotiation, except perhaps for the X-extension keys.
My proposed definition of the C bit as applying only to split keys
therefore only applies to X-extension keys during text negotiation.
Since we have had no experience with X- keys, and cannot forsee their
use, anything we introduce only for them should be the minimum possible.

In summary, I would like to see as little disruption as possible
to the key negotiation scheme which has been stable for a long time,
especially since anything we introduce will be needed only in very
limited circumstances.  I believe my modification to the definition of
the C flag accomplishes that, without introducing any new, false
perceptions about "batching" and "ordering".

Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

---

From: "Robert D. Russell" <[email-masked]>
Date: Sun, 2 Jun 2002 15:10:11 -0400 (EDT)

Hi Martins:

> first send me this, I'll send you that, now

However, there ARE dependencies between operational
parameters that cannot be ignored, such as the one Mike mentioned
-- FirstBurstSize and MaxBurstSize are dependent because of the
requirement in section 11.15: "FirstBurstSize MUST NOT exceed
MaxBurstSize."  See my e-mail response to Mike for details
on that dependence.  I am also sending a following e-mail
that details 3 other dependencies.

> "in a PDU sent at a later time" would.

I don't see this, and I agree with John Hufferd's response
to this that "previous" is obviously "previous", whether in
the previous PDUs (because the current PDU was delivered
after them) or in the same PDU (because key=value pairs
are naturally scanned from the beginning of a PDU's data segment,
and if nothing else, pairs had to be put into the data segment
in that order, and delivered on the wire in that order).
This is a non-issue.

> It's

I don't see this either.  Nowhere does the newly added text
describing the C-bit say anything about doing away with the
specific order of the key=value pairs within the "batch".
Why should it -- even if you don't process PDU by PDU you still
have to process batch by batch, a batch still has to be scanned
to find key=value pairs, and the natural way to scan is from the
beginning of the batch, since the next key starts after the
delimiter of the previous key in the batch.
This is also a non-issue.

> since many implementation simply won't check that.

"command" should simply be replaced by "batch" or,
to be more consistent with the rest of the wording in the
standard, with "set of key=value pairs".
However, see my earlier e-mail to Julian stating my
concerns over the use of the C-bit for "batching".

> non-interoperability in the specification.

Certainly not, and nowhere can I find anything in the standard
that implies responses can ever be omitted.  On the contrary,
there are several places where it says you MUST always respond.
For example, in section 4.2 on Text Mode Negotiation it says:
"A key not understood by the responder may be ignored by the
responder without affecting the basic function.  However, the
Text Response for a key not understood MUST be Key=NotUnderstood."
And in section 4.2.2 for simple-value negotiations it says
"For simple-value negotiations, the responding party MUST respond
with the same key."
The only time responses are optional are the 2 special-case
Boolean negotiations detailed at the end of section 4.2.
At no other time can responses be omitted.
This is also a non-issue.

> So, could we please get rid of this whole

I do not see how we can get rid of this paragraph.
However, perhaps it could be worded better to make it clearer
without changing its intent.

Best,

Bob Russell
InterOperability Lab

---

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Mon, 3 Jun 2002 11:18:54 -0600

My comments are inserted with my initials. Pat

-----Original Message-----
From: Robert D. Russell [mailto:[email-masked]]
Sent: Sunday, June 02, 2002 12:10 PM
To: [email-masked]
Subject: Re: iSCSI: keys/parameter dependence

<snip>

<PAT> This is an excellent example of why it is necessary 
to state explicitly where (if anywhere) one is required
to send parameters in a specific order. Requiring that
x not exceed y is equivalent to requiring y to be greater
than or equal to x. It doesn't imply the order. In any case, 
as long as each side independently ensures that the maximum 
value it will accept for FirstBurstSize does not exceed
the maximum value it will accept for MaxBurstSize, it doesn't
matter which is negotiated first. The relationship between
these two values does not imply an order and if we want to
force an order it will need to be done explicitly.

<snip>

<PAT> Then the sentence: "If they are sent within the same command, a
response for a parameter might imply responses for others." should
be altered. "A response for a parameter might imply responses for
others" appears to some readers to say that those responses may 
be omitted since they are already implied though to other readers
it just means that the earlier response limits the response to
the later key.

<PAT> If the first sentence of the paragaph is to stay, then 
one needs to explicitly list the parameter ordering requirements
because dependency order is not clear. The second sentence
should be deleted as it doesn't say anything useful. It is 
clear that the response to earlier parameters limits the range
of responses to later parameters regardless of whether they 
are in the same PDU or not.

Regards,
Pat

---

From: Martins Krikis <[email-masked]>
Date: Mon, 3 Jun 2002 14:22:57 -0700 (PDT)

> parameters that cannot be ignored, such as the one

I should have been more precise. I meant "order
imposing dependencies". You might say "is there
any other kind?", and I would say "yes" and be very
sorry for not CC-ing you on my previous post sent
to the list. I'm sorry already.

> on that dependence. 

I saw it. I consider it unbelievably ugly to have to
look at the values in order to figure out ordering
requirements. I prefer ignoring ordering completely
and check for overall consistency before commit.

> after them) or in the same PDU 

Just because your interpretation matches John's
doesn't mean that it has been unambiguously defined
and that everybody will see it that way. The
suspicion that may be, just may be, "after" meant
"in a later PDU" was made stronger by the sentence
that talked about keys sent in the same "command"
(i.e., PDU).

> (because key=value
> pairs

Not if we don't have a C-bit and have to start
from the end to see if the last pair is split or full.

And natural to one might be unnatural to another.

> in that order, 

What order? Previous coming before after?
That order only appears once I've put something
in the data-segment, and I could put pairs
in there in any way I want...

> This is a non-issue.

It's a good thing we got it clear what "after"
means, now I'll just ask why is it important...

> specific order of the key=value pairs within the

Nowhere does it say anything about the order.
I may prefer to process all booleans first, for
example. I may even find each pair going backwards
in the PDU...

> have to process batch by batch,

batch by batch, yes, absolutely.

> a batch still has to
> be scanned
> beginning of the batch, 

not necessarily.

> since the next key starts
> after the

or the previous value (or pair) ends 
before the delimiter of the next key...

> This is also a non-issue.

As long as somebody doesn't impose processing
order on my implementation.

> standard, with "set of key=value pairs".

Why does it even matter whether a key has been
sent in the same "batch" or even the same PDU as
another one? Either the value of one may imply
the value of another, or not. But why does this
sentence single out keys sent in the same "command"
("batch", whatever)? 

> concerns over the use of the C-bit for "batching".

I've seen it and still think that batching of keys
is a great way to simplify their processing.

> that implies responses can ever be omitted.

Alright. Then let's just get rid of this sentence
because it does make it sound like may be, just may
be, responses can be omitted when they are already
implied.

> This is also a non-issue.

I hope so, but the sentence worries me.

> without changing its intent.

But what is the intent? That ordering of keys
matters? I don't see it as a good feature, if so.

Or that the values of some keys "imply" the
values of others? They may be putting restrictions
on them, but why only if in the same "command"
("batch", whatever)? Why not always? Why have this
observation here and in the form that makes one
doubt whether responses are always mandatory?

            be those of my employer

---

From: [email-masked]
Date: Tue, 4 Jun 2002 08:42:03 -0600

Also,

Since discovery sessions cannot do IO... then should Initial_R2T,
BidiInitialR2T, ImmediateData, MaxOustandingR2T, DataPDUInOrder,
DataSequenceInOrder only be valid for normal sessions.

Kevin Lemay

-----Original Message-----
From: Robert D. Russell [mailto:[email-masked]]
Sent: Tuesday, June 04, 2002 1:14 AM
To: Julian Satran
Cc: [email-masked]
Subject: RE: iSCSI: keys/parameter dependence

Julian:

I have found the following dependencies between keys in draft 12-96,
and would ask other people on the mailing list to contribute others
they have found so we can all be aware of the complete set.

There seem to be very few dependencies, which I believe is a credit
to a clean, orthogonal design.

With a bit of work, we could probably get rid of all the dependencies
between the OFMarkInt (IFMarkInt) and OFMarker (IFMarker) keys, perhaps,
as suggested by Martins Krikis, by eliminating the OFMarker (IFMarker)
key and substituting a default (and response) value of 0 for the
OFMarkInt (IFMarkInt) to mean "no markers in that direction".

This would also eliminate the need for a "Reject" reply to an OFMarkInt
(IFMarkInt) offer.

"Meaningful" dependencies (i.e., those that cannot be ignored because
they effect operation):

1.  Between FirstBurstSize and MaxBurstSize
      Section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize."

2.  Between OFMarkInt (IFMarkInt) and OFMarker (IFMarker)
      Section A.3.2: "When the interval (in an OFMarkInt (IFMarkInt)
      offer) is unacceptable the responder answers with "Reject".
      Reject is resetting the marker function (i.e., OFMarker
      (IFMarker)) in the specified direction (Output or Input) to No."

3.  Between SessionType and MaxConnections
      Section 11.22: "The discovery session implies MaxConnections = 1
      and overrides both the default and an explicit setting."

"Trivial" dependencies (i.e., those that only allow the option of
replying with "Irrelevant" instead of a normally selected value, and
therefore can be ignored).

1.  Between FirstBurstSize, InitialR2T, and ImmediateData
      The table in section 11.12 implies that the combination
      InitialR2T=Yes and ImmediateData=No allows the response
      FirstBurstSize=Irrelevant.

2.  Between OFMarker (IFMarker) and OFMarkInt (IFMarkInt).
      Sections A.3.1 and A.3.2 imply that OFMarker=No (IFMarker=No)
      allows the response OFMarkInt=Irrelevant (IFMarkInt=Irrelevant).

Bob Russell
InterOperability Lab

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 4 Jun 2002 20:06:55 +0300

Bob,

Thanks.  That matches my list although I have a somewhat different 
approach to some of them.

1. FirstBurstSize - MaxburstSize is not exactly a dependency as it means 
only that the negotiated values have to relate to each other
at commit time or you have negotiation failure (login failure)

2 & 3 as above.

I think tact we may want to say somewhere that value consistency to the 
rules is to be determined a the end of the negotiation.

Thanks,
Julo

"Robert D. Russell" <[email-masked]>
06/04/2002 11:13 AM
Please respond to "Robert D. Russell"

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        Subject:        RE: iSCSI: keys/parameter dependence

Julian:

Bob Russell
InterOperability Lab

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 4 Jun 2002 20:19:18 +0300

Probably - but if you are tolerant you can answer them with Irrelevant.

Julo

[email-masked]
06/04/2002 05:42 PM
Please respond to kevin_lemay

        To:     [email-masked], Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        Subject:        RE: iSCSI: keys/parameter dependence

Also,

Kevin Lemay

-----Original Message-----
From: Robert D. Russell [mailto:[email-masked]]
Sent: Tuesday, June 04, 2002 1:14 AM
To: Julian Satran
Cc: [email-masked]
Subject: RE: iSCSI: keys/parameter dependence

Julian:

Bob Russell
InterOperability Lab

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 4 Jun 2002 20:19:18 +0300

I have one comment regarding to batching.

Batching is not related to the C-bit. C-bit is meant to simplify spanning 
over PDU boundaries.
Batching can be done with the previous structure as well - there is a lot 
you can do with an 8k block!

Julo

06/04/2002 09:46 AM

        To:     Martins Krikis <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: iSCSI: keys/parameter dependence

Martins:

Comments below on all your e-mails in this one reply.

> As to "running and tested",
> I don't think many people have encountered split
> PDUs in operational stage or FFP Text negotiations
> yet.

Agreed.

> Those, who prefer the "batch-processing" approach
> fought for the C-bit, so I would say that it was
> introduced in order to allow it.

I missed that point earlier.

> Regarding ordering, however, it had never been
> defined, and I would hate to see it introduced.

It was defined before draft 8, but was taken out when that
draft came in.  Unfortunately, I did not take it out of
my memory.  I agree that it should not be reintroduced.

> In my opinion, it is best to treat all operational
> parameters as independent and negotiate them as
> such.

Agreed.

> Just before the commit
> (i.e., turning on the T or F bit), one can do an
> all-encompassing consistency check and reset
> the negotiations if the values violate the laws
> imposed on them, or offer some more keys to solve
> any such problems, if this is still possible.

What you are saying seems to imply that C=0 does NOT
require the receiver to reply to keys received up to that point
-- it could send another empty PDU, or more likely, it could send
new offers of its own.  I agree that there is nothing in the draft
that says when replies to keys should be sent, only that they
MUST be sent (sometime).

For example, consider a login negotiation of operational parameters
in which the initiator sends a login pdu containing key=value offers
and the C bit 0.  The target responds with a login response pdu
containing key=value offers of its own (offering different keys)
but no replies to any of the offers it received in the login.
The initiator can then reply to the target's new offers, or it
can decide not to reply, and instead send additional new offers
or even an empty pdu, (C bit 0 in both alternatives).  And now
the target could do as it did before, not replying to any offers
but either sending back new offers or sending back an empty login
response pdu (again C bit 0 in both alternatives).  This could go
on indefinitely.

It would seem that the initiator might try to force replies by
setting T=1 to force an end-of-stage transition.  However, the target
can refuse to make the transition and can reply with T=0 and still
no replies to the keys it was offered.

This is admittedly a rather far-out example, because presumably both
initiator and target want to end the negotiations as soon as possible.
My point only is that I do not see anything in the draft that says
when the replies to keys have to be sent, only several references
that there MUST be a reply to every key offered (eventually).

Thoughts, comments?

> I could even imagine negotiations
> succeeding but laws
> (e.g. FirstBurstSize <= MaxBurstSize) not being
> broken when sending data... OK, the last thing
> might technically be forbidden at the moment
> but it is not that unreasonable. It would be
> something like
> FirstBursSize = min(FirstBurstSize, MaxBurstSize)
> done after the negotiation end, and then you can
> forget about dependencies. I think it is way
> easier than worrying about key ordering every
> time something is sent or received.

The dependency can be accounted for when generating the reply.
For example,

reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize)

That way nothing is broken when sending data.

> And how many instances of TargetName and TargetAddress
> can the SendTargets command provoke from the other
> side? I think it can easily overflow the 8192 bytes.

Yes it can, but there was already a mechanism in place to deal
with this.  In fact, this brings up an interesting point.
Presumably the C bit has to be used with replies sent to
SendTargets (or any other offer that might generate a long reply),
since the C bit is in the Text Response PDU used to send these replies.

Refering to sections 9.10.2 and 9.10.4:  If the target generating a
long reply has more text to send than will fit in one PDU, then it
should indicate this by setting C = 1.  Setting C = 1 also forces F=0,
and this in turn forces the Target Transfer Tag to be something
other than 0xffffffff.  When there is no more text to send,
the target sets C = 0 and F = 1 and TTT=0xffffffff in the last
text response pdu it sends to the initiator.  There is no
situation in which C = 1 and F = 1 can occur (since this is
explicitly stated in 9.10.2 as being an error), nor is there a
situation in which C = 0 and F = 0 should occur (because C = 0
means "I'm done sending stuff" and F = 0 means "I'm not done sending
stuff").

Is this the way you interpret the merging of the C bit with the
long text reply mechanism?  If there is a consensus on this,
perhaps the wording in the draft in section 9.10.4 should include
the (required) settings of the C bit whenever it mentions the
corresponding settings of the F bit and TTT field.

> and check for overall consistency before commit.

You are correct, the values can be figured out without
resorting to an ordering -- my mistake.

> Nowhere does it say anything about the order.

Agreed.

> So, are you really proposing a requirement that
> we must look at the values in order to figure out in
> which order to send keys? That is so UGLY, it is
> hard to believe that this is happening.

Please forget I even suggested it.

> > The existence of a dependency between OFMarker and
> > OFMarkInt, and between
> > IFMarker and IFMarkInt, is implied by the statements
> > in section A.3.2:
> > "When the interval is unacceptable the responder
> > answers with
> > "Reject".  Reject is resetting the marker function
> > in the spcified
> > direction (Output or Input) to No."
>
> No it isn't. IMO, it is resetting the marker interval
> to its previous value, which is likely the default
> value. I believe it's perfectly legal to negotiate
> the marker interval but to not turn on marker use,
> or to turn on the use but stay with current (default)
> values for the interval. If one side can't  tolerate
> the other's  Reject (i.e., can't live with the
> default value), it is welcome to bail and try next
> time w/o markers. BTW, we could use 0 here as a
> special value, meaning that markers are not in use,
> then we wouldn't need the boolean keys for
> markers.
>
> > This last sentence should probably be reworded to
> > say:
> > "A response value of "Reject" to an OFMarkInt
> > (IFMarkInt) key resets the
> > corresponding OFMarker (IFMarker) key value to
> > "No"."
>
> No, thank you. I would prefer if Reject meant the
> same as with the other keys, i.e., negotiation
> failed for this key, let's stick with the old
> value, or bail if we must.

Either the sentence needs to be reworded so it is proper English
or it should be taken out of the draft.  I take it you are advocating
its removal?

Bob Russell

---

From: Martins Krikis <[email-masked]>
Date: Tue, 04 Jun 2002 14:24:12 -0500

Robert,

I'm cutting text out to keep it shorter...

> that says when replies to keys should be sent, only that they

Yes. The other side cannot be forced to send anything.

> that there MUST be a reply to every key offered (eventually).

Yes, there is the possibility that one or both sides don't want
to commit the negotiation and keep ping-ponging empty PDUs. Thus,
implementations will likely be counting such request-response rounds
and have some threshold value for how many times this can go on...

> That way nothing is broken when sending data.

except that reply.MaxBurstSize may have to be substituted by
current.MaxBurstSize or offer.MaxBurstSize or something like that...
i.e., there can be chicken-and-egg problems, I think. I prefer
negotiating each key individually, according to its type, allowed
values, desired values, who may send it at the concrete stage
of the negotiations, etc. I am not fond of the idea that it may
be necessary to look at the (current or future) values of other keys
in addition to what already has to be done for each key.

> since the C bit is in the Text Response PDU used to send these replies.

Yes, it should. There was just an example of "long responses" in 9.10.4,
but some people understood it to mean that empty PDUs going in the
other direction are mandatory. For SendTargets there isn't much
else the initiator can send anyways (?). Well, the empty PDUs
of 9.10.4 weren't mandated yet when the discussions for C-bit
started, but that's basically what the C-bit mandates. Would
be nice to add it to the example of 9.10.4, too.

> other than 0xffffffff.  

Yes.

> When there is no more text to send,
> text response pdu it sends to the initiator. 

C = 0 yes, but F and TTT only if initiator set F and if the
target is ready to commit. It may still be missing values
from initiator, or just taking a break (:-)) for a couple 
request-response rounds.

> There is no
> explicitly stated in 9.10.2 as being an error), 

Yes.

> nor is there a

This can occur. C=0 just means "I'm done with this "set of keys" ("batch"),
now I'm willing to listen what you may have to say". It does not imply
F=1, as the target may not be ready to commit yet. In fact, initiator
need not have set F yet, so in fact target may be forbidden to set it.

> long text reply mechanism?  

C-bit now IS the "long login/text request/reply mechanism".

> If there is a consensus on this,

Perhaps something can be added, especially to the example there.

> or it should be taken out of the draft.  I take it you are advocating

Oops. My mistake. I hadn't even read the sentence about "Reject"
that is in the draft currently. I have no objections to English
there, but I don't like that Reject is "resetting the marker function
to no", since that certainly introduces a dependency, and I understand
that it is legal to treat the other Rejects as "stick to the old value".,
I would like this Reject to allow the same interpretation, i.e., not
require to touch any other keys immediately. Using 0 as a special value 
for intervals also has a drawback---it can be a value "out of range", 
to be returned. Suggestions?

Disclaimer: my opinions, not necessarily Intel's.

---

From: [email-masked]
Date: Tue, 4 Jun 2002 14:04:35 -0600

Robert,

Responding to:
This does, however, bring up another question.  When the C bit is 0,
the receiver of that PDU does not seem to be required to send replies
to the keys it has received up to that point -- it could send
another empty PDU, or more likely, it could send new offers of its
own.  It seems to me that there is nothing in the draft that says
when replies to keys should be sent, only that they MUST be sent.

There wasn't any requirement for how soon one responded to keys before
the C bit was created. I don't think any such requirement is needed.
One makes ones offers. If they haven't been responded too by the end
of the negotiation session - e.g. the target sets the T bit without 
having sent responses to all the Initiator's keys or the target times
out waiting for the Initiator to respond to keys it sent - then the
negotiation failed and the side that detected it should close the
connection.

Regards,
Pat

---

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Tue, 4 Jun 2002 18:23:14 -0600

Bob,

I agree. There is no requirement to respond to the keys received in the
last batch in your next batch. 

Pat

-----Original Message-----
From: Robert D. Russell [mailto:[email-masked]]
Sent: Monday, June 03, 2002 11:45 PM
To: Robert Snively
Cc: [email-masked]
Subject: RE: iSCSI: keys/parameter dependence

Robert:

You are, of course, absolutely correct.  There is no mention
in the current drafts of "order" applied to the processing of keys
-- there used to be such an "order" requirement, but that went out
when draft 8 came in, and is now ancient history.

My apologies to the entire list for mistakenly bringing it back.

I do, however, have a question about one small point in what you said:

> If you want to order processing, you would
> have to send them one at a time without the C bit set.

Is this true?  When the C bit is not set, there appears to be
no requirement in the standard that the receiver is forced to
reply to the keys it has received at that time -- it MUST reply
to every key eventually, but just having the C bit = 0 does
not seem to require it to reply then -- it could send an empty
reply PDU, or could offer new keys of its own at that time
and delay responding to anything until "everything is on the
table".  Comments/corrections please.

Thanks
Bob Russell

> Picking up on this in the middle of a thread, I
> find the following reply from Bob Russell
> interesting:
>
> > > It's
> Skimming over rev 12, I have not found the word "order"
> applied in the context of processing a string of
> key=value pairs.  While they
> must clearly be parsed linearly, it is perfectly reasonable
> to process the parsed values in any order, or even in
> a vendor-specific order than makes sense to a particular
> target.  That is why key=value pairs are used in the
> first place, so that one does not have to worry about
> ordering.  In this context, batching would be normal behavior
> and out of order processing within a batch would also be
> normal behavior.  If you want to order processing, you would
> have to send them one at a time without the C bit set.

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 5 Jun 2002 19:46:07 +0300

There was never a requirement to respond immediately.

Julo

"THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Sent by: [email-masked]
06/05/2002 03:23 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

        To:     "Robert D. Russell" <[email-masked]>, Robert Snively 
<[email-masked]>
        cc:     [email-masked]
        Subject:        RE: iSCSI: keys/parameter dependence

Bob,

Pat

-----Original Message-----
From: Robert D. Russell [mailto:[email-masked]]
Sent: Monday, June 03, 2002 11:45 PM
To: Robert Snively
Cc: [email-masked]
Subject: RE: iSCSI: keys/parameter dependence

Robert:

Thanks
Bob Russell

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 5 Jun 2002 19:22:39 +0300

Jeff,

We had a statement about dependencies that we now deferred to individual 
keys (as it is explicit in the security exchanges).
For operational parameters we have 2 choices:

State the dependency and force ordering
Take all values and check before committing 

Taking into consideration that a negotiation is atomic - i.e., failure 
must return ALL values to the status before and as such we have to keep 
them
and that most of the dependencies are of a kind that can be checked at the 
end and rather trivial it looks to me that 2 is slightly better than 1.

Julo

Jeff Fellin <[email-masked]>
06/04/2002 08:36 PM
Please respond to Jeff Fellin

Julian,
I never saw any place in the document when or if consistency was done. By 
your
proposing a final last stage consistency check to end the negotiation 
appears
to be adding semantics that are not present to eliminate the issue of 
parameters
having consistency requirements. When the definition of the parameters, 
for example
FirstBurstSize MUST NOT exceed MaxBurstSize implies that when 
FirstBurstSize is received
the value CANNOT exceed the current value of MaxBurstSize, the the value 
of MaxBurstSize
at some later point in time. The state transistions for Login do not 
mention this
overall parameter value consistency check, so how can you state it was 
already present.

Jeff Fellin
Bell Labs

> From [email-masked] Tue Jun  4 13:08:42 2002
> X-Authentication-Warning: ece.cmu.edu: majordom set sender to 
[email-masked] using -f
> To: "Robert D. Russell" <[email-masked]>
> Cc: [email-masked]
> From: "Julian Satran" <[email-masked]>
> Date: Tue, 4 Jun 2002 20:06:55 +0300
> X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a 
|January 7, 2002) at
>  04/06/2002 20:06:56,
>                Serialize complete at 04/06/2002 20:06:56
> Content-Type: multipart/alternative; boundary="=_alternative 
005D5E07C2256BCE_="
> Sender: [email-masked]
> Precedence: bulk
> X-Lines: 192
> Content-Length: 7481
> 
> Bob,
>

---

From: [email-masked]
Date: Wed, 5 Jun 2002 12:41:32 -0600

Julian,
 
Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate
but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner 
might originate some of the keys it had prepared but hadn't yet sent.
 
With the C-bit, a device can prepare a batch of keys with out regard to their size because the device
can ensure that they can be sent in multiple PDUs if necessary without the partner having an 
opportunity to originate keys in between.
 
The C-bit releaves the size constraint on batching offers.
 
Regards,
Pat 
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 04, 2002 10:19 AM
To: Robert D. Russell
Cc: [email-masked]; Martins Krikis; [email-masked]
Subject: Re: iSCSI: keys/parameter dependence

Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries. 
Batching can be done with the previous structure as well - there is a lot you can do with an 8k block! 

Julo 

06/04/2002 09:46 AM 

Martins:

Agreed.

Agreed.

Thoughts, comments?

Agreed.

Bob Russell

---

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Wed, 5 Jun 2002 14:11:34 -0600

This matches my understanding of what we were doing
with the C bit and it is consistant with the C bit
text in the draft.

Pat

-----Original Message-----
From: Martins Krikis [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 12:33 PM
To: Julian Satran
Cc: [email-masked]
Subject: Re: iSCSI: keys/parameter dependence

--- Julian Satran <[email-masked]> wrote:

> Almost everything is correct - except the mechanism
> for 
> Very-Long-responses - (TTT).
> This is different than the spanning mechanism (C-
> bit) in the sense that 
> has in theory no bounds (it was devised mainly for
> SendTargets but can be 
> used by any mechanism that has to send a lot of data
> - not negotiations).

Hmm, let me verify that I'm understanding this...

Let's suppose the following scenario:

A target is planning to send a very long response
(exceeding the mandatory buffering capabilities
of the other side) to a TextRequest that contained
the SendTargets key. This is legal, 
because it is not a negotiation, right? 

Let's suppose the text it is sending
will get broken in m TextResponse PDUs. 
For any of these PDUs, if the key=value pairs fit
completely (i.e., including the terminating '\0'),
and if the target doesn't mind the possibility
that the initiator may send some data back
(for example, do a little negotiation in parallel
with hearing what SendTargets will return...),
then it need not set the C-bit. Correct?

But it is also permissible to set the C-bit, 
since the target may not consider itself as 
"being done with this set of keys". Right?

If, however, in some PDU the last key=value
pair is split (i.e., will continue in the next
PDU), then it MUST set the C-bit, because
such a PDU cannot possibly "end a set of keys".

Can anybody comment on this understanding, please?

Applying this understanding to the example in
section 9.10.4, I can conjecture that the C
bit may or may not be set; it depends on whether
<part x> contains only complete (with '\0' at the 
end) pairs or not, and possibly on target's
preferences. The PDUs travelling in the other
direction need not necessarily be empty, unless
the C-bit in the preceding PDU forces them to be.
Is this true?

Many thanks in advance,

Disclaimer: these are my own opinions and are
            not necessarily Intel's opinions.

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 6 Jun 2002 06:55:47 +0300

As I pointed out earlier - you can batch all your keys but some 
certificates in 8k!
It was never forbidden nor mandated.

Julo

[email-masked]
06/05/2002 09:41 PM

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc:     [email-masked], [email-masked], [email-masked]
        Subject:        RE: iSCSI: keys/parameter dependence

Julian,
 
Batching is related to the C-bit. Before the C-bit, a device could prepare 
a batch of keys to originate
but they had to fit within the PDU because, if the keys extended beyond a 
PDU, the device's partner 
might originate some of the keys it had prepared but hadn't yet sent.
 
With the C-bit, a device can prepare a batch of keys with out regard to 
their size because the device
can ensure that they can be sent in multiple PDUs if necessary without the 
partner having an 
opportunity to originate keys in between.

Regards,
Pat 
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 04, 2002 10:19 AM
To: Robert D. Russell
Cc: [email-masked]; Martins Krikis; [email-masked]
Subject: Re: iSCSI: keys/parameter dependence

Julo 

Martins:

Agreed.

Agreed.

Thoughts, comments?

Agreed.

Bob Russell

---

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 6 Jun 2002 11:07:53 -0400 (EDT)

Julian:

I came across another dependency in draft 12-96 (but it has been
in the drafts for some time):

The end of section 11.20 says:

   "If ErrorRecoveryLevel is not 0 and if DataSequenceInOrder is set to
   Yes, a target may retry at most the last R2T, and an initiator may at
   most request retransmission for the last read data sequence.
   MaxOutstandingR2T MUST be set to 1 in this case."

It is unclear to me from reading this just what the "in this case"
refers to -- does it mean:

1) if MaxOutstandingR2T is not 1 then the target may not retry and
   the initiator may not request retransmission.

or

2) the combination ErrorRecoveryLevel > 0 and DataSequenceInOrder=Yes
   requires MaxOutStandingR2T=1.

If the first interpretation is correct, then this is not really a
dependency between the keys, but a subtle restriction on behavior
from a certain combination of keys.

If the second interpretation is correct, then this is a dependency
between keys.

Whichever interpretation is correct, I would suggest that the statement
in section 11.20 be reworded to make the interpretation unambiguous.

Thanks,
Bob Russell

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 7 Jun 2002 00:12:17 +0300

Pat,

I wonder what I said to warrant such a long answer.
I just pointed out that the C bit should not be viewed as related 
(directly) to batching.

Julo

06/06/2002 06:54 PM

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc: 
        Subject:        RE: iSCSI: keys/parameter dependence

Julian,
 
Then we shouldn't have added the C bit at all. One doesn't need it to 
indicate that a key-value isn't complete and one certainly doesn't need it 
for security negotiation where there is already a fairly lock step process 
for the certificate exchange.
 
The arguments people used for adding it were that they wanted to be able 
to batch offers larger than a PDU without worrying about length. I agree 
that isn't necessary today for any of the standard keys.
 
During login one can send all the standard keys in a single 8k PDU. During 
FFP, the only standard negotiated key exchanged is MaxRcvPDUDataSize. One 
could respond to a SendTargets with keys spread over multiple PDUs without 
an issue.
 
The current places where C helps are:
Implementation doesn't support 8k transmit PDU size - the negotiation 
default of 8 k is for the size PDU one supports receiving. An 
implementation might chose to only send a much shorter PDU and then its 
keys would not al fit in a single PDU. I find it difficult to imagine 
someone designing an implementation that creates a long batch of keys and 
then sends it in multiple short PDUs when it could send it in one PDU, so 
this doesn't seem like a very good reason to have the C bit.
 
Anticipation of many more or longer standard keys in the future so that 
they don't all fit in 8k.
 
Anticipation of more FFP negotiations so that FFP offers don't all fit in 
a single PDU when PDU size might be as small as 512.
 
Support for vendor specific extension keys that are more then 8 k in login 
or more than MaxRcvPDUDataSize in FFP.
 
Pat
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 8:56 PM
To: [email-masked]
Subject: RE: iSCSI: keys/parameter dependence

Julo 

[email-masked] 
06/05/2002 09:41 PM 
        
        To:        Julian Satran/Haifa/IBM@IBMIL, [email-masked] 
        cc:        [email-masked], [email-masked], 
[email-masked] 
        Subject:        RE: iSCSI: keys/parameter dependence 

Julian, 

  
  
Regards, 
Pat 
  
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 04, 2002 10:19 AM
To: Robert D. Russell
Cc: [email-masked]; Martins Krikis; [email-masked]
Subject: Re: iSCSI: keys/parameter dependence

Julo 

Martins:

Agreed.

Agreed.

Thoughts, comments?

Agreed.

Bob Russell

---

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Thu, 6 Jun 2002 15:36:33 -0600

Julian,
 
And I pointed out that the arguments for it were related to batching (even if current implementations of 12 don't send a multi-PDU batch) and C bit is unnecessary to deal with PDU spanning in the absence of batches. You still didn't agree so I explained my reasoning at greater length (though it doesn't seem to have done any good except to get you to add "(directly)" to the statement). I don't understand what you think justifies the addition of the C bit if it isn't to support batching.
 
The C bit should be viewed as related directly to batching.
 
Pat
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, June 06, 2002 2:12 PM
To: THALER,PAT (A-Roseville,ex1)
Cc: [email-masked]
Subject: RE: iSCSI: keys/parameter dependence

Pat, 

I wonder what I said to warrant such a long answer. 
I just pointed out that the C bit should not be viewed as related (directly) to batching. 

Julo 

06/06/2002 06:54 PM 

Julian, 
  
Then we shouldn't have added the C bit at all. One doesn't need it to indicate that a key-value isn't complete and one certainly doesn't need it for security negotiation where there is already a fairly lock step process for the certificate exchange. 
  
The arguments people used for adding it were that they wanted to be able to batch offers larger than a PDU without worrying about length. I agree that isn't necessary today for any of the standard keys. 
  
During login one can send all the standard keys in a single 8k PDU. During FFP, the only standard negotiated key exchanged is MaxRcvPDUDataSize. One could respond to a SendTargets with keys spread over multiple PDUs without an issue. 
  
The current places where C helps are: 
Implementation doesn't support 8k transmit PDU size - the negotiation default of 8 k is for the size PDU one supports receiving. An implementation might chose to only send a much shorter PDU and then its keys would not al fit in a single PDU. I find it difficult to imagine someone designing an implementation that creates a long batch of keys and then sends it in multiple short PDUs when it could send it in one PDU, so this doesn't seem like a very good reason to have the C bit. 
  
Anticipation of many more or longer standard keys in the future so that they don't all fit in 8k. 
  
Anticipation of more FFP negotiations so that FFP offers don't all fit in a single PDU when PDU size might be as small as 512. 
  
Support for vendor specific extension keys that are more then 8 k in login or more than MaxRcvPDUDataSize in FFP. 
  
Pat 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 8:56 PM
To: [email-masked]
Subject: RE: iSCSI: keys/parameter dependence

As I pointed out earlier - you can batch all your keys but some certificates in 8k! 
It was never forbidden nor mandated. 

Julo 

	[email-masked] 

06/05/2002 09:41 PM 

Julian, 

 
 
Regards, 
Pat 
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 04, 2002 10:19 AM
To: Robert D. Russell
Cc: [email-masked]; Martins Krikis; [email-masked]
Subject: Re: iSCSI: keys/parameter dependence

Julo 

06/04/2002 09:46 AM 

Martins:

Agreed.

Agreed.

Thoughts, comments?

Agreed.

Bob Russell

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 7 Jun 2002 16:23:57 +0300

The text should read now:

       If DataSequenceInOrder is set to Yes, a target may retry at most the
       last R2T, and an initiator may at most request retransmission for
       the last read data sequence.  For this reason if ErrorRecoveryLevel
       is not 0 and DataSequenceInOrder is set to Yes then MaxOustandingR2T
       MUST be set to 1.

 Julo

                      "Robert D.                                                                                                               
                      Russell"                 To:       [email-masked]                                                                       
                      <[email-masked]        cc:                                                                                             
                      du>                      Subject:  RE: iSCSI: keys/parameter dependence                                                  
                      Sent by:                                                                                                                 
                      [email-masked]                                                                                                        
                      .edu                                                                                                                     

                      06/06/2002 06:07                                                                                                         
                      PM                                                                                                                       
                      Please respond to                                                                                                        
                      "Robert D.                                                                                                               
                      Russell"                                                                                                                 

Julian:

or

Thanks,
Bob Russell

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 7 Jun 2002 16:52:46 +0300

Bob,

Some comments in text.

Regards,
Julo

                      "Robert D.                                                                                                               
                      Russell"                 To:       Julian Satran/Haifa/IBM@IBMIL                                                         
                      <[email-masked]        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