Last Call Review of draft-ietf-tsvwg-behave-requirements-update-06
review-ietf-tsvwg-behave-requirements-update-06-genart-lc-romascanu-2016-02-15-00

Request Review of draft-ietf-tsvwg-behave-requirements-update
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-02-16
Requested 2016-02-04
Authors Reinaldo Penno, Simon Perreault, Mohamed Boucadair, Senthil Sivakumar, Kengo Naito
Draft last updated 2016-02-15
Completed reviews Genart Last Call review of -06 by Dan Romascanu (diff)
Genart Telechat review of -07 by Dan Romascanu (diff)
Secdir Last Call review of -06 by Ben Laurie (diff)
Opsdir Last Call review of -06 by Mahesh Jethanandani (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-tsvwg-behave-requirements-update-06-genart-lc-romascanu-2016-02-15
Reviewed rev. 06 (document currently at 08)
Review result Ready with Issues
Review completed: 2016-02-15

Review
review-ietf-tsvwg-behave-requirements-update-06-genart-lc-romascanu-2016-02-15






I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.




 




For more information, please see the FAQ at




 




< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>




 




Document:  draft-ietf-tsvwg-behave-requirements-update-06




Reviewer: Dan Romascanu




Review Date: 2/15/16




IETF LC End Date: 2/16/16




IESG Telechat date: 




 




Summary: This document is ready with minor issues. 




 




Major issues:




 




None




 




Minor issues:




 







1.

      


The text in the second and third paragraphs in section 2.2 is rather confusing. Do these belong to updates, or should they be under Notes?





 







Ø

 


Admittedly, the NAT has to verify whether received TCP RST packets belong to a connection. This verification check is required to avoid off-path attacks.




 







Ø

 


If the NAT removes immediately the NAT mapping upon receipt of a TCP RST message, stale connections may be maintained by endpoints if the first RST message is lost between the NAT and the recipient.




 




If they belong to Updates ‘Admittedly’ needs to be dropped, ‘has to verify’ becomes ‘SHOULD verify’, etc.





Else, if these are rather notes they should be labeled Notes or Clarification




 







2.

      


In section 5: 




 







Ø

 


This update is compliant with the stateful NAT64 [RFC6146] that clearly specifies three binding information bases (TCP, UDP, ICMP).




 




As the focus of this document is NAT44, I do not believe that ‘compliant’ is the right word. Probably ‘consistent’ would be more appropriate.




 







3.

      


EIF is never expanded




 




Nits/editorial comments:




 




None.