Return-Path: <andrew.hutton@siemens-enterprise.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
 with ESMTP id 8A1D811E8150 for <rtcweb@ietfa.amsl.com>;
 Fri, 12 Jul 2013 09:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.545
X-Spam-Level: 
X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054,
 BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJcpVWnO9yfw for
 <rtcweb@ietfa.amsl.com>; Fri, 12 Jul 2013 09:44:20 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com
 (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com
 (Postfix) with ESMTP id 6C78121F9F71 for <rtcweb@ietf.org>;
 Fri, 12 Jul 2013 09:44:18 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by
 senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 87FCA23F0585;
 Fri, 12 Jul 2013 18:44:15 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by
 MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003;
 Fri, 12 Jul 2013 18:44:15 +0200
From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Thread-Topic: [rtcweb] Draft agenda for IETF 87 - FW Issues
Thread-Index: AQHOflbuioJxfw6BTUiF3V93e/1K7plguuEQgABKaYCAACHmgP//5B0AgAAx4TA=
Date: Fri, 12 Jul 2013 16:44:14 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF11641905@MCHP04MSX.global-ad.net>
References: <CA+9kkMBuCTdFsUMtmuBz6BnrSJMpHywEZU+x+m8ARnGprvzDzA@mail.gmail.com>
 <9F33F40F6F2CD847824537F3C4E37DDF116406C8@MCHP04MSX.global-ad.net>
 <C5E08FE080ACFD4DAE31E4BDBF944EB1135D6B20@xmb-aln-x02.cisco.com>
 <9F33F40F6F2CD847824537F3C4E37DDF1164151F@MCHP04MSX.global-ad.net>
 <C5E08FE080ACFD4DAE31E4BDBF944EB1135D6FD3@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB1135D6FD3@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Jul 2013 16:44:25 -0000

I totally don't follow this argument.

What we need is for RTCWEB browsers to behave in a standardized way in envi=
ronments where there is a FW requiring the flow to come from a HTTP Proxy. =
Defining this is clearly within the scope of RTCWEB and if we move the work=
 to BEHAVE we still need a RTCWEB specification to say what rtcweb implemen=
tations are required to implement.

The charter states the wg will.

"Define the solution - protocols and API requirements - for firewall and NA=
T traversal".

It also states:

"This work will be done primarily by using already defined protocols or fun=
ctionalities. If there is identification of missing protocols or functional=
ities, such work can be requested to be done in another working group with =
a suitable charter or by requests for chartering it in this WG or another W=
G".

We have not so far identified any missing protocol or functionality so why =
do you ask the work to be moved to a different group?

With regard to the full agenda I for one think we can find time for this ra=
ther than again circling through the endless discussion on some of the othe=
r topics. I am not sure also why we need 40 mins to discuss the use case up=
dates time would be better spent finding solutions for the existing use cas=
es.

If you think that nobody will object then surely we can get this over very =
quickly.

Agree there has not been enough discussion on the draft but I have received=
 only positive feedback including some comments off list.

Regards
Andy





> -----Original Message-----
> From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]
> Sent: 12 July 2013 16:31
> To: Hutton, Andrew
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues
>=20
>=20
> So section 3.3.1 of draft-hutton-rtcweb-nat-firewall-considerations
> provides a brief sketch of an extension to TURN clients to use a HTTP
> proxy.
>=20
> I would be shocked to see anyone in this WG tell you not to do that,
> it's been discussed many times in the past. But in the end this WG will
> either say we like it, take it to BEHAVE, or it will say we hate it in
> which case as and individual draft you will still probably take it to
> BEHAVE. You probably want to keep an eye on HTTP2 stuff and
> implications to this too.
>=20
> We had not much list discussion on this draft. We have an agenda very
> full of WG items that are very controversial. We could put it at the
> end of the agenda with "time permitting" but to be honest, I sort of
> doubt we would get to it. Is there some question you think you want
> feedback from this group on that we could start on this list or
> something?
>=20
> I'm just trying to be realistic about the outcomes of this draft - we
> could discuss it in RTCWeb for 3 meetings before proposing a  TURN
> extension in behave but in the end I suspect we could just short
> circuit all that.
>=20
>=20
> On Jul 12, 2013, at 8:17 AM, "Hutton, Andrew" <andrew.hutton@siemens-
> enterprise.com> wrote:
>=20
> > What we want to discuss is a solution to the HTTP (Proxy) only FW use
> case as described in http://tools.ietf.org/html/draft-ietf-rtcweb-use-
> cases-and-requirements-11#section-3.2.3. This is not solved by the
> current specs.
> >
> > The draft http://tools.ietf.org/html/draft-hutton-rtcweb-nat-
> firewall-considerations-01 proposes a solution based on using HTTP
> Connect and some other related browser best practice requirements but
> also discusses alternatives.
> >
> > We want to discuss solving this use case and hopefully get this draft
> adopted.
> >
> > Andy
> >
> >
> >
> >> -----Original Message-----
> >> From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]
> >> Sent: 12 July 2013 16:09
> >> To: Hutton, Andrew
> >> Cc: Ted Hardie; rtcweb@ietf.org
> >> Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues
> >>
> >>
> >> Can you get specific about exactly what you want to discuss? The
> >> current solution ins the specs uses ICE, STUN, TURN and works
> thorough
> >> many firewalls but not all. What change would you like to see?
> >>
> >> On Jul 12, 2013, at 2:01 AM, "Hutton, Andrew"
> <andrew.hutton@siemens-
> >> enterprise.com>
> >> wrote:
> >>
> >>> Regarding the FW traversal discussion then I still think we need a
> >> discussion in the RTCWEB WG and I hope to persuade the chairs that
> this
> >> is the case.
> >>>
> >>> We have requirements in the use case draft and charter items that
> >> need solutions and this is a real issue impacting RTCWeb trials
> today.
> >>>
> >>> Regards
> >>> Andy
> >>>
> >>>
> >>>
> >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> >> Behalf Of Ted Hardie
> >>> Sent: 11 July 2013 17:51
> >>> To: rtcweb@ietf.org
> >>> Cc: Cullen Jennings
> >>> Subject: [rtcweb] Draft agenda for IETF 87
> >>>
> >>> Greetings,
> >>>
> >>> Below is an initial draft agenda for the upcoming meeting.   Since
> we
> >> have not yet reached the draft deadline (which is the 15th), there
> may
> >> be new drafts or updates that result in changes.  We did already
> >> receive requests for NAT/Firewall traversal discussion, and the
> chairs
> >> will be working with the document authors to get them considered in
> the
> >> appropriate groups.
> >>>
> >>> As folks have probably noticed, we are meeting Thursday and Friday,
> >> after the MMUSIC sessions are complete (they are Tuesday and
> >> Wednesday). This should allow us to discuss the results on our first
> >> day.
> >>>
> >>> Please send feedback or change proposals to the list.
> >>>
> >>> thanks,
> >>>
> >>> Ted and Cullen
> >>>
> >>> Day 1:
> >>>
> >>> Should SDES be part of  WebRTC security practice and, if so, how?
> >>> Presentations: 30 minutes
> >>> Discussion:  40 minutes
> >>>
> >>> Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents
> >>> Presentation: 30 minutes
> >>> Discussion: 30 minutes
> >>>
> >>> Security document updates
> >>> Presentation: 10 minutes
> >>> Discussion: 10 minutes
> >>>
> >>> Day 2:
> >>>
> >>> Chair Discussion:  10 minutes
> >>>
> >>> Use Case Requirements updates:
> >>> Issues list presentation: 20 minutes
> >>> Discussion: 20 minutes
> >>>
> >>> Data channel:
> >>> Issues list presentation:  45 minutes
> >>> Discussion: 45 minutes
> >>>
> >>>
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb

