Traversal Using Relays around NAT (TURN) Server Auto Discovery
draft-ietf-tram-turn-server-discovery-12

Thank you for addressing my DISCUSS.

= Section 6 =

"Using the TURN
   anycast address, the only two things that need to be deployed in the
   network are the two things that actually use TURN."

This is a bit opaque. I would suggest adding the qualifier "for discovery" somewhere in this sentence.

= Section 7.2 =

"WebRTC endpoints SHOULD treat any TURN server discovered through the mechanisms described in this specification as an enterprise/gateway server, in accordance with Recursively Encapsulated TURN [I-D.ietf-rtcweb-return]."
 
I think this needs to be re-phrased to include auto-discovery of a TURN server hosted by any access network, not just an enterprise network.

= Section 9 =

"Any discovered TURN server
   outside the criteria is considered untrusted and is not used for
   privacy sensitive communication."
   
This is stated as a fact, but I would have thought it's more of a recommendation to implementers, e.g., servers outside the criteria ought to be considered untrusted and therefore not used.

Thanks, this version helps, and I am clearing my DISCUSS. (I assume Spencer will figure out the Right Thing to do to make sure the update to 5766 gets the right review.)

I have a few minor comments on the resulting text. None of these are showstoppers:

- Absrtact: Please mention that this draft updates 5766 to relax the requirement for authentication in certain cases in the abstract.

- 9, 2nd paragraph, "Making STUN authentication OPTIONAL ..."

Since  you already used a 2119 MAY in the previous paragraph, there's no need for the 2119 OPTIONAL here. (In general, 2119 keywords should be used to state requirements, not talk about existing requirements)

-9, third paragraph:
I saw a comment on my DISCUSS email thread from Karl Stahl, stating that DTLS could not be mandated. Has that input been considered? (I don't have an opinion; I just want to make sure people noticed the comment.)

-9, 9th paragraph: "Instead, with an explicit administrator choice, a TURN client SHOULD fall-back to encryption-only (D)TLS when (D)TLS authentication is not available."
I’m not sure what SHOULD means after adding the explicit choice part. Does that means the administrator SHOULD make that choice? Is the point that you can fall back, but MUST NOT do so without explicit choice?

-9, 10th paragraph:
-- The first sentence is now redundant with the previous paragraph.
-- is the point of the first part of the second sentence that you MUST NOT fall back without explicit choice? (similar to for server authentication?)

Thank you for adding in the text on restricting access to the turn server to address my prior discuss.  I think this is helpful.

- 5.1: s/chance/change/

- I think section 9 covers all the bases in terms of what
might be done, but probably has to be a bit vague about what's
best to do and the consequences that follow. (For example,
with the reference to how RFC7250 "could be used.") I think it
might be a good idea to admit that we don't really yet know
the security implications of this mechanism, if widely
deployed.  However, I also admit that I'm unsure about this
since it's just very hard to know the security properties of
discovery of this kind ahead of time, so I'm not sure what
kind of text to suggest that'd be useful.

Thanks for addressing my DISCUSS points on version 09.

Thank you for the fix.