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

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