IETF Logo Mail Archive

Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Tue, 26 August 2014 19:22 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.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 0D98B1A875D for <rtcweb@ietfa.amsl.com>; Tue, 26 Aug 2014 12:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 zbhUp8JlHc18 for <rtcweb@ietfa.amsl.com>; Tue, 26 Aug 2014 12:22:36 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53ED1A8766 for <rtcweb@ietf.org>; Tue, 26 Aug 2014 12:22:35 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 9FDF88E2232D6; Tue, 26 Aug 2014 19:22:31 +0000 (GMT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s7QJM3x7031284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 15:22:34 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Tue, 26 Aug 2014 15:21:41 -0400
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness
Thread-Index: AQHPwJwliI9buEYWNESDP5FmOAawY5vhzk/ggAFsZYD///NCAA==
Date: Tue, 26 Aug 2014 19:21:40 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E534706@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <CA+9kkMCZT1XW4LLaJ4Nq2DbrxD59cYnjLo5JXn9fjEb8pyamaQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <CAKz0y8zycsyr9m4BA=-8xOaWkU+Sog5Mbz7K-oN3woqi++mVzg@mail.gmail.com> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <CAKz0y8zNM3rc3XC6JqrK+d4hXiT5TomhNM+W2twg0+-83-pFow@mail.gmail.com> <CABkgnnUnfB5bskH4zWRfBMdHbSoqftV5Fo_GEXoLt9XCH9Tt_w@mail.gmail.com> <CAD5OKxsT9Vdm0=tjk9WsLAH4ekbAizgyjm--168TrOf8UAYGZw@mail.gmail.com> <CABkgnnXUpibu8kWYmbJJJT2J3RNGXFV8LbceLijgG0U-pGY2xQ@mail.gmail.com> <CAKz0y8z_oBf2efavfOLgzqE1R8sZstefZ1tvwwJLkhRskXZERQ@mail.gmail.com> <CAD5OKxsSqA=cki_fSaqAPP0GXCv_kHr6571C+K9ze4ceHCGYdQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <D01D6B42.104F8%rmohanr@cisco.com> <009001cfbe4f$6b92f280$42b8d780$@co.in> <CAKz0y8y3=0_-jwWiviR_Uj6tSq75NEq92Ocergc_NvFk2h_72Q@mail.gmail.com> <CAD5OKxugaPq=cLppPUqT8CUADV-E2zDMcz6m3sUgKOnK-TdQfQ@mail.gmail.com> <CABkgnnU6kv+=jQuxj4Ci-zYW9mHEfJ=6jqqrdqDTopPN06-kgw@mail.gmail.com> <CAD5OKxu=9X2um+EebZzp3isY-R_-NqyOgH+bWj55+_Q8qXfrqg@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E52F5F0@US70UWXCHMBA02.zam.alcatel-lucent.com> <CABkgnnUNk=QMFtGH3ZvD0V3B6OwSjcsOmaQU5+gcQ5wg9yo7aA@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E532F45@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAKz0y8wS93GbA-HrW9mMr=RsrTFVXTsV1=F14enNwYJ2Grfbnw@mail.gmail.com>
In-Reply-To: <CAKz0y8wS93GbA-HrW9mMr=RsrTFVXTsV1=F14enNwYJ2Grfbnw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E534706US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Va6PFX2CfeEpuLMN9uN8fprieG4
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness
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: Tue, 26 Aug 2014 19:22:38 -0000

Consent freshness is applicable to any WebRTC entity supporting full ICE. A WebRTC browser/device as defined in the transport and overview drafts support full ICE, so perform consent freshness. The requirements for other WebRTC entities, including WebRTC gateway, is yet to be fully specified, and the document that specifies them would also specify whether they support full ICE or not (and hence whether they perform consent freshness or not).

I don't see a problem with this approach.

If you have a better approach, do suggest the text.
<Raju>
IHMO, the consent freshness and ICE-full should NOT be coupled together.
So, I propose the following approach which overlaps with yours.

The draft-ietf-rtcweb-stun-consent-freshness should just talk about consent freshness in general and if it is supported by an implementation then it should specify the behavior, but not tie it to ICE-full.


The draft-ietf-rtcweb-transports should allow both ICE-full and ICE-lite implementations for webrtc and defer who implements what to respective webrtc class specific drafts (e.g. I-D.alvestrand-rtcweb-gateways). IMO, this is because webrtc is much bigger than just how ICE is done and categorizing an implementation as non-WeRTC just because of ICE-lite is not right.

The draft-ietf-rtcweb-overview can specify some high-level requirements for various classes of webrtc implementations and/or defer them, in some cases, to respective drafts (like it already did with I-D.alvestrand-rtcweb-gateways).
</Raju>

BR
Raju

v2.23.0 | Report a Bug | By Email