Re: [dccp] dccp draft | additional note to section 5.8.

[Eddie Kohler <kohler at cs.ucla.edu>]

Hi Hagen,

The correct answer is going to depend on the option in question.  For example 
multiple Ack Vectors are explicitly allowed:

"A single Ack Vector option can acknowledge up to 16192 data packets.  Should 
more packets need to be acknowledged than can fit in 253 bytes of Ack Vector, 
then multiple Ack Vector options can be sent; the second Ack Vector begins 
where the first left off, and so forth."

Multiple Change/Confirm options are allowed, as long as they refer to 
different features:

"A packet MAY contain more than one feature negotiation option, as long as
no two options refer to the same feature."

But we don't say what happens if someone DOES include more than one feature 
negotiation option referring to the same feature; and we don't say, in cases 
like NDP Count, anything about option duplication.

I think there is an issue here, Mark; wouldn't TCP be better if you didn't 
need to normalize it?

I would say that implementations MUST process all options sequentially, and 
unless otherwise specified (as in Ack Vector and Change/Confirm), in the case 
of multiple options, the last takes precedence.

As for Change/Confirm, I might remove the restriction about no two options 
referring to the same feature.  Although that would seem weird, I don't think 
the restriction is necessary, and I don't think it would make implementation 
any easier.

Eddie


Hagen Paul Pfeifer wrote:
> Additional note to document draft-ietf-dccp-spec-13.txt
>
> Section 5.8. (Options) stated that options are processed sequentially and
> unknown types or with nonsensical lengths MUST be ignored.
>
> What about the case that a broken implementation send out similarly options
> but with different values several times in one packet? Which option should
> the receiver take care? Its advantageous to define this arrangement also in
> the draft!
>
> Any opinions about that?
>
> best regards
>
> Hagen Paul Pfeifer
>
> --
> Signed and/or encrypted mails preferd. Key-Id = 0x98350C22
> Fingerprint = 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22