IETF Logo Mail Archive

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

Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Tue, 26 August 2014 14:45 UTC

Return-Path: <muthu.arul@gmail.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 C26941A86EA for <rtcweb@ietfa.amsl.com>; Tue, 26 Aug 2014 07:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 EOOwk0MwgPxg for <rtcweb@ietfa.amsl.com>; Tue, 26 Aug 2014 07:45:55 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A681A802B for <rtcweb@ietf.org>; Tue, 26 Aug 2014 07:45:54 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id n3so4292864wiv.1 for <rtcweb@ietf.org>; Tue, 26 Aug 2014 07:45:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4OpaW+f5doFIDNfUTeVO+qTvq4SCNr70SkuYGIst5ME=; b=TXBjgbRVx5BKgRklxc4lpSLQQxWmNh8Avvomfu75N94/9799fJ3cXdR4h5ma9A9P10 asxFKbch70+d5X7rzOekn5ggHuA4mWZGb6ek1dOYHUBM1pA/ynkcVL2E75xNXkheKWXq zDfgYwdZFUjk2UAyxbepgzMqGPxusp2tf9qcpydIl7NAVucLEOvRNB+skKMPnZas9076 Q249cyL5OfQG18ccYy8koDq/B4mAyCRAvgcJqTflY6Foy1RubOuBPfB+7c8BYG7e6zNh YBSJBRx4cCCR4wYUuEe8qrOSHZgRb7SSfaYJ6zZ8fffkhijCoq1ErgLKM22FZFBsca1e Y3FQ==
MIME-Version: 1.0
X-Received: by 10.180.73.139 with SMTP id l11mr22159825wiv.30.1409064353299; Tue, 26 Aug 2014 07:45:53 -0700 (PDT)
Received: by 10.180.197.168 with HTTP; Tue, 26 Aug 2014 07:45:53 -0700 (PDT)
In-Reply-To: <E1FE4C082A89A246A11D7F32A95A17828E532F45@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>
Date: Tue, 26 Aug 2014 20:15:53 +0530
Message-ID: <CAKz0y8wS93GbA-HrW9mMr=RsrTFVXTsV1=F14enNwYJ2Grfbnw@mail.gmail.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="f46d043c07de3e85700501895c40"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VOI4I_ZwGPt28xQzBTrfskhlVDw
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 14:45:56 -0000

On Tue, Aug 26, 2014 at 4:29 PM, Makaraju, Maridi Raju (Raju) <
Raju.Makaraju@alcatel-lucent.com> wrote:

> > On 25 August 2014 11:01, Makaraju, Maridi Raju (Raju)
> > <Raju.Makaraju@alcatel-lucent.com> wrote:
> > > I don’t think outlawing ICE-lite is acceptable.
> >
> > I've not ever suggested that.  I'm only suggesting that ICE-lite ∉
> > WebRTC.  (That's U+2209, btw).
> <Raju>
> WebRTC is defined by more than just ICE connectivity checks.
> IMHO, Categorizing a class of devices as NOT WebRTC just because of
> ICE-lite is not right, while there is so much other functionality (codecs,
> data channels) that is common. Also, the converse is not true either; just
> because a class of devices support ICE-full does not equate them to WebRTC
> class.
> So, IMHO there is no merit in (re)classifying WebRTC devices around
> ICE-lite.
> I also want to point out that ICE-lite is part of ICE RFC and also WebRTC
> clients already have a way to negotiate ICE-lite.
>
> In addition, draft-ietf-rtcweb-overview-11 added definition for 3 classes
> of webrtc devices with varying level of conformance while keeping the core
> webrtc conformance common. Won't rest of the specs like consent freshness,
> transports etc. refer to these classes of webrtc devices instead of just
> concentrating on just one type of webrtc device?
>

​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.

Muthu ​


>
> </Raju>
>
> BR
> Raju
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

v2.23.0 | Report a Bug | By Email