> 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". If a sender is permitted to add the option even if the negotiation means that it is not permitted to use the option, it generates uncommitted data which gets ignored by the receiver. This creates a lot of waste of bandwidth. Ack Vector options are a good example - they have dynamic length, so at worst there are several hundred wasted bytes per each packet when allowing the sender to go ahead and ignore the feature negotiation. I can see only disadvantages of allowing A and not-A. Apart from making the implementation complex and confusing, 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. >> If there is something I may have misunderstood, please can you clarify. > > 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.
