Re: [rtcweb] Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13

Meral Shirazipour <meral.shirazipour@ericsson.com> Mon, 18 May 2015 18:01 UTC

Return-Path: <meral.shirazipour@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB781A6F12; Mon, 18 May 2015 11:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiGVn7i7Eo95; Mon, 18 May 2015 11:01:32 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DEE11AD2D5; Mon, 18 May 2015 11:01:32 -0700 (PDT)
X-AuditID: c618062d-f79a96d000007fb1-d8-5559d0692471
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 54.D9.32689.960D9555; Mon, 18 May 2015 13:43:37 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Mon, 18 May 2015 14:01:30 -0400
From: Meral Shirazipour <meral.shirazipour@ericsson.com>
To: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
Thread-Topic: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13
Thread-Index: AdCPTCeBLwIOGK4OTCGKJsw8iNXzOwCmJtAAABQ/LBA=
Date: Mon, 18 May 2015 18:01:30 +0000
Message-ID: <ABCAA4EF18F17B4FB619EA93DEF7939A3329B53D@eusaamb107.ericsson.se>
References: <ABCAA4EF18F17B4FB619EA93DEF7939A33239E08@eusaamb107.ericsson.se> <D17F9195.2FB1A%rmohanr@cisco.com>
In-Reply-To: <D17F9195.2FB1A%rmohanr@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPiG7mhchQgxf/9SxmX13IaHH11WcW i+VdOxgt1v5rZ3dg8ZjyeyOrx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CV0bDoAUvBZb2K bwuesTYwzlTrYuTkkBAwkdixfzUbhC0mceHeeiCbi0NI4CijxOqXm8ASQgLLGSWun3YDsdkE LCS2/37OCmKLCOhLvNmwDKyBWeA8o8S8rj1MIAlhgTCJvS0djBBF4RJXpzeyQ9hWEkfWHQar YRFQldjQMhvM5hXwlZg4ZznQUA6gZUUSB86IgYQ5geYv//aXBcRmBDru+6k1YOXMAuISt57M Z4I4WkBiyZ7zzBC2qMTLx/9YIWxFiX3909kh6nUkFuz+xAZha0ssW/iaGWKtoMTJmU9YJjCK zUIydhaSlllIWmYhaVnAyLKKkaO0OLUsN93IYBMjMIaOSbDp7mDc89LyEKMAB6MSD++DeRGh QqyJZcWVuYcYpTlYlMR5vxmGhAoJpCeWpGanphakFsUXleakFh9iZOLglGpglJmqKJpnI292 cauWyNWGFyULN+04YDY/wWX9yvWFNn/DE6PK71TW3Tmw+6XdBuXrykXzSmZN2Bii62/P8vTw noht0h++6Aa7veo/e7m178rM5N9ZFwvq/7ntvH7L0VQgirFkW9nx1+zZcqtXnbG5sqKx8v4U 9v3K79qXFK/e8v20ev+fBHNPOSWW4oxEQy3mouJEABOEl4yCAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/0hLipBgaRQuCvM7nXArLIKaST0A>
X-Mailman-Approved-At: Mon, 18 May 2015 11:05:13 -0700
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" <draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 May 2015 18:01:39 -0000

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:rmohanr@cisco.com] 
Sent: Monday, May 18, 2015 10:04 AM
To: Meral Shirazipour; draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org; gen-art@ietf.org; rtcweb@ietf.org
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 <meral.shirazipour@ericsson.com>
Date: Saturday, 16 May 2015 1:47 am
To: "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org"
<draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org>,
"gen-art@ietf.org" <gen-art@ietf.org>
Subject: Gen-ART Last Call review of
draft-ietf-rtcweb-stun-consent-freshness-13
Resent-From: <meral.shirazipour@ericsson.com>
Resent-To: <draft-ietf-rtcweb-stun-consent-freshness.all@ietf.org>
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:gen-art-bounces@ietf.org] On Behalf Of Meral Shirazipour
Sent: Friday, May 15, 2015 1:18 PM
To: draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org; gen-art@ietf.org
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