> I'm recommending that implementers exercise
good judgment … are you objecting to this?
No
> I think we're
close to violent agreement.
Yes
Actually, I
started this thread because I was wondering what was meant by the sentence:
Not
offering a key for negotiation is not
equivalent
to offering the current (or default) value.
And I think
that was answered.
Thanks
Eddy
-----Original
Message-----
From: Black_David@emc.com
[mailto:Black_David@emc.com]
Sent: Friday, February 01, 2002
10:08 AM
To: Eddy_Quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: not offering a
key
Eddy,
> 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.
That
was definitely not my intention. If either party chooses to negotiate a
value, the negotiation
code that
has to be implemented anyway will drive both parties to agreement, but notice
the *if*.
I
definitely do not want this taken to an extreme that would require all keys to
be negotiated in
all
cases. As a consequence, there will be situations in which mistakes occur
that cause the
two
parties to have different ideas of what the default value is for a key that
wasn't negotiated
(to
err is human, most code is written by humans ... ). I am recommending an
"if in doubt,
negotiate"
approach to implementation that will tend to limit such problems to relatively
unimportant
keys. Coverage of "all possible bugs" was not my intention.
> 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.
I think we have a serious
difference in philosophy. The usual IETF
dictum of being conservative in
what is sent and liberal in what is
accepted implies coverage of more
than just bugs that could cause a
crash or data corruption - see
the recent example I sent to the list
of how a notion of "implicit
offers" could cause a silly breakdown
in negotiation. OTOH, being
liberal in what is accepted does not
equate to covering all possible bugs - it means doing one's
best to
do something reasonable in the face of the unexpected as opposed
to regarding the least little thing going wrong as a fatal error
and
reason to immediately give up.
As to the standard, I'm not proposing
any change. I'm recommending that implementers
exercise good judgment by choosing to
negotiate any parameters that are important to the behavior
and performance of their implementation
(which sounds like common sense - are you objecting to
this?). The negotiation algorithm
has been (and should be) specified in a way that is robust to
minor things going wrong, and hence just
using it provides some robustness against minor
things going wrong.
The overall principle is somewhat
akin to the exhortation not to complain about the behavior of
the government if you didn't bother to
vote. I think we're close to violent agreement.
Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA 01748
+1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500
black_david@emc.com Cell: +1
(978) 394-7754
---------------------------------------------------
-----Original Message-----
From: Eddy Quicksall
[mailto:Eddy_Quicksall@ivivity.com]
Sent: Friday, February 01, 2002
7:37 AM
To: Black_David@emc.com; Eddy
Quicksall
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: not offering a
key
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
