I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other review
comments.


This document is difficult to read. There are structural issues, and maybe some unnecessary content. I'm marking this "Has Nits" rather than "Has issues" since as far as I can tell, the addition to protocol it describes have no new security issues other than what is noted in the security considerations section. Please consider whether there are other operational considerations that might help avoid over-consumption of sequence numbers.

Nits:

Please look at the outline as reflected in the Table of Contents. In section 6, there are things listed as "Requirements" that aren't requirements. Consider separating discussion of the things like race conditions that lead to requirements from the requirements and state the requirements succinctly. Similarly section 5 claims to be about "components" but talks about things (particularly in 5.3) that are not components themselves.

Consider removing most of the diagrams. They aren't leveraged well in the discussion, and I don't think they advance understanding the problem or the proposed protocol beyond the prose.

Please consider asking for early input from the RFC Editor.