Subject: [rtcweb] NAT/Firewall considerations (RE: I-D Action: draft-ietf-rtcweb-transports-00.txt)

From: <[email-masked]>
Date: Tue, 27 Aug 2013 12:53:02 +0000

Hi,

I would support the adoption of the NAT and Firewall considerations (http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01) as a WG document. Or to be more precise, I very much agree with the requirements summarized in Section 5. Especially this one seems important to me:

o  connect to a TURN server via a HTTP proxy using the HTTP connect

      method,

If we want WebRTC to work from many corporate networks I'm aware of, it would not be possible without this as a fallback capability.

Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Bernard Aboba
Sent: 21 August, 2013 00:44
To: Hutton, Andrew; [email-masked]; Harald Alvestrand
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt

The NAT/Firewall considerations document does go into detail on the various traversal scenarios, which helps inform the discussion of what should or should not be supported in terms of transport.  Section 5 summarizes the recommendations as follows:
5<http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01#section-5>.  Requirements for RTCWEB-enabled browsers

   For the purpose of relaying RTCWEB media streams or data channels a

   browser needs to be able to

   o  connect to a TURN server via UDP, TCP and TLS,

   o  connect to a TURN server via a HTTP proxy using the HTTP connect

      method,

   o  connect to a TURN server via the HTTP(s) ports 80/443 instead of

      the default STUN ports 3478/5349,

   o  upgrade the HTTP proxy-relayed connection to the TURN server to

      use TLS,

   o  use the same proxy selection procedure for TURN as currently done

      for HTTP,

   o  switch the usage of the HTTP proxy-relayed connection with the

      TURN server from HTTP to STUN/TURN,

   o  use a preconfigured or standardized port range for UDP-based media

      streams or data channels,

   o  learn from the proxy configuration script about the presence of a

      local TURN server and use it for sending UDP traffic to the

      internet,

   o  support ICE-TCP for TCP-based direct media connection to the

      RTCWEB peer.

> From: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Date: Tue, 20 Aug 2013 16:31:28 +0000
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
>
> Section 2.2 "Middle Box Related Functions" should also I assume cover the case of using a HTTP Proxy or an enterprise TURN server and reference http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01 assuming we can get this adopted.
>
> Regards
> Andy

---

From: Emil Ivov <[email-masked]>
Date: Tue, 27 Aug 2013 14:53:55 +0200

+1

Emil

On Tue, Aug 27, 2013 at 2:53 PM,  <[email-masked]> wrote:
> Hi,
>
>
>
> I would support the adoption of the NAT and Firewall considerations
> (http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01)
> as a WG document. Or to be more precise, I very much agree with the
> requirements summarized in Section 5. Especially this one seems important to
> me:
>
>
>
> If we want WebRTC to work from many corporate networks I’m aware of, it
> would not be possible without this as a fallback capability.
>
>
>
> Markus
>
>
>
>
>
>
>
> The NAT/Firewall considerations document does go into detail on the various
> traversal scenarios, which helps inform the discussion of what should or
> should not be supported in terms of transport.  Section 5 summarizes the
> recommendations as follows:
>
> 5.  Requirements for RTCWEB-enabled browsers
>
>
>
>
>
>> From: [email-masked]
>> To: [email-masked]; [email-masked]
>> Section 2.2 "Middle Box Related Functions" should also I assume cover the
>> case of using a HTTP Proxy or an enterprise TURN server and reference
>> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01
>> assuming we can get this adopted.
>>
>> Regards
>> Andy
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: Victor Pascual <[email-masked]>
Date: Tue, 27 Aug 2013 16:34:37 +0200

I agree

-Victor

On Aug 27, 2013, at 2:53 PM, <[email-masked]> wrote:

> If we want WebRTC to work from many corporate networks I’m aware of, it would not be possible without this as a fallback capability.
>  
> Markus
>  
>  
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 27 Aug 2013 09:47:13 -0500

Another +1.

Mary.

On Tue, Aug 27, 2013 at 7:53 AM, <[email-masked]> wrote:

>  Hi,****
>
> ** **
>
> I would support the adoption of the NAT and Firewall considerations (
> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01)
> requirements summarized in Section 5. Especially this one seems important
> to me:****
>
> ** **
>
> o  connect to a TURN server via a HTTP proxy using the HTTP connect****
>
>       method,****
>
> ** **
>
> would not be possible without this as a fallback capability.****
>
> ** **
>
> Markus****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *ext Bernard Aboba
> *Sent:* 21 August, 2013 00:44
> *To:* Hutton, Andrew; [email-masked]; Harald Alvestrand
> *Subject:* Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt***
> *
>
> ** **
>
> The NAT/Firewall considerations document does go into detail on the
> various traversal scenarios, which helps inform the discussion of what
> should or should not be supported in terms of transport.  Section 5
> summarizes the recommendations as follows: ****
> 5<http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01#section-5>.
> Requirements for RTCWEB-enabled browsers****
>
> ** **
>
> ** **
>
>    For the purpose of relaying RTCWEB media streams or data channels a****
>
>    browser needs to be able to****
>
> ** **
>
>    o  connect to a TURN server via UDP, TCP and TLS,****
>
> ** **
>
>    o  connect to a TURN server via a HTTP proxy using the HTTP connect****
>
>       method,****
>
> ** **
>
>    o  connect to a TURN server via the HTTP(s) ports 80/443 instead of****
>
>       the default STUN ports 3478/5349,****
>
> ** **
>
>    o  upgrade the HTTP proxy-relayed connection to the TURN server to****
>
>       use TLS,****
>
> ** **
>
>    o  use the same proxy selection procedure for TURN as currently done****
>
>       for HTTP,****
>
> ** **
>
>    o  switch the usage of the HTTP proxy-relayed connection with the****
>
>       TURN server from HTTP to STUN/TURN,****
>
> ** **
>
>    o  use a preconfigured or standardized port range for UDP-based media****
>
>       streams or data channels,****
>
> ** **
>
>    o  learn from the proxy configuration script about the presence of a****
>
>       local TURN server and use it for sending UDP traffic to the****
>
>       internet,****
>
> ** **
>
>    o  support ICE-TCP for TCP-based direct media connection to the****
>
>       RTCWEB peer.****
>
> ** **
>
> > Section 2.2 "Middle Box Related Functions" should also I assume cover
> the case of using a HTTP Proxy or an enterprise TURN server and reference
> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01assuming we can get this adopted.
> >
> > Regards
> > Andy****
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 27 Aug 2013 16:48:50 +0200

+1 a must have to be able doing any serious business with webrtc..

El 27/08/2013 16:34, Victor Pascual escribió:
> I agree
>
> -Victor
>
> On Aug 27, 2013, at 2:53 PM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi,
>>
>> requirements summarized in Section 5. Especially this one seems 
>> important to me:
>>
>> If we want WebRTC to work from many corporate networks I'm aware of, 
>> it would not be possible without this as a fallback capability.
>>
>> Markus
>>
>> *From:[email-masked] <mailto:[email-masked]> 
>> [mailto:[email-masked]] *On Behalf Of *ext Bernard Aboba
>> *To:* Hutton, Andrew; [email-masked] <mailto:[email-masked]>; 
>> Harald Alvestrand
>> *Subject:* Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
>>
>> various traversal scenarios, which helps inform the discussion of 
>> what should or should not be supported in terms of transport.  
>> Section 5 summarizes the recommendations as follows:
>>
>>
>>     5
>>     <http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01#section-5>.
>>     Requirements for RTCWEB-enabled browsers
>>
>>   
>>   
>> <mailto:[email-masked]>
>> > To: [email-masked] <mailto:[email-masked]>; [email-masked] 
>> <mailto:[email-masked]>
>> > Section 2.2 "Middle Box Related Functions" should also I assume 
>> cover the case of using a HTTP Proxy or an enterprise TURN server and 
>> reference 
>> [email-masked] <mailto:[email-masked]>

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 27 Aug 2013 16:52:30 +0200

+1

On 8/27/13 2:53 PM, [email-masked] wrote:
> *From:[email-masked] [mailto:[email-masked]] *On 
> summarizes the recommendations as follows:
>
>
>     5

---

From: Alan Johnston <[email-masked]>
Date: Tue, 27 Aug 2013 09:55:46 -0500

Agree that enterprises need this plus a few other TURN extensions. 

I support adoption as WG draft. 

- Alan -

---

From: "Avasarala, Ranjit (NSN - IN/Bangalore)" <[email-masked]>
Date: Tue, 27 Aug 2013 16:03:38 +0000

I too agree that this functionality is required for enterprises where devices could be behind NAT. But in IMS we may not need as UEs are globally reachable.

Regards
Ranjit
Sent from Nokia Lumia
________________________________
From: ext [email-masked]<mailto:[email-masked]>
Sent: ‎27-‎08-‎2013 18:23
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] NAT/Firewall considerations (RE: I-D Action: draft-ietf-rtcweb-transports-00.txt)

Hi,

      method,

Markus

      method,

      use TLS,

      for HTTP,

      internet,

      RTCWEB peer.

---

From: "cb.list6" <[email-masked]>
Date: Tue, 27 Aug 2013 09:05:03 -0700

The I-D says this

"As last resort in order to cater

   for NAT/FWs with address and port dependent filtering characteristics"

What is the first resort?

<ascending soap box>

Specifically, i would like the document to say that end points and
intermediate systems should support IPv6 and attempt IPv6
connectivity...which means they must support IPv6.

IPv6 is a middle box / NAT avoidance mechanism, but these early days
of WebRTC show no support for IPv6.

https://bugzilla.mozilla.org/show_bug.cgi?id=797262

The draft should explicitly describe that secure e2e connectivity
should be attempted first with all address families, not short cuts
that make WebRTC more fragile by relying on middle boxes (TURN).

I am not opposed to this draft, and find TURN to be a useful way to
police traffic and bridge disparate address families, but it is a
slippery slope where we try to avoid one middle box with another.

CB

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 27 Aug 2013 16:27:14 +0000

> If we want WebRTC to work from many corporate networks I’m aware of, it would not be possible without this as a fallback capability.

Have you tried if this work with your corporate firewalls? We are trying to get more information about that and info about if the TURN server needs to run on the TURN port or port 443. 

Thanks, Cullen with my co chair hat on. PS - Real Soon Now we are going to ask people to move this diction to a separate list so that others can follow it without having to wade through all the rtcweb traffic.

---

From: Mary Barnes <[email-masked]>
Date: Tue, 27 Aug 2013 11:34:15 -0500

On Tue, Aug 27, 2013 at 11:27 AM, Cullen Jennings (fluffy) <[email-masked]
> wrote:

> to me:
> Have you tried if this work with your corporate firewalls? We are trying
> to get more information about that and info about if the TURN server needs
> to run on the TURN port or port 443.
>
> Thanks, Cullen with my co chair hat on. PS - Real Soon Now we are going to
> ask people to move this diction to a separate list so that others can
> follow it without having to wade through all the rtcweb traffic.
>
[MB] I'm slightly puzzled by this suggestion.  Are you suggesting that any
discussion of the hutton rtcweb draft (which is being proposed as WG item
should be on a separate mailing list?  Or are you referring to more general
discussions or are you considering this to be a more WebRTC discussion?
There's not been at all a huge amount of discussion on this RTCWEB mailing
list that I find it to be overload. I personally find the cross postings to
the W3C list and this mailing list to generate a whole lot of extra email
in my mailbox. [/MB]

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 27 Aug 2013 17:57:01 +0000

On Aug 27, 2013, at 10:34 AM, Mary Barnes <[email-masked]> wrote:

> 
> 
> 
> On Tue, Aug 27, 2013 at 11:27 AM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> 
> [MB] I'm slightly puzzled by this suggestion.  Are you suggesting that any discussion of the hutton rtcweb draft (which is being proposed as WG item should be on a separate mailing list?  Or are you referring to more general discussions or are you considering this to be a more WebRTC discussion?   There's not been at all a huge amount of discussion on this RTCWEB mailing list that I find it to be overload. I personally find the cross postings to the W3C list and this mailing list to generate a whole lot of extra email in my mailbox. [/MB]
> 

Yes, I am asking that the discussion of how webrtc clients, proxies, NATs and TURN servers interact is done on the  [email-masked] list. 

You can go here to sign up at:
https://www.ietf.org/mailman/listinfo/pntaw

That includes the draft-hutton-rtcweb-nat-firewall-considerations draft and the topic of it it should be adopted by the rtcweb WG. That list was created more or less for that draft. 

The reason we want it on a seperate list is people such as security folks that do not currently subscribe to rtcweb@ietf want to be able to follow the firewall discussions without having to deal with the volume of email we sometimes see on rtcweb. 

Thanks. Cullen (with my co-chair hat on)

---

From: Mary Barnes <[email-masked]>
Date: Tue, 27 Aug 2013 12:58:06 -0500

Thanks for the clarification.  Your last point explains the logic to me and
I do agree.

Mary.

On Tue, Aug 27, 2013 at 12:57 PM, Cullen Jennings (fluffy) <[email-masked]

> > > If we want WebRTC to work from many corporate networks I’m aware of,
> > Thanks, Cullen with my co chair hat on. PS - Real Soon Now we are going
> to ask people to move this diction to a separate list so that others can
> > [MB] I'm slightly puzzled by this suggestion.  Are you suggesting that
> any discussion of the hutton rtcweb draft (which is being proposed as WG
> item should be on a separate mailing list?  Or are you referring to more
> general discussions or are you considering this to be a more WebRTC
> discussion?   There's not been at all a huge amount of discussion on this
> RTCWEB mailing list that I find it to be overload. I personally find the
> cross postings to the W3C list and this mailing list to generate a whole
> lot of extra email in my mailbox. [/MB]
> >
>
> Yes, I am asking that the discussion of how webrtc clients, proxies, NATs
> and TURN servers interact is done on the  [email-masked] list.
>
> That includes the draft-hutton-rtcweb-nat-firewall-considerations draft
> and the topic of it it should be adopted by the rtcweb WG. That list was
> created more or less for that draft.
>
> The reason we want it on a seperate list is people such as security folks
> that do not currently subscribe to rtcweb@ietf want to be able to follow
> the firewall discussions without having to deal with the volume of email we
> sometimes see on rtcweb.
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Aug 2013 11:04:10 -0700

> Yes, I am asking that the discussion of how webrtc clients, proxies, NATs and TURN servers interact is done on the  [email-masked] list.

Can I request that you send a brief summary of what you believe to be
the scope of this discussion?

It seems obvious that draft-hutton-rtcweb-nat-firewall-considerations
fits here.  Does draft-uberti-behave-turn-rest also belong, or is the
behave WG looking after that now?

--Martin

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 27 Aug 2013 18:37:44 +0000

On Aug 27, 2013, at 12:04 PM, Martin Thomson <[email-masked]> wrote:

>  Doesdraft-uberti-behave-turn-restalso belong, or is the

Good question - I don't really know. My leaning is that the discussion of draft-uberti-behave-turn-rest could also be on this new list. Any objections to that?

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 28 Aug 2013 04:44:34 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> cb.list6
> Sent: Tuesday, August 27, 2013 9:35 PM
> To: Alan Johnston
> Cc: <[email-masked]>
> Subject: Re: [rtcweb] NAT/Firewall considerations (RE: I-D Action: draft-ietf-
> rtcweb-transports-00.txt)
> 
> The I-D says this
> 

Yes, this method may not work with Enterprises that use Firewalls that perform DPI on HTTP, detect port misuse etc and for HTTPS either act as TLS Proxy or monitor the TLS handshake for valid certificates etc. Enterprises in addition to firewalls also could use cloud connector which re-directs HTTP/HTTPS traffic to cloud based "Security As A Service" for DPI, reputation based filtering etc.
 
-Tiru.

> > If we want WebRTC to work from many corporate networks I'm aware of, it

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 28 Aug 2013 10:11:01 +0000

I am not convinced that moving the work to another mailing list is really useful I think it just creates confusion and probably there will be a lot of cross post between RTCWEB and PNTAW.

But if it gets things moving then I am ok with it.

What I would ask is that the chairs post a mail to RTCWEB and PNTAW which clearly describes the purpose of the new mailing list.

Regards
Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 27 August 2013 18:58
To: Cullen Jennings (fluffy)
Cc: [email-masked]
Subject: Re: [rtcweb] NAT/Firewall considerations (RE: I-D Action: draft-ietf-rtcweb-transports-00.txt)

Thanks for the clarification.  Your last point explains the logic to me and I do agree.

Mary.

On Tue, Aug 27, 2013 at 12:57 PM, Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> wrote:

On Aug 27, 2013, at 10:34 AM, Mary Barnes <[email-masked]<mailto:[email-masked]>> wrote:

>
>
>
> On Tue, Aug 27, 2013 at 11:27 AM, Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Aug 27, 2013, at 6:53 AM, [email-masked]<mailto:[email-masked]> wrote:
>
> > Hi,
> >
Yes, I am asking that the discussion of how webrtc clients, proxies, NATs and TURN servers interact is done on the  [email-masked]<mailto:[email-masked]> list.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 28 Aug 2013 14:34:59 +0000

Andy, 

Lets review the history here. At the last IETF, the chairs blocked out time to meet with you and we  talked about several ways forward and asked what you wanted. You made it clear you were OK with this plan. Given we went and did exactly what we discussed then after running it by various ADs and others, why exactly are you complaining about this now ?

On Aug 28, 2013, at 4:11 AM, "Hutton, Andrew" <[email-masked]> wrote:

> On Tue, Aug 27, 2013 at 12:57 PM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> 
> Yes, I am asking that the discussion of how webrtc clients, proxies, NATs and TURN servers interact is done on the  [email-masked].
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 28 Aug 2013 14:45:10 +0000

Hi Cullen,

Just expressing my opinion that multiple mailing lists don't really help here but hopefully I will be proved wrong. The important thing is to make some progress.

The plan we have ended up with was certainly not my first choice but I am happy that there is now a plan in place and we can move on.

Regards
Andy

> From: Cullen Jennings (fluffy) [mailto:[email-masked]]
> Sent: 28 August 2013 15:35
> To: Hutton, Andrew
> Cc: [email-masked]
> Lets review the history here. At the last IETF, the chairs blocked out
> time to meet with you and we  talked about several ways forward and
> asked what you wanted. You made it clear you were OK with this plan.
> Given we went and did exactly what we discussed then after running it
> by various ADs and others, why exactly are you complaining about this
> now ?
> 
> 
> 
> 
> 
> 
> > I am not convinced that moving the work to another mailing list is
> really useful I think it just creates confusion and probably there will
> be a lot of cross post between RTCWEB and PNTAW.
> >
> > What I would ask is that the chairs post a mail to RTCWEB and PNTAW
> which clearly describes the purpose of the new mailing list.
> >
> > Regards
> > Andy
> >
> >
> > > > I would support the adoption of the NAT and Firewall
> considerations (http://tools.ietf.org/html/draft-hutton-rtcweb-nat-
> firewall-considerations-01) as a WG document. Or to be more precise, I
> very much agree with the requirements summarized in Section 5.
> Especially this one seems important to me:
> > > >
> > > > If we want WebRTC to work from many corporate networks I'm aware
> of, it would not be possible without this as a fallback capability.
> > > >
> > > > Markus
> > > >
> > > >
> > >
> > > Have you tried if this work with your corporate firewalls? We are
> trying to get more information about that and info about if the TURN
> server needs to run on the TURN port or port 443.
> > >
> > > Thanks, Cullen with my co chair hat on. PS - Real Soon Now we are
> going to ask people to move this diction to a separate list so that
> others can follow it without having to wade through all the rtcweb
> traffic.
> > > [MB] I'm slightly puzzled by this suggestion.  Are you suggesting
> that any discussion of the hutton rtcweb draft (which is being proposed
> as WG item should be on a separate mailing list?  Or are you referring
> to more general discussions or are you considering this to be a more
> WebRTC discussion?   There's not been at all a huge amount of
> discussion on this RTCWEB mailing list that I find it to be overload. I
> personally find the cross postings to the W3C list and this mailing
> list to generate a whole lot of extra email in my mailbox. [/MB]
> > >
> >
> > Yes, I am asking that the discussion of how webrtc clients, proxies,
> NATs and TURN servers interact is done on the  [email-masked].
> >
> > That includes the draft-hutton-rtcweb-nat-firewall-considerations
> draft and the topic of it it should be adopted by the rtcweb WG. That
> list was created more or less for that draft.
> >
> > The reason we want it on a seperate list is people such as security
> folks that do not currently subscribe to rtcweb@ietf want to be able to
> follow the firewall discussions without having to deal with the volume
> of email we sometimes see on rtcweb.
> >

---

From: Mary Barnes <[email-masked]>
Date: Wed, 28 Aug 2013 10:24:47 -0500

I have a couple questions for clarification.  My understanding of the new
list is that it will provide a more targeted venue for these discussions
and allow folks that don't want their mailbox to be filled up with other
RTCWEB stuff to be engaged in the discussions (e.g., security and I would
think some of the BEHAVE guys).  Is that correct?   I'm assuming that since
this new list is a non-WG list that there are no binding decisions made in
that group, but rather any common agreements on that mailing list MUST be
vetted and any documents, etc MUST be approved in the RTCWEB WG. Is that
correct?

Thanks,
Mary.

On Wed, Aug 28, 2013 at 9:45 AM, Hutton, Andrew <
[email-masked]> wrote:

> Hi Cullen,
>
> Just expressing my opinion that multiple mailing lists don't really help
> here but hopefully I will be proved wrong. The important thing is to make
> some progress.
>
> The plan we have ended up with was certainly not my first choice but I am
> happy that there is now a plan in place and we can move on.
>
> Regards
> Andy
>
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 29 Aug 2013 09:32:14 +0000

On: 28 August 2013 16:25 Mary Barnes wrote:

> 
> I have a couple questions for clarification.  My understanding of the
> new list is that it will provide a more targeted venue for these
> discussions and allow folks that don't want their mailbox to be filled
> up with other RTCWEB stuff to be engaged in the discussions (e.g.,
> security and I would think some of the BEHAVE guys).  Is that correct?
>   I'm assuming that since this new list is a non-WG list that there are
> no binding decisions made in that group, but rather any common
> agreements on that mailing list MUST be vetted and any documents, etc
> MUST be approved in the RTCWEB WG. Is that correct?
> 

This refers to the new "pntaw" mailing list and in a previous message Cullen Jennings stated: 

> NATs and TURN servers interact is done on the  [email-masked] list.
> 
> and the topic of it it should be adopted by the rtcweb WG. That list
> was created more or less for that draft.
> 

The purpose of the pntaw mailing list as I see it is therefore is to allow us to come to a point when we can make a decision on how the solution to the issue of how webrtc browsers interact with web proxies, NAT/Firewalls and TURN servers and this includes deciding on whether to adopt draft-hutton-rtcweb-nat-firewall-considerations.

There is of course some overlap here with other areas and wg's like SEC, behave, and httpbis so if the chairs and AD's think a new list is the way forward then ok but I hope the goal is to make a decision on what solution to adopt sometime soon.

Andy

---

From: Mary Barnes <[email-masked]>
Date: Thu, 29 Aug 2013 10:08:55 -0500

> This refers to the new "pntaw" mailing list and in a previous message
[MB] I was aware of that, but I interpreted the "should be adopted" as more
of a recommendation from the non-WG mailing list as opposed to a binding
RTCWEB WG decision. [/MB]

> The purpose of the pntaw mailing list as I see it is therefore is to allow
> us to come to a point when we can make a decision on how the solution to
> the issue of how webrtc browsers interact with web proxies, NAT/Firewalls
> and TURN servers and this includes deciding on whether to adopt
> draft-hutton-rtcweb-nat-firewall-considerations.
>

 [MB] So I missed the subtlety in Cullen's initial post that the
expectation is that the decision whether or not to accept your draft is
being made on a non-WG mailing list.  I don't think that's the right thing
to do.   I can agree that folks on pntaw can make a recommendation to
RTCWEB, but that needs to be fully documented and then the decision to
adopt a document  for the WG deliverable should be made on the WG mailing
list. Not everyone on the RTCWEB mailing list will subscribe to pntaw, so I
can't see how a decision on behalf of the WG can be made on a non-WG
mailing list. [/MB]

 There is of course some overlap here with other areas and wg's like SEC,
> behave, and httpbis so if the chairs and AD's think a new list is the way
> forward then ok but I hope the goal is to make a decision on what solution
> to adopt sometime soon.
>
> Andy
>
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 Aug 2013 09:51:32 -0700

On Aug 29, 2013, at 8:11, "Mary Barnes" <[email-masked]> wrote:

> [MB] So I missed the subtlety in Cullen's initial post that the expectation is that the decision whether or not to accept your draft is being made on a non-WG mailing list.  I don't think that's the right thing to do.   I can agree that folks on pntaw can make a recommendation to RTCWEB, but that needs to be fully documented and then the decision to adopt a document  for the WG deliverable should be made on the WG mailing list. Not everyone on the RTCWEB mailing list will subscribe to pntaw, so I can't see how a decision on behalf of the WG can be made on a non-WG mailing list. [/MB]

[BA] I can certainly understand the desire to create a space where NAT/Firewall issues can be discussed, free of the high volume of other traffic on the RTCWEB list. However, with respect to decisions, this seems more akin to a Design Team effort which is brought back to a WG than an autonomous group with its own decision making capability. Ultimately the recommendations developed on this list need to be supported in WebRTC implementations if they are to have meaning. RTCWEB WG is probably the best group to determine consensus for that.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 30 Aug 2013 08:00:53 +0200

WG,

The new mailing list is a non-wg mailing list. It will be a good place
to discuss and resolve issues around any proposal. The outcome of such
discussion in form of documents still needs to be handled through the WG
process. Which WG that is will depended on the content of a particular
document. Clearly documents that falls within this WG's charter will be
handled here.

Cheers

Magnus

On 2013-08-29 18:51, Bernard Aboba wrote:
>> expectation is that the decision whether or not to accept your
>> draft is being made on a non-WG mailing list.  I don't think that's
>> the right thing to do.   I can agree that folks on pntaw can make a
>> recommendation to RTCWEB, but that needs to be fully documented and
>> then the decision to adopt a document  for the WG deliverable
>> should be made on the WG mailing list. Not everyone on the RTCWEB
>> mailing list will subscribe to pntaw, so I can't see how a decision
>> on behalf of the WG can be made on a non-WG mailing list. [/MB]
> 
> [BA] I can certainly understand the desire to create a space where
> NAT/Firewall issues can be discussed, free of the high volume of
> other traffic on the RTCWEB list. However, with respect to decisions,
> this seems more akin to a Design Team effort which is brought back to
> a WG than an autonomous group with its own decision making
> capability. Ultimately the recommendations developed on this list
> need to be supported in WebRTC implementations if they are to have
> meaning. RTCWEB WG is probably the best group to determine consensus
> for that.
> 
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------