Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt

Harald Alvestrand <harald@alvestrand.no> Fri, 11 April 2014 10:55 UTC

Return-Path: <harald@alvestrand.no>
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 11AA31A0649 for <rtcweb@ietfa.amsl.com>; Fri, 11 Apr 2014 03:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 UcjDQa0BHm-9 for <rtcweb@ietfa.amsl.com>; Fri, 11 Apr 2014 03:54:58 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 726CA1A0642 for <rtcweb@ietf.org>; Fri, 11 Apr 2014 03:54:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 35F787C51FA; Fri, 11 Apr 2014 12:54:56 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE5l1t2dsoUn; Fri, 11 Apr 2014 12:54:55 +0200 (CEST)
Received: from [172.28.209.191] (unknown [74.125.57.33]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0804D7C51F7; Fri, 11 Apr 2014 12:54:54 +0200 (CEST)
Message-ID: <5347C9FD.7000609@alvestrand.no>
Date: Fri, 11 Apr 2014 12:54:53 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Karl Stahl <karl.stahl@intertex.se>, rtcweb@ietf.org
References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <CF6D6F0C.878CF%rmohanr@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> <014201cf5573$c02ae3b0$4080ab10$@stahl@intertex.se>
In-Reply-To: <014201cf5573$c02ae3b0$4080ab10$@stahl@intertex.se>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HnIjUuKCKcV6Y9BHbE1jYkh1B24
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt
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: Fri, 11 Apr 2014 10:55:02 -0000

On 04/11/2014 12:49 PM, Karl Stahl wrote:
> Harald,
>
> Just remembered regarding ICE Lite in your transport document; I think your
> statement regarding ICE, not ICE Lite therein, should be clarified so it is
> understood that browsers must (also) operate against ICE Lite devices
> (typical for a gateway).

Huh?

As far as I understand ICE-Lite, any full ICE implementation will
interoperate with an ICE-Lite implementation without any special handling.
Thus, any ICE implementation that doesn't do so has a bug.

I don't want to put in the document a statement that says "MUST
implement ICE and MUST NOT have bugs that prevent interoperability with
ICE-Lite". That's just not helpful.

>
> (That is the way it already works in Chrome - buggy in Firefox though)
>  
> /Karl
>
> -----Ursprungligt meddelande-----
> Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Christer Holmberg
> Skickat: den 11 april 2014 08:52
> Till: Ram Mohan R (rmohanr); rtcweb@ietf.org
> Ämne: Re: [rtcweb] I-D Action:
> draft-ietf-rtcweb-stun-consent-freshness-02.txt
>
> Hi,
>
> I think it would be good to have some text about usage of consent freshness
> when one entity is ICE lite.
>
> And, I think it would be good to make it more clear that the usage of
> consent is always negotiated per direction.
>
> Thanks!
>
> Regards,
>
> Christer
>
>
> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R
> (rmohanr)
> Sent: 11. huhtikuuta 2014 8:01
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] I-D Action:
> draft-ietf-rtcweb-stun-consent-freshness-02.txt
>
> Summary of changes in this revision
>
> Addressed the comments received from the WG.
> Removed the timers definition from solution overview and made the text more
> generic.
> Incorporated text from draft-thomson-rtcweb-consent.
> Most of the text of solution overview is re-written however the idea is
> still kept intact
>
>
> Comments are welcome.
>
> There is still some dangling reference (text) to SRTP/DTLS mechanism for
> consent which we will modify in the next revision
>
>
> Regards,
> Authors
>
> -----Original Message-----
> From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> Date: Friday, 11 April 2014 9:07 am
> To: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
> Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
> Subject: [rtcweb] I-D Action:
> draft-ietf-rtcweb-stun-consent-freshness-02.txt
>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Real-Time Communication in 
>> WEB-browsers Working Group of the IETF.
>>
>>        Title           : STUN Usage for Consent Freshness
>>        Authors         : Muthu Arul Mozhi Perumal
>>                          Dan Wing
>>                          Ram Mohan Ravindranath
>>                          Tirumaleswar Reddy
>>                          Martin Thomson
>> 	Filename        : draft-ietf-rtcweb-stun-consent-freshness-02.txt
>> 	Pages           : 8
>> 	Date            : 2014-04-10
>>
>> Abstract:
>>   To prevent sending excessive traffic to an endpoint, periodic consent
>>   needs to be obtained from that remote endpoint.
>>
>>   This document describes a consent mechanism using a new STUN usage.
>>   This same mechanism can also determine connection loss ("liveness")
>>   with a remote peer.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshne
>> ss/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-02
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshne
>> ss-
>> 02
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


-- 
Surveillance is pervasive. Go Dark.