------------------------------------------------
        Alternatives of dealing with misbehaving clients
        ------------------------------------------------

This text argues why it is better to reset the connection when a server
finds that a client did not provide the expected Confirm options when
sending the Ack in reply to the Response sent previously by the server.

1. Presentation of the issues (failed feature negotiation)
---------------------------------------------------------
The problem is that the client, after sending the Ack, is now in a state
(PARTOPEN) ready for data transmission, with merely a format restriction -
 it must use DataAcks instead of pure Data packets for its traffic (8.1.5).

Analogously, since the receipt of the Ack completes the three-way handshake,
the server proceeds to the OPEN state, which indicates that it is `ready'
for participating in data transfer. This, however, is in conflict with the
fact that several parameters affecting the data transfer are still under
negotiation, with yet unresolved (and hence undefined) values.

We thus have the same situation as in negotiating conversation features
while in mid-conversation. Since these feature parameters reconfigure the
endpoints with regard to how the actual data transfer is performed, data
transfer needs to be suspended as long as negotiation of relevant features
is still in progress.

2. Alternatives to suspending data traffic while in state (PART)OPEN
--------------------------------------------------------------------
Suspending data transfer while in state OPEN can be realised by introducing
additional rules, which however clashes with the definition of the OPEN state
as being `open to data transfer'.

An alternative to such additional processing rules is the use of an
intermediate protocol state, e.g. SEMI_OPEN, which would be entered when
a server with pending feature-negotiation receives an Ack from the client
without the awaited Confirm options. While in such an intermediate state, the
server could repeatedly transmit Sync packets to effect feature-negotiation
retransmission, until the client replies with a SyncAck carrying the requested
Confirm options.

There are tho reasons which speak against such a solution. 

Firstly, nothing stops an unsuspecting client from entering into data transfer
and thereby using an only partially configured transport channel. 

Secondly, the use of additional states alters the DCCP protocol state machine
and should only be used as very last resort. 

3. Additional reason for preferring re-setting the connection
-------------------------------------------------------------
An additional advantage of this solution is scalability and robustness: if
the server is asked to keep state for a client until the client happens to add
Confirm options to its packets, then this opens a door for Denial-of-Service
attacks in which many clients open connections with the same server, but
never reply with Confirm options and/or silently terminate without sending
a Close/Reset packet.