Subject: [tram] WGLC draft-ietf-tram-alpn-00

From: Simon Perreault <[email-masked]>
Date: Wed, 10 Sep 2014 08:16:23 -0400

TRAMsters,

This email initiates a one-week working-group last call on this draft:

http://tools.ietf.org/html/draft-ietf-tram-alpn-00

Please read it now. Substantial comments should be addressed to the group.
Nits should be sent directly to the authors.

Thanks,
Simon & Gonzalo

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 10 Sep 2014 14:52:16 +0000

Folks,
We've just published a revision of draft-ietf-tram-alpn. Please consider the -01 version for WGLC review.

http://tools.ietf.org/html/draft-ietf-tram-alpn-01

Thanks,
Prashanth

From: Simon Perreault <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 10, 2014 5:46 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [tram] WGLC draft-ietf-tram-alpn-00

TRAMsters,

Please read it now. Substantial comments should be addressed to the group. Nits should be sent directly to the authors.

Thanks,
Simon & Gonzalo

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Sep 2014 13:33:33 -0700

> http://tools.ietf.org/html/draft-ietf-tram-alpn-00

-01 fails to address the comments on this thread:
http://www.ietf.org/mail-archive/web/tram/current/msg00687.html

The introduction needs some editorial work to trim it down.  Point 3
makes no sense at all to me, and there are grammatical errors in point
1.  However, I would take everything from after the first sentence of
the second paragraph and before the last paragraph and delete it.  A
small note about being able to identify the purpose of a flow without
initiating a session seems appropriate.

I still think that you want different ways to identify the various
forms: TURN/TLS, TURN/DTLS, TURN/TCP, TURN/UDP.  I realize that there
is some disagreement about that, but we've found this to be useful in
identifying a protocol outside of the context of its use elsewhere.
If you don't do that, please make sure that you explicitly enumerate
the protocols that this does identify fully.

This isn't ready.

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 10 Sep 2014 20:46:53 +0000

> initiating a session seems appropriate.

Point taken. We can trim it back.

> the protocols that this does identify fully.

This is something we have been kicking around recently and were thinking to put it out to the group to get consensus on. We were thinking perhaps it is best to define one label for each usage of STUN (as was done in Section 4 of RFC 7350) that may use (D)TLS, i.e. stun.turn, stun.nat-discovery, stun.nat-behavior-discovery, etc).  This feels like the right level of granularity for the label. If folks think it is useful we can even throw in a wildcard label (stun.*) as a catch all implying whatever STUN usage.  

Thoughts?

> This isn't ready.

We're happy to be agile and give it another quick pass. Thanks for the feedback.

-G

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Sep 2014 14:19:14 -0700

On 10 September 2014 13:46, Gonzalo Salgueiro (gsalguei)
<[email-masked]> wrote:
> If folks think it is useful we can even throw in a wildcard label (stun.*) as a catch all implying whatever STUN usage.

I'd be surprised if you couldn't enumerate all the options up front.
Inferring semantics based on a prefix is a dangerous precedent to set.
Existing usages of ALPN rely on it being an opaque token.  It would be
good to maintain that.

Not saying you shouldn't create consistency in the form of the labels
though, just don't try to overload meaning on that.

As far as uses go, the three you identify are the two that I think we
might need.  That is, if you are talking to a TURN server, that's
pretty clearly a good use for protocol identification.  Same applies
to talking to a STUN server for NAT discovery purposes.  Not sure that
I'd care to distinguish between NAT discovery and behaviour discovery
though.

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 10 Sep 2014 21:26:06 +0000

> though, just don't try to overload meaning on that.

Point taken.

> I'd care to distinguish between NAT discovery and behaviour discovery

OK. We'll take a pass at defining labels with the principal STUN sub-usages as I described in my earlier email.  We'll forego the more esoteric ones to strike a balance between appropriate granularity and unnecessary label proliferation. You'll see this change in an -02 coming very soon.

Thanks again.

Gonzalo

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Sep 2014 23:16:24 +0100

> OK. We'll take a pass at defining labels with the principal STUN sub-usages as I described in my earlier email.  We'll forego the more esoteric ones to strike a balance between appropriate granular…

Thanks.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 16 Sep 2014 10:58:33 +0000

Hi Martin,
We've published a revision incorporating feedback provided on this thread.
http://tools.ietf.org/html/draft-ietf-tram-alpn-02. Let us know if you
believe this is now WGLC-ready.

Thanks,
Prashanth

On 9/11/14 3:46 AM, "Martin Thomson" <[email-masked]> wrote:

>> OK. We'll take a pass at defining labels with the principal STUN
>>sub-usages as I described in my earlier email.  We'll forego the more
>>esoteric ones to strike a balance between appropriate granularity and
>>unnecessary label proliferation. You'll see this change in an -02 coming
>>very soon.
>
>Thanks.
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Sep 2014 19:15:47 -0700

> believe this is now WGLC-ready.

I'm still not convinced by the use case for identifying "stun".

At a minimum, remove: "(e.g., any labels starting with "stun.")"

---

From: Simon Perreault <[email-masked]>
Date: Wed, 17 Sep 2014 08:43:22 -0400

> I'm still not convinced by the use case for identifying "stun".

How else would normal Binding requests be identified? I mean, I don't have
a use case, but as an implementer I need to know what ALPN label to use.

A comment for the authors: for each STUN usage you list, please refer to
the corresponding RFC.

The whole paragraph is hard to understand IMHO. I would rewrite simply:
"stun: This label is used as a fallback for STUN usages that do not have a
corresponding ALPN label."

Simon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 17 Sep 2014 15:03:07 +0000

From: Simon Perreault <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 17, 2014 6:13 PM
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: Prashanth Patil <[email-masked]<mailto:[email-masked]>>, "Gonzalo Salgueiro (gsalguei)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tram] WGLC draft-ietf-tram-alpn-00

On Tue, Sep 16, 2014 at 10:15 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
I'm still not convinced by the use case for identifying "stun".

How else would normal Binding requests be identified? I mean, I don't have a use case, but as an implementer I need to know what ALPN label to use.

A comment for the authors: for each STUN usage you list, please refer to the corresponding RFC.

Sure.

The whole paragraph is hard to understand IMHO. I would rewrite simply: "stun: This label is used as a fallback for STUN usages that do not have a corresponding ALPN label."

Our intention was that 'stun' could identify any usage, including TURN/nat-discovery that have well defined labels, and not just a fallback for something that doesn’t have a well defined ALPN label. Too ambiguous?

-Prashanth

---

From: Simon Perreault <[email-masked]>
Date: Wed, 17 Sep 2014 11:31:05 -0400

On Wed, Sep 17, 2014 at 11:03 AM, Prashanth Patil (praspati) <
[email-masked]> wrote:

>  Our intention was that 'stun' could identify any usage, including
> TURN/nat-discovery that have well defined labels, and not just a fallback
> for something that doesn’t have a well defined ALPN label. Too ambiguous?
>

What's the point? Why would anyone emit "stun" when something more precise
is available?

Simon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 18 Sep 2014 02:43:24 +0000

From: Simon Perreault <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 17, 2014 9:01 PM
To: Prashanth Patil <[email-masked]<mailto:[email-masked]>>
Cc: Martin Thomson <[email-masked]<mailto:[email-masked]>>, "Gonzalo Salgueiro (gsalguei)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tram] WGLC draft-ietf-tram-alpn-00

On Wed, Sep 17, 2014 at 11:03 AM, Prashanth Patil (praspati) <[email-masked]<mailto:[email-masked]>> wrote:
The whole paragraph is hard to understand IMHO. I would rewrite simply: "stun: This label is used as a fallback for STUN usages that do not have a corresponding ALPN label."

What's the point? Why would anyone emit "stun" when something more precise is available?

We thought of it as a parent identifier, an umbrella label that identifies all STUN usages. But I agree, it doesn’t serve too much purpose for this label to identify usages that already have well defined labels.

-Prashanth

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 18 Sep 2014 03:56:13 +0000

Hi Martin & Simon - 

Just published an -03 clarifying that the "stun" label will function
exclusively as a fallback label for when one of the other usage-specific
labels do not apply.  

https://tools.ietf.org/html/draft-ietf-tram-alpn-03

In your estimation are we ready for WGLC now?

Cheers,

Gonzalo

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Sep 2014 06:51:32 -0700

On Sep 17, 2014 5:43 AM, "Simon Perreault" <[email-masked]> wrote:
> How else would normal Binding requests be identified? I mean, I don't
have a use case, but as an implementer I need to know what ALPN label to
use.

I can't imagine wrapping a Binding request in a (D)TLS handshake in any
scenario. It is usually the other easy around.

And, in those cases where you are sending Binding requests, your goal isn't
to do STUN. That isn't the application protocol, it's something like RTP,
or that thing your game talks, or some new STUN usage that really does
something.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 18 Sep 2014 11:04:09 -0400

> scenario. It is usually the other easy around.

Agreed. But can we agree that if someone did want to do it, one could
rightfully expect it to work?

> And, in those cases where you are sending Binding requests, your goal
> isn't to do STUN. That isn't the application protocol, it's something like
> RTP, or that thing your game talks, or some new STUN usage that really does
> something.
>

Correct. So if I'm developing a game, and I'm using STUN to punch holes in
the NAT for my game protocol to go through, what do I use as ALPN label?
"stun.X-my-awesome-game"? I'm a developer, not a protocol designer, so just
tell me please.

I think we should tell those developers to use "stun".

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 18 Sep 2014 11:19:32 -0400

> exclusively as a fallback label for when one of the other usage-specific

I just realized something: I assumed that "stun.nat-discovery" referred to
RFC 5780, but now I see in the following paragraph that there is explicitly
no label assigned to that usage. So I'm wondering what "stun.nat-discovery"
is used for...

Thanks,
Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 18 Sep 2014 10:15:08 -0600

On 09/18/2014 09:19 AM, Simon Perreault wrote:
> 
> On Wed, Sep 17, 2014 at 11:56 PM, Gonzalo Salgueiro (gsalguei) 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 

RFC 7350 section 4.1.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Simon Perreault <[email-masked]>
Date: Thu, 18 Sep 2014 13:00:51 -0400

> > no label assigned to that usage. So I'm wondering what

Ah, thanks!

Please add this reference to the label description!

Thanks,
Simon

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 18 Sep 2014 21:22:06 +0000

On Sep 18, 2014, at 1:00 PM, Simon Perreault <[email-masked]> wrote:

> 
> On Thu, Sep 18, 2014 at 12:15 PM, Marc Petit-Huguenin <[email-masked]> wrote:

Good call.  Added to -04.

Cheers,

Gonzalo

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 18 Sep 2014 21:24:08 +0000

On Sep 18, 2014, at 11:04 AM, Simon Perreault <[email-masked]> wrote:

> 
> On Thu, Sep 18, 2014 at 9:51 AM, Martin Thomson <[email-masked]> wrote:
> I can't imagine wrapping a Binding request in a (D)TLS handshake in any scenario. It is usually the other easy around.
> 
> 
> Agreed. But can we agree that if someone did want to do it, one could rightfully expect it to work?
>  
> And, in those cases where you are sending Binding requests, your goal isn't to do STUN. That isn't the application protocol, it's something like RTP, or that thing your game talks, or some new STUN usage that really does something.
> 
> 
> Correct. So if I'm developing a game, and I'm using STUN to punch holes in the NAT for my game protocol to go through, what do I use as ALPN label? "stun.X-my-awesome-game"? I'm a developer, not a protocol designer, so just tell me please.
> 

I agree.  

Martin - Do you see the need for any further text edits based on the -04?

Thanks,

Gonzalo

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Sep 2014 15:13:47 -0700

> rightfully expect it to work?

I would say that when someone chooses to do that, the application that
they are using should then ask for a new identifier.

If you don't care to identify your application properly, how about you
not use ALPN?

---

From: Simon Perreault <[email-masked]>
Date: Sun, 21 Sep 2014 14:04:20 -0400

As individual participant, I don't find this argument convincing. No game
developer would spend energy getting his own label, even if the registry
was FCFS. Also, I think that a "stun" label is still providing information
that could be somewhat valuable. But I also don't think that this is an
important issue.

Now, as chair I think we're starting to rehash the same arguments, and I
think we should move on. To me, the most sensible course of action if we
don't reach consensus would be to do nothing, i.e., not define a "stun"
label. We can always revisit this issue later if it becomes a pain point.
For now I think everyone can live without it.

Can anyone not live with this course of action?

Simon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 25 Sep 2014 04:35:48 +0000

It seems like there is no objection to removing the 'stun' label from the draft; we'll submit a revision accordingly. The new revision will only include labels to identify the two specific usages i.e., turn & nat-discovery. No additional label will be defined to identify other STUN usages.

-Prashanth

Date: Sunday, September 21, 2014 11:34 PM

As individual participant, I don't find this argument convincing. No game developer would spend energy getting his own label, even if the registry was FCFS. Also, I think that a "stun" label is still providing information that could be somewhat valuable. But I also don't think that this is an important issue.

Now, as chair I think we're starting to rehash the same arguments, and I think we should move on. To me, the most sensible course of action if we don't reach consensus would be to do nothing, i.e., not define a "stun" label. We can always revisit this issue later if it becomes a pain point. For now I think everyone can live without it.

Simon

Le 2014-09-19 18:13, "Martin Thomson" <[email-masked]<mailto:[email-masked]>> a écrit :