Hi Ram, Thank you for the response. Please see in line. Also, I did not see response to the rest of the comments, not sure if it was cut from the email (please see below-I copy pasted the original email).
Best regards, Meral -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:[email protected]] Sent: Monday, May 18, 2015 10:04 AM To: Meral Shirazipour; [email protected]; [email protected]; [email protected] Subject: Re: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 Hi Meral, Thanks for your feedback. See inline -----Original Message----- From: Meral Shirazipour <[email protected]> Date: Saturday, 16 May 2015 1:47 am To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 Resent-From: <[email protected]> Resent-To: <[email protected]> Resent-Date: Saturday, 16 May 2015 1:48 am >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." Sure we will add this text [Msh] thank you > >-[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 This document does not restrict itself to webRTC implementations alone which is the reason we have not specified any where that Consent freshness is for only webRTC clients. Any full ICE implementations can use Consent freshness. We have this text at the end of introduction in the current draft "This document defines what it takes to obtain, maintain, and lose consent to send. Consent to send applies to a single 5-tuple. How applications react to changes in consent is not described in this document. Consent is obtained only by full ICE implementations. An ICE-lite implementation will not generate consent checks, but will just respond to consent checks it receives." Is this not sufficient ? [Msh] Somehow I had to read twice to deduce that. If you think that is sufficient and there is no need to specifically state not limited to webRTC the I am ok with it too. Regards, Ram From: Gen-art [mailto:[email protected]] On Behalf Of Meral Shirazipour Sent: Friday, May 15, 2015 1:18 PM To: [email protected]; [email protected] Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
