You have my signed-off-by for this patch. I'm not clear if you intend to use this top commit message for the entire patch, if so, see comment below. > In contrast to static feature negotiation at the begin of a connection, which > establishes the capabilities of both endpoints, this patch introduces support > for dynamic exchange of feature negotiation options. > > Such a dynamic exchange is necessary in at least two cases: > * CCID-2's Ack Ratio (RFC 4341, 6.1.2) which changes during the connection; > * Sequence Window values that, as per RFC 4340, 7.5.2, should be sent "as > as the connection progresses". > > Both are NN (non-negotiable) features. Hence dynamic feature "negotiation" is > distinguished from static/pre-connection negotiation by the following: > * no new capabilities are negotiated (those that matter for the connection > are negotiated prior to setting up the connection, comparable to SIP); > * features must be understood by each endpoint: as per RFC 4340, 6.4, > Sequence Window is "Req'd" and Ack Ratio must be understood when CCID-2 > is used as per the note underneath Table 4. > > These characteristics are reflected in the implementation: > * only NN options can be exchanged after connection setup; > * NN options are activated directly after validating them. The rationale is > that a peer must accept every valid NN value (RFC 4340, 6.3.2), hence it > will either accept the value and send a "Confirm R", or it will send an > empty Confirm (which will reset the connection according to FN rules). This statement is confusing. While the receiving side will activate a immediately, the sender will now wait for the CONFIRM before activating the new value. This changed as a result of one of the merged patches. I would recommend leaving this statement out. > * An Ack is scheduled directly after activation to accelerate communicating > the update to the peer. > > Signed-off-by: Gerrit Renker <gerrit@xxxxxxxxxxxxxx> > Acked-by: Ian McDonald <ian.mcdonald@xxxxxxxxxxx> Signed-off-by: Samuel Jero <sj323707@xxxxxxxx> Samuel Jero Internetworking Research Group Ohio University
Attachment:
signature.asc
Description: OpenPGP digital signature