Gerrit,
Last things first:
>> If:
>> - the language about generating options used "MUST...MAY", instead of
>> "MUST...MUST NOT", and
> I still can not see a reason why there should be a state between on and off.
>
>
>> For instance, "Receivers MUST use previously specified mechanisms to
>> measure the round-trip time when Send RTT Estimate is zero; this document
>> does not define a standards-track method allowing receivers to use Sender
>> RTT Estimate options when the Send RTT Estimate is zero." [...])
> Agree in principle with this suggestion -- this is also the result of the
> discussions with Gorry.
Great!!
Now:
On 10/29/2010 04:24 AM, Gerrit Renker wrote:
My issue is simply that all other analogous option/feature combinations in DCCP
are specified like this:
DCCP A MUST send Ack Vector options on its acknowledgements when Send
Ack Vector/A has value one, although it MAY send Ack Vector options
even when Send Ack Vector/A is zero.
This was intentional; I can explain more if you care.
Please do - I asked for that in the previous email.
I can not see the point of doing the above.
It says "you MUST do A, but you MAY also not do A".
No, it doesn't. The plain language of the feature description says
- If the feature is one, the sender MUST send the option.
- If the feature is zero, the sender MAY send the option.
This is not a contradiction.
If a sender is permitted to add the option even if the negotiation means that
it is not permitted to use the option,
The idea of "not permitting" an option is not in the spec; you've invented it.
An endpoint is always permitted to send Ack Vector options. "Send Ack
Vector", when on, REQUIRES that an endpoint send Ack Vector options. When
off, the feature has no effect; the endpoint is still permitted to send Ack
Vector options, *as it always was*.
Among the reasons that we preferred MUST...MAY for features like this:
- It allows an endpoint to generate an option unconditionally, which might be
preferred for simplicity of implementation. Sender RTT Estimate, CCID-3 Loss
Event Rate are good examples.
- When an extension-feature is off (zero), we don't constrain endpoints'
behavior. That is key to forward compatibility; an endpoint by definition
cannot be constrained by an extension that does not yet exist.
I can see only disadvantages of allowing A and not-A. Apart from making the
implementation complex and confusing,
Doubt it. Among other reasons, for senders, the behavior you prefer
("MUST...MUST NOT") is a strict subset of the behavior we allow
("MUST...MAY"). And a receiver must always be able to handle any options.
it also opens a door for denial of service
attacks, a man in the middle could reformat most parts of the payload data simply
as an Ack Vector, flip the required bits of the checksum, and turn the bitstream
into random noise.
Totally bogus argument. Nothing about Send Ack Vector's current behavior
makes DoS attacks easier. Your man in the middle can do what you described no
matter what the spec says.
Eddie
