Re: [tram] Stephen Farrell's No Objection on draft-ietf-tram-turn-third-party-authz-16: (with COMMENT)

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Stephen,

Thank you for taking the time to review this document. 
We have also updated the draft to address the old comments.

Cheers,
-Tiru

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Friday, May 29, 2015 4:49 PM
> To: The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]; draft-ietf-tram-turn-third-party-
> [e-mail]; [e-mail];
> [e-mail]
> Subject: Stephen Farrell's No Objection on draft-ietf-tram-turn-third-party-
> authz-16: (with COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-tram-turn-third-party-authz-16: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> Hiya,
> 
> I've cleared my remaining discuss point which was to ask that the WG
> consider an alternative (and I think simpler) scheme based on signatures.
> Some of that discussion has happened so there's no reason to hold this up
> further. (I hope the discussion of simpler methods continues but that will
> depend on people being interested.)
> 
> S
> 
> OLD COMMENTS:
> 
> - As some others have said before, this is still not an easy read and though
> better, could still do with more editorial work.
> 
> - Why are 4.1.1 and 4.1.2 still just examples. You need one to be MTI or you
> won't get interop. Indeed 4.1.2 says you SHOULD do 4.1.1! Please just bite
> the bullet and clearly say that 4.1.1 is MTI.
> 
> - 4.1.1, "HTTPS MUST be used for mutual authentication" is not a very clear
> way to say it. You mean that HTTPS MUST be used and that TLS with mutual
> authentication based on client certificates MUST be used. How does the
> WebRTC server know what CA the TURN server is going to use? That's
> another point of pre-arrangement that will be needed.
> 
> - 4.1.1, I thought the web folks frowned upon specifying URI parameters like
> that. Shouldn't you at least use a .well-known URL or something so as to not
> get on someone eles's lawn?
> 
> - 6.2, PATH_MTU is not the correct term. There are two paths involved, from
> WebRTC to browser and from browser to TURN server and MTUs need not
> be the same on those paths.
> 
> OLD COMMENTS BELOW HERE, I DIDN'T CHECK
> THOSE.
> 
> - I really think this would benefit from some wider review and I don't think
> it's ready as-is.
> 
> - I agree with Richard's discuss points.
> 
> - intro: "impossible in web applications" isn't really true in principle, but
> impossible in WebRTC as it uses JS is true.
> 
> - Assuming the AS that can authorize the user shares a secret with the STUN
> server chosen by the WebRTC server seems very brittle. Why would that be
> true in general?
> 
> - 4.1.1: Hmmm. How many people use KeyProv I wonder?
> 
> - 4.1.2 - which "two servers"? WebRTC can have more servers than that.
> 
> - 4.1.2 - now we're using TLS mutual auth? And how does the TLS client
> know which CA to use that'll work with the TLS server here? I don't think
> that'll scale will it?
> 
> - 4.1.3 - this looks like what the WG/authors really want, would that be a fair
> statement?
> 
> - 9: Figure 2 should be way up at the top of the document and not here
> 
> - 9: Why 5 seconds?
>