Last Call Review of draft-ietf-rtcweb-stun-consent-freshness-12
review-ietf-rtcweb-stun-consent-freshness-12-genart-lc-shirazipour-2015-05-15-00

Request Review of draft-ietf-rtcweb-stun-consent-freshness
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-05-15
Requested 2015-05-07
Draft last updated 2015-05-15
Completed reviews Genart Last Call review of -12 by Meral Shirazipour (diff)
Genart Last Call review of -13 by Meral Shirazipour (diff)
Genart Last Call review of -15 by Meral Shirazipour (diff)
Secdir Last Call review of -11 by Steve Hanna (diff)
Opsdir Last Call review of -11 by David Black (diff)
Assignment Reviewer Meral Shirazipour
State Completed
Review review-ietf-rtcweb-stun-consent-freshness-12-genart-lc-shirazipour-2015-05-15
Reviewed rev. 12 (document currently at 16)
Review result Ready with Nits
Review completed: 2015-05-15

Review
review-ietf-rtcweb-stun-consent-freshness-12-genart-lc-shirazipour-2015-05-15






I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at


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

.





 




Please resolve these comments along with any other Last Call comments you may receive.




 




Document: draft-ietf-rtcweb-stun-consent-freshness-13 




Reviewer: Meral Shirazipour




Review Date: 2015-05-15




IETF LC End Date:  2015-05-15




IESG Telechat date: NA




 




 




Summary:




This draft is ready to be published as Standards Track RFC but I have some comments .




 




 




 




Major issues:




 




Minor issues:




 




Nits/editorial comments:




 




-The abstract lacks context, please consider adding some more text. A suggestion: repeat the first sentence from the intro in the abstract:





"To prevent attacks on peers, endpoints have to ensure the remote peer is willing to receive traffic."




 




-[Page 2] Intro: It was not clear if this document is specific to webRTC implementations. Is there any limitation to only use for webRTC? Maybe a sentence in the intro could clarify if there is or there is not such limitation.




 




-[Page 2] Intro, it would be good if the intro section could give a good example (use case, application) of when a receiving end would revoke the consent during the session.(why closing the session is not enough)





 




-[Page 3], Section2, "Transport Address" definition. It would be good to clarify this wrt 5-tuple. The two terms are used interchangeably, yet Transport address carries only destination IP protocol port, not the sender's (as carried in
 5-tuple).




e.g. [Page 4]:"….the remote peer's transport address, the endpoint MUST cease transmission on that 5-tuple."




 




-[Page 4] "Initial consent to send traffic is obtained using ICE.  Consent expires after 30 seconds." 





Is this value specified by [RFC6062] or this document? not clear.




 




-[Page 4-5]Section 4.1 addresses security issues. Section 8 adds additional content on security. It would be best to consolidate or at least have Section 8 point back to 4.1.




 




 




 




nits:




 




-[Page 5], "can not cause"--->"cannot cause"




-[Page 6], "each others keys"--->"each other's keys"




-[Page 7], typo "through review"--->"thorough review"




-SRTCP,DTLs, etc. please spell out acronyms at first use.




 




Best Regards,




Meral




---




Meral Shirazipour




Ericsson




Research




www.ericsson.com