Subject: [tram] About that charter...

From: Simon Perreault <[email-masked]>
Date: Fri, 22 Nov 2013 10:14:55 -0500

Are we done discussing it? What are the next steps?

As a reminder, the current version is here:
https://github.com/petithug/tram-charter/blob/master/charter.txt

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 26 Nov 2013 09:03:14 +0000

Hi,

> https://github.com/petithug/tram-charter/blob/master/charter.txt
I think the charter looks good.

Being a new-bee regarding charters I have a few questions and comments.

The first section is rather long and describes the background in length. Is the text in the first section at all necessary in a charter?

Can we add something around cloud in section three? For example:
“ — that make STUN and TURN more suitable for WebRTC and Cloud like
environments.”

TRAM would also benefit more traditional enterprise deployments. By using the word “cloud” the charter can get some attention from that camp as well.

Consider these comments as nits. 

.-.
Pål-Erik

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Tue, 26 Nov 2013 09:08:16 +0000

Hi Pal,

>-----Original Message-----
>From: tram [mailto:[email-masked]] On Behalf Of Pal Martinsen
>(palmarti)
>Sent: Tuesday, November 26, 2013 5:03 PM
>To: Simon Perreault
>Cc: [email-masked]
>Subject: Re: [tram] About that charter...
>
>Hi,
>
>The first section is rather long and describes the background in length. Is the
>text in the first section at all necessary in a charter?
>
>" - that make STUN and TURN more suitable for WebRTC and Cloud like
>environments."
>
>TRAM would also benefit more traditional enterprise deployments. By using the
>word "cloud" the charter can get some attention from that camp as well.
>

 Could you give some detailed requirements and considerations about the "cloud"?that will be more helpful. It will be better this could be get benefit from or affect the deliverables.
 
Best Regards,
     Xin

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 26 Nov 2013 01:20:37 -0800

If we add word "porn" it will attract even more attention.

For many engineers, "cloud" is a non-technical term, for managers only. But
this is supposed to be a very technical list.

On Tue, Nov 26, 2013 at 1:03 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

> The first section is rather long and describes the background in length.
> Is the text in the first section at all necessary in a charter?
>
> TRAM would also benefit more traditional enterprise deployments. By using
> the word “cloud” the charter can get some attention from that camp as well.
>

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 26 Nov 2013 09:27:11 +0000

> Could you give some detailed requirements and considerations about the "cloud"?that will be more helpful. It will be better this could be get benefit from or affect the deliverables.
You are right about cloud being a bit fuzzy, and it might not bee a good idea to add buzzwords to the charter. 

My goal was to add a word or short sentence getting the attention of the more traditional enterprise folks. As the charter describes in the first section ICE and TURN was slow to be adopted. Adding security, authentication, manageability, mobility ,QoS  ++ extensions to TURN will hopefully lead to more enterprises deploying TURN. Getting more “feature” parity between enterprise and RTCWEB deployment would benefit all. Having some wording stating that this is also intended for enterprise might help.

This is just word smithing to avoid enterprise folks that just see a red flag whenever RTCWEB is mentioned to be more happy. 

.-.
Pål-Erik

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 26 Nov 2013 09:33:34 +0000

On 26 Nov 2013, at 10:20 am, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:

:-)
More attention or deployments?

For many engineers, "cloud" is a non-technical term, for managers only. But this is supposed to be a very technical list.

Agree. But it still be nice with some wording to get the more traditional enterprise folks onboard.

.-.
Pål-Erik

On Tue, Nov 26, 2013 at 1:03 AM, Pal Martinsen (palmarti) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

.-.
Pål-Erik

> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca<http://postellation.viagenie.ca/>
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca<http://ecdysis.viagenie.ca/>
> STUN/TURN server               --> http://numb.viagenie.ca<http://numb.viagenie.ca/>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 26 Nov 2013 01:35:04 -0800

I am not sure that we want here anybody for whom WebRTC is a red flag. I am
not sure that we can have a healthy discussion here, then.

I think that WebRTC behind all this TURN evolution. We are not going to
sneak TURN into the enterprise; the enterprise will adopt WebRTC - and this
is how TURN will be included into the enterprise infrastructure. I believe
that this is the only realistic scenario of TURN inclusion into the
enterprise.

On Tue, Nov 26, 2013 at 1:27 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

> >> On 22 Nov 2013, at 16:14 pm, Simon Perreault <
> [email-masked]>
> >> wrote:
> >>
> > Could you give some detailed requirements and considerations about the
> "cloud"?that will be more helpful. It will be better this could be get
> benefit from or affect the deliverables.
> >
> My goal was to add a word or short sentence getting the attention of the
> more traditional enterprise folks. As the charter describes in the first
> section ICE and TURN was slow to be adopted. Adding security,
> authentication, manageability, mobility ,QoS  ++ extensions to TURN will
> hopefully lead to more enterprises deploying TURN. Getting more “feature”
> parity between enterprise and RTCWEB deployment would benefit all. Having
> some wording stating that this is also intended for enterprise might help.
>
> This is just word smithing to avoid enterprise folks that just see a red
> flag whenever RTCWEB is mentioned to be more happy.
>
> .-.
> Pål-Erik
>
> > Best Regards,
> >     Xin
> >
> >>
> >> .-.
> >> Pål-Erik
> >>
> >>
> >>> Simon
> >>> --

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 26 Nov 2013 01:39:08 -0800

On Tue, Nov 26, 2013 at 1:33 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

>
>
>
>  For many engineers, "cloud" is a non-technical term, for managers only.
> But this is supposed to be a very technical list.
>

That's fine, unless it sounds like "cloud-ready hard disks" or similar.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 26 Nov 2013 14:13:45 +0000

On: 26 November 2013 09:27 Pal Martinsen Wrote:
> 
> My goal was to add a word or short sentence getting the attention of
> the more traditional enterprise folks. 

Not sure what is meant by "more traditional enterprise folks" but I think the group will get the attention it needs.

> As the charter describes in the
> first section ICE and TURN was slow to be adopted. Adding security,
> authentication, manageability, mobility ,QoS  ++ extensions to TURN
> will hopefully lead to more enterprises deploying TURN. 
>

Many of the items mentioned here are actually not in the charter (i.e. manageability, mobility, QoS) and I also heard one the "traditional enterprise folks" talking about bandwidth management which is also not currently in the charter.  So maybe we need some more work on the charter or maybe what we need is to put together a requirements document and make that the first milestone.

> Getting more
> "feature" parity between enterprise and RTCWEB deployment would benefit
> all. Having some wording stating that this is also intended for
> enterprise might help.
>

I don't know what is meant by "feature parity between enterprise and RTCWEB" but I would support a statement in the charter indicating that the work of the group will include adding functionality to TURN to allow the TURN server to enforce policy on WebRTC traffic such as those typically required in an enterprise deployment.

> 
> This is just word smithing to avoid enterprise folks that just see a
> red flag whenever RTCWEB is mentioned to be more happy.
> 

Such folks should be and deserve to be ignored ;-).

Regards
Andy

---

From: Simon Perreault <[email-masked]>
Date: Tue, 26 Nov 2013 09:18:19 -0500

Le 2013-11-26 09:13, Hutton, Andrew a écrit :
>> As the charter describes in the first section ICE and TURN was slow
>> to be adopted. Adding security, authentication, manageability,
>> mobility ,QoS  ++ extensions to TURN will hopefully lead to more
>> enterprises deploying TURN.
>
> Many of the items mentioned here are actually not in the charter
> (i.e. manageability, mobility, QoS) and I also heard one the
> "traditional enterprise folks" talking about bandwidth management
> which is also not currently in the charter.  So maybe we need some
> more work on the charter or maybe what we need is to put together a
> requirements document and make that the first milestone.

Creating a working group is not a PR stunt. We have people here who want 
to work on real problems. So we write a charter about those problems and 
the work that needs to be done. It's as simple as that.

If/when new people come to this group with "enterprise" problems, 
solution proposals, and the energy to work on it, I'll be happy to 
propose a recharter to include the new stuff.

Any charter should always be about stuff we know we can and will fix.

Simon

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 26 Nov 2013 14:33:56 +0000

Hi Simon,

I was simply pointing out that many of the items Pal seemed to assume the group would cover are not in the charter.

However creating a charter is never that simple and we are already aware of work that people want to do in this group which is not explicitly mentioned in the charter.  

So when somebody comes to the group with a draft on adding some kind of bandwidth parameter to TURN then I would be preferable for this to be a matter of adding a new milestone rather than rewriting the charter. The charter should not be so closed that it can be used to argue against other ideas being put forward otherwise we will end up with a TRAM2 and a TRAM3 working group.

Regards
Andy

> From: Simon Perreault [mailto:[email-masked]]
> Sent: 26 November 2013 14:18
> To: Hutton, Andrew; Pal Martinsen (palmarti); Chenxin (Xin)
> Cc: [email-masked]

---

From: Michael Hammer <[email-masked]>
Date: Tue, 26 Nov 2013 14:48:52 +0000

Could you clarify whether the "cloud" elements are 

part of the problem (apps in cloud will find themselves behind restrictive
NATs) or 

part of the solution (TURN servers hosted in the cloud) or 

an innocent bystander collateral damage (cloud users or suppliers need to do
something)?

Mike

From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Tuesday, November 26, 2013 4:39 AM
To: Pal Martinsen (palmarti)
Cc: Simon Perreault; [email-masked]
Subject: Re: [tram] About that charter...

On Tue, Nov 26, 2013 at 1:33 AM, Pal Martinsen (palmarti)
<[email-masked]> wrote:

Agree. But it still be nice with some wording to get the more traditional
enterprise folks onboard.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 26 Nov 2013 05:59:26 -0900

On 11/26/13 12:03 AM, Pal Martinsen (palmarti) wrote:
> TRAM would also benefit more traditional enterprise deployments. By
> using the word “cloud” the charter can get some attention from that
> camp as well.

I think that if there's interest in enterprise deployments it's
probably a good idea, in terms of getting the charter through
the process, to spell out explicitly which features would
be needed, distinct from a CPE deployment.  I tend to think
that targeting enterprises *right now* would be a mistake,
since they're the ones who tend to have the most rigid policies
around network boundary traversal and those policies are
often driven out of the corporate auditor's department.
I'd let webrtc lead the deployment and have network administrators
discover that they've got a problem.

Melinda

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 26 Nov 2013 15:59:38 +0000

I agree.

Gonzalo

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 26 Nov 2013 16:20:11 +0000

> discover that they've got a problem.

What do you mean by "let webrtc lead the deployment"?

WebRTC specifically includes deployments where the webrtc client is behind firewalls this is explicit in the charter and http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12 which also explicitly mentions restricted enterprise deployments. 

Personally I would like to start developing the tools and provide information to help network administrators before they discover they have a problem with webrtc.

Andy

---

From: Melinda Shore <[email-masked]>
Date: Tue, 26 Nov 2013 07:28:18 -0900

On 11/26/13 7:20 AM, Hutton, Andrew wrote:
> Personally I would like to start developing the tools and provide
> information to help network administrators before they discover they
> have a problem with webrtc.

Do you need specific reference to enterprise deployments
to do that?  I didn't think so.  In the meantime, if
you go out there and tell people who are dealing with
corporate policies driven out of the auditor's office that
you're going to poke holes in their firewalls using a
mechanism that's not managed under enterprise security
policy, you're going to hit resistance before you even
start.  As you may have noticed.

I'd leave any reference to enterprise networks out of the
charter.

Melinda

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 26 Nov 2013 16:47:44 +0000

On: 26 November 2013 16:28 Melinda Shore Wrote:
> to do that?  I didn't think so.  

I agree but we need the charter to broad enough to include putting some policy control in to the TURN server and to be clear I am not talking about firewall policy here. Just some things that have previously been mentioned like bandwidth, QoS, Mobility, and some things we might not have thought of yet.

> In the meantime, if

Also agree this is not about poking holes in firewalls and the work to define how webrtc works properly within an enterprise security policy will evidently not take place in this working group, we still need a home for that.

> I'd leave any reference to enterprise networks out of the

I am ok with that.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 26 Nov 2013 11:50:02 -0500

> I agree but we need the charter to broad enough to include putting some policy control in to the TURN server and to be clear I am not talking about firewall policy here. Just some things that have…

Please propose actual text changes. The current charter is at

Just say exactly how you would like to see it changed. The RFC Editor 
notation "OLD:... NEW:..." would be fine.

Thanks,
Simon

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 26 Nov 2013 11:02:23 -0600

I'm not speaking as an AD, but I am speaking as a retired IAB member who
was watching a year-long effort to charter something (well, really,
anything) in the cloud space.

My suggestion would be to figure out specifically what part of "cloud" is
relevant to what you're proposing, and point to something more specific.
For example, the data center parts of "cloud" started getting more traction
when they were called out specifically.

The IESG (at that time) wasn't opposed to doing something that would be
helpful for clouds, but they weren't getting proposals for specific
protocol work, and that's pretty much what the IETF does ...

Spencer

On Tuesday, November 26, 2013, Oleg Moskalenko wrote:

> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>wrote:
>
>> Hi,
>>
>> On 22 Nov 2013, at 16:14 pm, Simon Perreault <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
>> wrote:
>>
>> > [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
>> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Nov 2013 09:16:04 -0800

> Also agree this is not about poking holes in firewalls and the work to define how webrtc works properly within an enterprise security policy will evidently not take place in this working group, we…

I'm still trying to understand if we can reasonably expect to find a 
home for that discussion, or if we are being told "the IETF doesn't talk 
about that".

In any case, I don't especially care to have a discussion of anybody's 
security policies. But we might talk about things that will be affected 
by, and provide input to, the application of security policies.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 26 Nov 2013 17:25:05 +0000

Actually I was reasonably happy with the charter as it was until it was stated that the current list of deliverables was part of the charter rather than being draft milestones and therefore adding to the list would need a charter update. As I am often told that adding milestones is a whole lot easier than updating the charter text.

Is it the case that the list of deliverables is proposed to be part of the charter or are they just draft milestones?

I assumed they were draft milestones as mentioning drafts in the charter is something I don't think I have seen before.

If I were to propose any change to the actual charter text then maybe I would modify the paragraph below to indicate that the work may also includes other extensions to TURN.

So change the following:

"The goal of the TRAM Working Group is to consolidate the various initiatives
to update TURN and STUN, including the definition of new transport and
authentication mechanisms that make STUN and TURN more suitable for the WebRTC
environment".  

To

"The goal of the TRAM Working Group is to consolidate the various initiatives
to update TURN and STUN, including the definition of new transport, 
authentication mechanisms, and extensions, that make STUN and TURN more suitable for the WebRTC
environment".  

Regards
Andy

> From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: 26 November 2013 16:50
> To: [email-masked]
> > I agree but we need the charter to broad enough to include putting
> some policy control in to the TURN server and to be clear I am not
> talking about firewall policy here. Just some things that have
> previously been mentioned like bandwidth, QoS, Mobility, and some
> things we might not have thought of yet.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Nov 2013 09:51:50 -0800

+1

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 26 Nov 2013 17:58:45 +0000

+1 

That's a reasonable addition.

Gonzalo

---

From: Simon Perreault <[email-masked]>
Date: Tue, 26 Nov 2013 13:28:26 -0500

> authentication mechanisms, and extensions, that make STUN and TURN more suitable for the WebRTC

Makes sense. Pull request sent to Marc.

Simon

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 26 Nov 2013 19:01:12 +0000

Can someone confirm that the deliverables

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 26 Nov 2013 19:03:35 +0000

So can someone confirm that the deliverables mentioned in the draft charter are actually draft milestones and not part of the charter text itself?

Sorry about last message.

Andy

---

From: Simon Perreault <[email-masked]>
Date: Tue, 26 Nov 2013 14:05:16 -0500

> So can someone confirm that the deliverables mentioned in the draft charter are actually draft milestones and not part of the charter text itself?

That's the intent, at least for me.

Simon

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 26 Nov 2013 19:51:02 +0000

They are milestones.  I suspect that before the charter is finalized we'll simply list the milestones and drop their individual summary text.

Gonzalo

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 26 Nov 2013 19:11:45 -0800

Spencer, this is how I view it, too. If we specify a particular part of the
"cloud" and if we define well what we are going to do about that, then it
will be fine. But then we even do not need the word "cloud". I think that
we already have a good-enough defined charter.

On Tue, Nov 26, 2013 at 9:02 AM, Spencer Dawkins at IETF <
[email-masked]> wrote:

>>> [email-masked]> wrote:
>>>
>>> using the word “cloud” the charter can get some attention from that camp as
>>> well.
>>>