IETF Logo Mail Archive

Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Mon, 01 June 2015 09:13 UTC

Return-Path: <tireddy@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 129451A90C6 for <rtcweb@ietfa.amsl.com>; Mon, 1 Jun 2015 02:13:17 -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 G_iRnhnQNcsT for <rtcweb@ietfa.amsl.com>; Mon, 1 Jun 2015 02:13:15 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0981A90C1 for <rtcweb@ietf.org>; Mon, 1 Jun 2015 02:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2823; q=dns/txt; s=iport; t=1433149995; x=1434359595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2GhGONdNACeOGe+iz8XbCegInX98cjdvUp/M81NN5u8=; b=NkyXiUcGODnGgBXSGxSk20bZKQJNtFPRjGQDjbFsqG/jRAJ8Nv6KR8Y4 SRnu6GmbLKYaqphxIMSjFlyTJGyZg3Uty9JVtKa63a7ITMUoE8GFvnaa+ G32ZEd/VevILNVluvNcjF/BTzHDOI06ZNeFrdFO5JaPmGIp/kX9EWHm4l 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A3BAByIWxV/5BdJa1cgxBUXga9aGYJgVAKhS1KAoErOBQBAQEBAQEBgQqEIgEBAQMBAQEBNzQLDAQCAQgRAwEBAQsUCQchBgsUCQgCBAENBQiIEAMKCA3QUg2EdgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0OCTYFhJzEHBoMRgRYBBJMKiTmSB4cEI2GDF2+BBEKBAQEBAQ
X-IronPort-AV: E=Sophos;i="5.13,531,1427760000"; d="scan'208";a="155101180"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 01 Jun 2015 09:13:14 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t519DEWb021543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jun 2015 09:13:14 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 1 Jun 2015 04:13:14 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Bernard Aboba <bernard.aboba@gmail.com>, Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
Thread-Index: AdCZEAkgUwawg8/yQZKvd0M2cshTwQA3IdqAAB6E1AAAG0e6gAAVn3yAACmsfAAAIlRCgAADy+0A
Date: Mon, 01 Jun 2015 09:13:13 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A478627AA@xmb-rcd-x10.cisco.com>
References: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> <D18DD4A0.31980%rmohanr@cisco.com> <CE03DB3D7B45C245BCA0D243277949364CB762@MX104CL02.corp.emc.com> <556965FD.1060001@alvestrand.no> <B00F986D-664C-4DC5-AD9E-785680DAE81B@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D873AEB@ESESSMB209.ericsson.se> <D191F31F.32336%rmohanr@cisco.com>
In-Reply-To: <D191F31F.32336%rmohanr@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.18.53]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/TTMWWTGb0nBOSt6b1-CaTtetxC0>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] OPS-Dir 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, 01 Jun 2015 09:13:17 -0000

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R
> (rmohanr)
> Sent: Monday, June 01, 2015 11:31 AM
> To: Christer Holmberg; Bernard Aboba; Harald Alvestrand
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-
> freshness-13
> 
> WFM. I am fine with keeping APIs out of scope for consent document. It will
> be better to have all APIs in one document and have reference to that where
> ever applicable.

NEW:

8.  API Recommendations

   The W3C specification [W3C-WEBRTC] may provide an API hook that
   generates an event when consent has expired for a given 5-tuple,
   meaning that transmission of data has ceased.  This could indicate
   what application data is affected, such as media or data channels.
   The mechanism of how applications are made aware of consent
   expiration is outside the scope of the document.

-Tiru

> 
> Regards,
> Ram
> 
> -----Original Message-----
> From: Christer Holmberg <christer.holmberg@ericsson.com>
> Date: Sunday, 31 May 2015 7:08 pm
> To: Bernard Aboba <bernard.aboba@gmail.com>, Harald Alvestrand
> <harald@alvestrand.no>
> Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
> Subject: Re: [rtcweb] OPS-Dir review of
> draft-ietf-rtcweb-stun-consent-freshness-13
> 
> >Hi,
> >
> >>> I'd prefer to limit the number of documents that try to design APIs.
> >>>
> >>> Can we do something more generic, like "Applications that use the
> >>> RTWEB transport will need to be notified when transmission ceases
> >>> due to expiry of consent. The design of APIs to carry these
> >>> notifications  is out of scope for this document."?
> >>
> >> [BA] Agree with Harald. Loss of STUN consent on a 5-tuple is quite
> >>different from tripping  a circuit breaker. Let's not design the APIs
> >>in this document.
> >
> >I agree on the not-designing-the-API part.
> >
> >Regarding Harald's suggested text, it's fine - but I don't think it
> >belongs in this document. Shouldn't it be in the RTCWEB overview and/or
> >security document instead?
> >
> >The consent freshness draft could then state that the
> >mechanism/requirements how applications are made aware of consent
> >expiration is outside the scope of the document.
> >
> >Regards,
> >
> >Christer
> >
> >
> >
> >
> >
> >_______________________________________________
> >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

v2.19.0 | Report a Bug | By Email