Subject: [tram] Two new authentication mechanisms

From: Simon Perreault <[email-masked]>
Date: Fri, 27 Jun 2014 09:21:26 -0400

TRAMsters,

We are soliciting discussion on the potential adoption as working-group 
documents of these two drafts:

http://tools.ietf.org/html/draft-johnston-tram-stun-origin
http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz

They would be targeted at fulfilling milestone 4 ("Nov 2014 - Send new 
authentication mechanism(s) to IESG for publication as Proposed Standard").

If you would like to see one or both of the drafts adopted, or if you 
are opposed, please explain why. Authors, we will assume you are for 
adoption of your own drafts.

Please consider the interactions between the two drafts. Is there 
anything interesting or problematic? What about overlap in function? Is 
there any? If so, is it necessary or problematic?

Let's take two weeks to discuss this.

Thanks,
Simon & Gonzalo

---

From: "Yoakum, John H (John)" <[email-masked]>
Date: Mon, 30 Jun 2014 16:24:46 +0000

>From my perspective, we should keep these two drafts separate as both are interesting but the Origin draft is reasonably mature already, and conceptually very straight forward as it is currently defined.  It would seem the Origin draft could be approved now as we already have both browser and TURN server proof-of-concept implementations (see latest draft update) that demonstrate feasibility, desirability, and usefulness.  Of course the effort to figure out how to add this to a browser was mentally significant but the actual code changes required for a proof-of-concept total just over 100 lines out of ~10M lines in Chrome.  Now that those changes have been made publically available it is straight forward for Google, and reasonably simple for everyone else, to comply with this draft and enable its various value propositions.  The additional bits in the STUN messages are typically quite small and insignificant for the value delivered.  Once we get this draft approved it is likely this functionality can be in browsers quickly, but the browser vendors will probably wait for draft approval to implement it (and we want to limit the use of that attribute value proposed before approval anyway).  In addition to various use cases previously discussed, it will prove to be highly useful to know Origin in various customer service systems where customers are reaching out to contact centers as it helps provide customer context.

Cheers,
John

AVAYA
1.919.425.8446 

-----Original Message-----
From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Friday, June 27, 2014 9:21 AM
To: [email-masked]
Subject: [tram] Two new authentication mechanisms

TRAMsters,

We are soliciting discussion on the potential adoption as working-group documents of these two drafts:

They would be targeted at fulfilling milestone 4 ("Nov 2014 - Send new authentication mechanism(s) to IESG for publication as Proposed Standard").

If you would like to see one or both of the drafts adopted, or if you are opposed, please explain why. Authors, we will assume you are for adoption of your own drafts.

Please consider the interactions between the two drafts. Is there anything interesting or problematic? What about overlap in function? Is there any? If so, is it necessary or problematic?

Thanks,
Simon & Gonzalo

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