Last Call Review of draft-ietf-rmcat-coupled-cc-06
review-ietf-rmcat-coupled-cc-06-secdir-lc-lonvick-2017-08-24-00

Request Review of draft-ietf-rmcat-coupled-cc
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-08-28
Requested 2017-08-14
Other Reviews Opsdir Last Call review of -06 by Zitao Wang (diff)
Genart Last Call review of -06 by Matthew Miller (diff)
Review State Completed
Reviewer Chris Lonvick
Review review-ietf-rmcat-coupled-cc-06-secdir-lc-lonvick-2017-08-24
Posted at https://mailarchive.ietf.org/arch/msg/secdir/gtDzu3HeUNgIrhExPj_-u9SafqI
Reviewed rev. 06 (document currently at 07)
Review result Has Nits
Draft last updated 2017-08-24
Review closed: 2017-08-24

Review
review-ietf-rmcat-coupled-cc-06-secdir-lc-lonvick-2017-08-24

Hi,

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 last call comments.

The summary of the review is that the ID is ready with nits.

This INFORMATIONAL draft discusses an experimental protocol. The 
Security Considerations section is adequate, but I would suggest 
including a brief statement that implementers should also be aware of 
the Security Considerations sections of RFC 3124 (normatively 
referenced), and RFCs 5348 and 7478 (both informatively referenced). 
Each of of these RFCs is discussed within the draft.

I also agree with Section 5 of the Shepherd Writeup, and nothing need be 
done to the draft about that.

   This is a heavily transport related draft, being focussed entirely
   on details of congestion control. Security considerations are adequate,
   although they will likely need elaboration for a future standards-track
   revision of this work in the light of operational experience. The draft
   says little about operational complexity, and the risks of cheating and
   poor quality implementations, but this will depend on the experiences
   with the protocol, and cannot effectively be done without experimentation
   and controlled deployment experience.


Regards,
Chris