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

"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Mon, 18 May 2015 17:03 UTC

Return-Path: <rmohanr@cisco.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 1E5661AD359; Mon, 18 May 2015 10:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 UhRw9EBSK7Wz; Mon, 18 May 2015 10:03:42 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4611AD352; Mon, 18 May 2015 10:03:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2479; q=dns/txt; s=iport; t=1431968622; x=1433178222; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jExbXwt7lT4eDugHZTTmGpQHIICFrYkfsOgsHSvk/mY=; b=Hg4a3odi56QxpF78b3c9MFM/LYDZ7bDSA5EeWM7tlx2p8LoI4zIugU2R HYhr1/IYhhgTdcmdjw1FS0edqnOtROaCGcCZ5+3fpJZDUycFPy/mOux0J 8+kV3UFSa9uiZhaazQoKyMEZOM6T+vaCxpetRYuFYxXhMQxpnvO2DHEYC 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANBQBnGlpV/5RdJa1cgxBUXgbGT4V2AoE0TAEBAQEBAYELhCIBAQEEOksEAgEIEQMBAh8QMh0IAQEEARKILA3YRwEBAQEBAQEBAgEBAQEBAQEBGos6hQwGhCcFkmWEL4ZLgSc+gyqOJYNYI2GDF28BgUSBAQEBAQ
X-IronPort-AV: E=Sophos;i="5.13,454,1427760000"; d="scan'208";a="417537085"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP; 18 May 2015 17:03:41 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4IH3faw028856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 May 2015 17:03:41 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.60]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 18 May 2015 12:03:41 -0500
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: Meral Shirazipour <meral.shirazipour@ericsson.com>, "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>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13
Thread-Index: AdCPTCeBLwIOGK4OTCGKJsw8iNXzOwCmJtAA
Date: Mon, 18 May 2015 17:03:40 +0000
Message-ID: <D17F9195.2FB1A%rmohanr@cisco.com>
References: <ABCAA4EF18F17B4FB619EA93DEF7939A33239E08@eusaamb107.ericsson.se>
In-Reply-To: <ABCAA4EF18F17B4FB619EA93DEF7939A33239E08@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [10.65.60.246]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DAAB4F86791D3C479E20D5E029A8BC6F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/9RZA2CmSqKeCd_rDXgRuJfGReXA>
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 17:03:44 -0000

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

>
>-[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 ?

Regards,
Ram