Maybe I misunderstood your note.
What I was referring to is that you said:
If for some
reason the other party doesn't have the
same default
(bugs happen), negotiation should drive
both
parties to an agreed value ...
Reading on I assumed you meant that we should add code to cope with
that. If you take that to an extreme, we would be adding “lots of code” just to
cover all possible bugs.
An implementation should only have to cover the other ends bugs that
could cause a crash or data corruption at our end. In this case, I don’t think
that means we should change the standard to do extra negotiations just to cover
possible bugs.
Again, maybe I misunderstood what you were trying to say.
Eddy
-----Original
Message-----
From: Black_David@emc.com
[mailto:Black_David@emc.com]
Sent: Tuesday, January 29, 2002
3:16 AM
To: Eddy_Quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: not offering a
key
I don't understand how this leads to "lots of
code". The
underlying principle is to negotiate anything you care about
and not to complain about things that you didn't negotiate.
Saying that there are no implicit offers is fine with me.
Thanks,
--David
-----Original
Message-----
From: Eddy Quicksall
[mailto:Eddy_Quicksall@ivivity.com]
Sent: Monday, January 28, 2002
12:42 PM
To: julian_satran@il. ibm. com
(E-mail)
Cc: ips@ece.cmu.edu; Robert D.
Russell
Subject: RE: iSCSI: not offering a
key
I don’t
think we should be in the business of adding lots of code to cope with possible
bugs at the other end … there would be no end to what you would do and how you
would do it.
Couldn’t
we just strike the sentence and say what Dr. Russell said. I would suggest something
like:
“There is
no such thing as implicit offers. If an explicit offer is not made then a reply
cannot be expected.”
-- cut and
past from his EMAIL --
I believe this
sentence was added to the spec because at the
last UNH
plugfest, several people were interpreting "no explicit
offer" of
a key as an "implicit" offer of the default for the key,
and were
therefore expecting a reply. This
sentence is intended
to prevent
that interpretation -- if you don't make an explict offer
you cannot expect a reply -- there are no such
things as implicit offers.
Eddy
-----Original Message-----
From: Black_David@emc.com
[mailto:Black_David@emc.com]
Sent: Saturday, January 26, 2002
3:31 AM
To: Eddy_Quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: not offering a
key
> Maybe I don’t
understand the sentence. I interpret it to mean that if the
> default value is
acceptable to me then not offering it is somehow different
> than the default … and
that confuses me (well, actually it makes me wonder
> if the sentence is
trying to say something else).
Here are two examples of how it's different:
(1) If for some reason the other party doesn't have the
same default (bugs happen), negotiation
should drive
both parties to an agreed value, but in
the absence of
negotiation, the other party might do
something different.
Moral: if a key value is important, it
MUST be negotiated.
This is a little weaker than Luben's statement
that
all keys always have to be negotiated.
That strength
was never intended.
(2) If the other party wants to negotiate the value and
both offer the same default value, not offering
the default
results in an additional step before the
negotiation can
conclude, viz:
-> Nothing
-> Key=Default
<- Key=Default <-
Key=Default
-> Key=Default
--David
