Last Call Review of draft-ietf-rtcweb-stun-consent-freshness-13
review-ietf-rtcweb-stun-consent-freshness-13-genart-lc-shirazipour-2015-05-21-00
Request | Review of | draft-ietf-rtcweb-stun-consent-freshness |
---|---|---|
Requested revision | No specific revision (document currently at 16) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2015-05-26 | |
Requested | 2015-05-14 | |
Authors | Muthu Arul Mozhi Perumal , Dan Wing , Ram R , Tirumaleswar Reddy.K , Martin Thomson | |
I-D last updated | 2015-05-21 | |
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 L. Black (diff) |
|
Assignment | Reviewer | Meral Shirazipour |
State | Completed | |
Request | Last Call review on draft-ietf-rtcweb-stun-consent-freshness by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 13 (document currently at 16) | |
Result | Ready w/nits | |
Completed | 2015-05-21 |
review-ietf-rtcweb-stun-consent-freshness-13-genart-lc-shirazipour-2015-05-21-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