Gerrit...
On 10/19/2010 10:42 PM, Gerrit Renker wrote:
It is justified by applying the suggestions made in that section. If you can
officially add what you have written in the preceding email as an erratum to
RFC 4340 we would be happy to use it. Otherwise we will not change it.
You and Gorry disagree. My previous email, being RTT Estimate specific, is
not appropriate for an erratum. But see below.
RFC4340 compliant DCCP endpoints may send new options before negotiating a
corresponding feature. Gorry and Arjuna's RFC 5634 does this already.
RFC4340 S15 uses the undefined term "extension":
o Each DCCP extension SHOULD be controlled by some feature. The
default value of this feature SHOULD correspond to "extension not
available". If an extended DCCP wants to use the extension, it
SHOULD attempt to change the feature's value using a Change L or
Change R option. Any non-extended DCCP will ignore the option,
thus leaving the feature value at its default, "extension not
available".
An endpoint-shared behavior change is usually an extension; an option alone
may not be. The 'Send RTT Estimate' feature controls the "extension" part of
this proposal, namely the shared behavior change where the sender promises to
send RTT Estimates, and the receiver prefers RTT Estimates to CCval (and
radically slows down in the absence of RTT Estimates).
The analogy with RFC4340's Send NDP Count and Send Ack Vector features and
RFC4342's Send Loss Event Rate feature is exact. These features all are
defined as "MUST send if on, MAY send if off," AND ARE EXPLICITLY DESCRIBED AS
EXTENSIONS.
RFC4340.
Req'd This column is "Y" if and only if every DCCP
implementation MUST understand the feature. If it is
"N", then the feature behaves like an extension (see
Section 15), and it is safe to respond to Change
options for the feature with empty Confirm options.
(Send NDP Count and Send Ack Vector are not Req'd.)
RFC4342.
Send Loss Event Rate is
optional, in that it behaves like an extension ([RFC4340], Section
15).
-*-
Here's an attempt at clarifying RFC4340.
o Each DCCP extension SHOULD be controlled by some feature.
("Extension" refers to a behavior change on which both endpoints
must agree.)
Does this help? It was and is difficult to completely define this concept,
since it must cover future compatibility. I've tried, again, for some time
now and not found a satisfactory way. Input solicited. But given the above I
don't consider an erratum required.
Eddie
