Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

[Brandon Williams <[e-mail]>]

Hi Karl,

Regarding the "explicit administrator choice" part of the text, I think 
the point is not that an application MUST NOT blindly fall back to 
cleartext, but instead MUST give the admin and/or user some control. 
There are a variety of ways this could be accomplished. Tiru's 
suggestion in the earlier e-mail is just one of those. I don't think the 
draft needs to describe a specific method; it's up to the application 
developer to choose a method that best meets user needs.

--Brandon

On 02/10/2017 08:20 AM, Karl Stahl wrote:
> Hi Tiru, below again
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> *Skickat:* den 10 februari 2017 05:57
> *Till:* Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
> *Kopia:* [e-mail]
> *Ämne:* RE: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> Hi Karl,
>
>
>
> Please see inline [TR2]
>
>
>
> *From:*Karl Stahl [mailto:[e-mail]]
> *Sent:* Friday, February 10, 2017 6:53 AM
> *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
> <mailto:[e-mail]>>; 'Simon Perreault' <[e-mail]
> <mailto:[e-mail]>>; 'Spencer Dawkins at IETF'
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* SV: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> Hi Tiru, please see [Karl] inlines after your inlines.
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> *Skickat:* den 9 februari 2017 15:34
> *Till:* Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
> *Kopia:* [e-mail] <mailto:[e-mail]>
> *Ämne:* RE: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> Hi Karl,
>
>
>
> Please see inline
>
>
>
> *From:*Karl Stahl [mailto:[e-mail]]
> *Sent:* Thursday, February 9, 2017 6:22 PM
> *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
> <mailto:[e-mail]>>; 'Simon Perreault' <[e-mail]
> <mailto:[e-mail]>>; 'Spencer Dawkins at IETF'
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* SV: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> Tiru,
>
>
>
> Each of your three sentences are incorrect.
>
>
>
> And,
>
>> updated in 12 version to say that (D)TLS is not mandatory to use if the
> network infrastructure can defend against the attacks discussed in RFC5766.
>
>
>
> --- And in addition It breaks the version -07 consensus text regarding
> (D)TLS usage in this situation, by introducing “MUST” for (D)TLS usage
> under 9:
>
> ...and therefore MUST NOT be used for privacy sensitive communication.
>
> ...but MUST NOT fall back without explicit administrator choice.
>
> ...but MUST NOT fall back without explicit administrator choice.
>
> and my question how the “explicit administrator choice”  is supposed to
> happen in an enterprise environment or at an internet café is not answered.
>
>
>
> [TR] Explicit administrator choice means the user is notified about the
> failure and fallback happens only after consent from the user (i.e. the
> user needs to know that fallback happens to a less secure mechanism).
>
> [Karl] I suggest “administrator” is then changed to “user” so it is not
> interpreted as the network administrator, in a version -13 of the draft.
>
>
>
> [TR2] Sure, I can update draft.
>
> [Karl2] But please notice, that this only clarifies the draft, it is
> still a nuisance for a user and a general webRTC browser (that will be
> used under such conditions) and that was not what Brandon or anyone else
> asked for. Recommending the STUN dummy authentication instead, resolves
> the (D)TLS break of consensus of the version -07 text, including the
> performance concerns raised by Pal-Erik and others, as well as other
> objections.
>
>
>
> - I don’t think Brandon or anyone asked for such impossibilities (which
> again seem to be created to make this specification unusable for its
> purpose).
>
>
>
> Please note that to my knowledge, (D)TLS usage is not mandated  for any
> usage of TURN servers anywhere, and (again) this draft – that should
> specify DISCOVERY – cannot MANDATE USAGE. None of the discovery methods
> do (and cannot)  use (D)TLS (that discussion is for USAGE, AFTER the
> DISCOVERY).
>
>
>
> [TR2] Other drafts do not mandate (D)TLS because RFC5766 mandates STUN
> authentication, this draft updates RFC5766 by saying STUN authentication
> is not mandatory hence it is mandating (D)TLS.
>
> [Karl2] Yes, we agree. It is only this draft, version -10 to -12 draft
> that suggests to mandate usage of (D)TLS (Please free us from that)
>
>
>
> [TR] No, (D)TLS is only mandated if the network infrastructure cannot
> defend against the attacks discussed in RFC5766.
>
> [Karl] That is already clear in the -12 version. My comment remains (In
> addition to being wrong, I meant it is also strange (and unnecessary,
> considering that dummy authentication can achieve it better) if this
> DISCOVERY draft would mandates (D)TLS for TURN server usage in a certain
> situation, when no other draft mandates (D)TLS for usage of TURN servers.)
>
>
>
> [TR2] I don’t agree with your comments and don’t plan to make any
> changes to (D)TLS related text in the draft unless I hear otherwise from
> other WG members and chairs.
>
>
>
> [Karl] While producing the above suggested -13 of the draft, I also
> suggest you also include all the redlining I proposed (and no one has
> objected against) and I think we will have a draft that can be accepted
> to become an RFC.
>
>
>
> [TR2] I reject your all your other proposed changes including anycast,
> don’t see any merit in your arguments
>
> [Karl2] … and ignoring Brandon’s:
>
>> It is true that you have provided a justification for the change.
>
>> My  point is that the small set of people…
>
> As responded to:
>
>>> [Karl Justification is in the (A), (B), (C) and (D) of
>
>>> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>
>
>
>>> where saying Binding instead Allocate, is necessary to achieve (A) and (B), and improves (C) and (D).
>
>
>
> and will let the WG chairs decide how to proceed with the draft.
>
>
>
> [Karl2] Well, we need a specification that is defined and fulfill its
> purpose and thus can be made an RFC.
>
> Can you specify what and explain why any of the red lined suggestions to
> the version -12 text would go against this (or is there nothing)?
>
> (As a guidance to those you ask for “decide how to proceed with the draft.”)
>
>
>
> /Karl
>
>
>
> -Tiru
>
>
>
> Thanks,
>
> Karl
>
>
>
> -Tiru
>
>
>
> The read lined -12 version is cleared from these and other flaws or
> mistakes.
>
>
>
> We should focus on whether the red lined version is anything but
> improvements and adds no drawbacks over version -12 of the draft.
>
>
>
> /Karl
>
>
>
> PS: Regarding the non working anycast method, **since I highlighted in
> August 8, 2016, all from the Author’s at the WG list is**:
>
> October 18, 2016 (from Prashanth to me and others during the discuss):
>  We intend to add the following to explain server behavior a little better:
>
> “A TURN anycast server performs checks 1 to 7 discussed in Section 6.2
> of RFC5766. If all checks pass, the TURN anycast server MUST respond
> with a 300 (Try Alternate) error as described in [RFC5766];”
>
> November 15, 2016  (to something from Brandon): Agreed. -Tiru
>
> November 18, 2016 (to something from Brandon): +1, don't see a need for
> alternate mechanism. -Tiru
>
> December 22, 2016 Hi Karl, I don’t understand why the mechanism where
> TURN server has both anycast and unicast address for re-direction won’t
> work ? Cheers, -Tiru
>
> Now February 7, 8, 2016 See below
>
>
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> *Skickat:* den 8 februari 2017 09:51
> *Till:* Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
> *Kopia:* [e-mail] <mailto:[e-mail]>
> *Ämne:* RE: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> Hi Karl,
>
>
>
> We have gone over the same points over and over again and I don’t see a
> need to document the discussion b/w you and Simon, they are only
> operational considerations and have no impact on the protocol.
>
>
>
> Secondly, there is no consensus on your proposed new anycast mechanism
> and WG members have opposed your new anycast mechanism.
>
>
>
> Regarding (D)TLS, the draft is updated in 12 version to say that (D)TLS
> is not mandatory to use if the network infrastructure can defend against
> the attacks discussed in RFC5766. This update addresses comments
> received from Brandon.
>
>
>
> -Tiru
>
>
>
> *From:*Karl Stahl [mailto:[e-mail]]
> *Sent:* Wednesday, February 8, 2017 12:28 PM
> *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
> <mailto:[e-mail]>>; 'Simon Perreault' <[e-mail]
> <mailto:[e-mail]>>; 'Spencer Dawkins at IETF'
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* SV: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> 1) The A)+B) method (that Simon and I discussed) is not specified in the
> draft -12 text and further referencing:
>
> [Tiru below]> "https://tools.ietf.org/html/rfc7094#section-3.4
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7094-23section-2D3.4&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=LEhCEnJWTs-58S-OzhGCxFlWFoO_AZ4jL2d87B7k3xQ&e=>
> also discusses similar mechanism" does not help:
>
> - It rather states issues coming from not knowing whether a server
> reached by anycast addressing, actually is at a unicast address or
> really is deployed at a anycast address (which I believe is rare).
>
>
>
> 2) Further, there are no deployment considerations for the A)+B) method
> in the –12 draft (compare the redlined version)
>
> It does not even discuss or list  RFC7478 (Web Real-Time Communication
> Use Cases and Requirements) that it is supposed to meet, but which the
> A)+B) method is in conflict with.
>
> https://www.ietf.org/mail-archive/web/tram/current/msg02314.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02314.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=JUvi1vp2Im171VnwziFnhFyKRHdWeOyx5urNi9JOG9w&e=>
> and https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>.
>
>
>
>
>
>
> 3) And if the (more complex) A)+B) method would be properly defined and
> described in some future revision, then remains (from
> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>):
>
> “(trying to) exemplify/clarify the high level (important) points why we
>
> need/want anycast discovery by saying Binding instead of Allocate. These
>
> points are:
>
>
>
> (A) We need an anycast discovery method for auto-discovering "a TURN server"
>
> (not some special TURN server or arrangement of TURN servers "invented" for
>
> being discoverable by a certain method)
>
>
>
> (B) We need an anycast discovery method for a TURN server that is
>
> setup/installed/configured for its USAGE (which is relaying traffic) - not
>
> requiring a special network configuration just for being discoverable. (And
>
> more widely, it must be the goal of this specification to provide at least
>
> one discovery method that works for ALL network types and configurations,
>
> where a network provided TURN server may be useful - I see only anycast
>
> using Binding for querying *the TURN server's* unicast address fulfilling
>
> this.)
>
>
>
> (C) Robust (tolerant) deployment is highly preferable.
>
>
>
> (D) Ease of deployment is highly preferable.
>
>
>
> Saying Binding instead Allocate, is necessary to achieve (A) and (B), and
>
> improves (C) and (D).”
>
>
>
> 4) The (D)TLS text in version -12 does not have consensus either.
>
> https://www.ietf.org/mail-archive/web/tram/current/msg02296.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02296.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=3U7eSkgvs4w6NXK3vLX4Dlc7ZAwSIBMZ3bMsJDzqlkc&e=>
> and
>
> https://www.ietf.org/mail-archive/web/tram/current/msg02297.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=i7d7dLfsouxgahM92augLVbvLcurGOxKgbJ6qnzCIZw&e=>
>
>
> Against my red lined (D)TLS changes, I have heard no objections (just as
> with the red lined anycast method).
>
>
>
> /Karl
>
>
>
>
>
> -----Ursprungligt meddelande-----
> Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> Skickat: den 7 februari 2017 12:02
> Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
> Kopia: [e-mail] <mailto:[e-mail]>
> Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
>> -----Original Message-----
>
>> From: tram [mailto:[e-mail]] On Behalf Of Karl Stahl
>
>> Sent: Tuesday, February 7, 2017 4:02 PM
>
>> To: Tirumaleswar Reddy (tireddy) <[e-mail] <mailto:[e-mail]>>; 'Simon Perreault'
>
>> <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins at IETF'
>
>> <[e-mail] <mailto:[e-mail]>>
>
>> Cc: [e-mail] <mailto:[e-mail]>
>
>> Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action:
>
>> draft-ietf-tram-turn-server-discovery-12.txt
>
>>
>
>> Tiru,
>
>>
>
>> That does not make the version -12 text in the draft any clearer about what
>
>> the draft's anycast method actually is. I am asking you the same question as I
>
>> asked Simon before (and only he answered):
>
>
>
> I agree with the responses Simon has already provided to all the below
> questions. Further, I also don't see the need to discuss the below
> questions in the draft because they are only operational considerations
> (and have no impact on the actual protocol).
>
>
>
> -Tiru
>
>
>
>>
>
>> Does the draft assume:
>
>>
>
>> (A) a TURN server listening to TWO IP addresses (that are at different
>
>> subnets) that can respond error 300 or make an allocation, distinguished by
>
>> whether the request was received on its anycast address or its unicast
>
>> address, OR
>
>>
>
>> (B) we really have TWO TURN servers to play with (the one at the anycast
>
>> address being configured to respond with the error 300, OR
>
>>
>
>> (C) the FIRST Allocate is responded to with error 300 and SUBSEQUENT
>
>> Allocates actually are making TURN allocations.
>
>>
>
>>
>
>> We cannot have an RFC, not even being clear about the method specified.
>
>>
>
>> /Karl
>
>>
>
>>
>
>> -----Ursprungligt meddelande-----
>
>> Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>
>> Skickat: den 7 februari 2017 07:18
>
>> Till: Simon Perreault; Karl Stahl; 'Spencer Dawkins at IETF'
>
>> Kopia: [e-mail] <mailto:[e-mail]>
>
>> Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action:
>
>> draft-ietf-tram-turn-server-discovery-12.txt
>
>>
>
>> > -----Original Message-----
>
>> > From: Simon Perreault [mailto:[e-mail]]
>
>> > Sent: Friday, February 3, 2017 7:13 PM
>
>> > To: Karl Stahl <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins
> at IETF'
>
>> > <[e-mail] <mailto:[e-mail]>>
>
>> > Cc: [e-mail] <mailto:[e-mail]>; Tirumaleswar Reddy (tireddy)
> <[e-mail] <mailto:[e-mail]>>
>
>> > Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D
>
>> Action:
>
>> > draft-ietf-tram-turn-server-discovery-12.txt
>
>> >
>
>> > Karl,
>
>> >
>
>> > There is no consensus in the working group behind this new anycast
>
>> > mechanism. Therefore it can not be added to the draft, and the
>
>> > mechanism defined in RFC 5766 remains.
>
>>
>
>> Yup, https://tools.ietf.org/html/rfc7094#section-3.4
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7094-23section-2D3.4&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=LEhCEnJWTs-58S-OzhGCxFlWFoO_AZ4jL2d87B7k3xQ&e=>
> also discusses similar
>
>> mechanism.
>
>> I don't see the need for a new anycast mechanism.
>
>>
>
>> -Tiru
>
>>
>
>> >
>
>> > Thanks,
>
>> > Simon
>
>> >
>
>> > Le 2017-02-02 à 18:23, Karl Stahl a écrit :
>
>> > > The -12 version of the draft does not include major remedies of
>
>> > > flaws that were un-addressed long before the DISCUSS, nor the latest
>
>> > > regarding the possible use of (D)TLS for auto discovered turn
>
>> > > servers provided the local or access network administrator, see
>
>> > >
>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02216.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02216.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=OR288fay15EdJ063J_GCuNOt-SScDC5CylZsleLjXbU&e=>
>
>> > >
>
>> > >
>
>> > >
>
>> > > For the latest discussed, see
>
>> > >
>
>> > >
>
>> > >
>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02279.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02279.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=B9ST_TVehqEC-PVjUMsDQsxLBNgTStctSmVvmqi39zo&e=>
>
>> > >
>
>> > >>> However, I think we need agreement on the justification for such a
>
>> > >
>
>> > >> change.
>
>> > >
>
>> > >> [Karl] Justification is in the (A), (B), (C) and (D) of
>
>> > >
>
>> > >> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>
>
>> > >
>
>> > >> where saying Binding instead Allocate, is necessary to achieve (A)
>
>> > >> and
>
>> > > (B), and improves (C) and (D).
>
>> > >
>
>> > >
>
>> > >
>
>> > > Brandon> It is true that you have provided a justification for the
>
>> change.
>
>> > >
>
>> > >
>
>> > >
>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02296.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02296.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=3U7eSkgvs4w6NXK3vLX4Dlc7ZAwSIBMZ3bMsJDzqlkc&e=>
>
>> > >
>
>> > > The (D)TLS mandating was Author's idea to throw into version -10
>
>> > > during the discuss and remains in this version -11, breaking the
>
>> > > consensus text since version -7.
>
>> > >
>
>> > >
>
>> > >
>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02297.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=i7d7dLfsouxgahM92augLVbvLcurGOxKgbJ6qnzCIZw&e=>
>
>> > >
>
>> > > STUN dummy authentication instead of (D)TLS as suggested by Oleg
>
>> > > Moskalenko
>
>> > >
>
>> > >
>
>> > >
>
>> > >
>
>> > >
>
>> > > I have inserted my (now edited and adopted to the latest) redlining,
>
>> > > removal of blue options etc. into the -12 draft text as attached,
>
>> > > for the author to copy from and paste.
>
>> > >
>
>> > >
>
>> > >
>
>> > > Without my red lining, current version -12 is in conflict with
>
>> > > RFC7478 (Web Real-Time Communication Use Cases and Requirements)
>
>> > > and does
>
>> > not
>
>> > > meet the need of [I-D.ietf-rtcweb-return] (Recursively Encapsulated
>
>> > > TURN) (see under redlined 7.2)
>
>> > >
>
>> > > and it does not do what was set out in the Charter and "Milestone 3:
>
>> > > TURN server auto-discovery mechanism for enterprise and ISPs"
>
>> > >
>
>> > >
>
>> > >
>
>> > > Further, the authors have in version -12 (compared to from before
>
>> > > DISCUSS)  changed the text "  6.  Discovery using Anycast " to:
>
>> > >
>
>> > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddisc&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=AMYCMt0k9_YCuab2JldMPgDJsb5neZZkNIlStXCjJGQ&e=>
>
>> > > ov ery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt
>
>> > >
>
>> > > "IP anycast can also be used for TURN service discovery.  A packet
>
>> > >
>
>> > >    sent to an anycast address is delivered to the "topologically
>
>> > >
>
>> > >    nearest" network interface with the anycast address.  Using the
>
>> > > TURN
>
>> > >
>
>> > >    anycast address, the only two things that need to be deployed in
>
>> > > the
>
>> > >
>
>> > >    network for discovery are the two things that actually use TURN.
>
>> > >
>
>> > >
>
>> > >
>
>> > >    When a client requires TURN services, it sends a TURN allocate
>
>> > >
>
>> > >    request to the assigned anycast address.  A TURN anycast server
>
>> > >
>
>> > >    performs checks 1 to 7 discussed in Section 6.2 of [RFC5766].  If
>
>> > > all
>
>> > >
>
>> > >    checks pass, the TURN anycast server MUST respond with a 300 (Try
>
>> > >
>
>> > >    Alternate) error as described in Section 2.9 of [RFC5766]; The
>
>> > >
>
>> > >    response contains the TURN unicast address in the
>
>> > > ALTERNATE-SERVER
>
>> > >
>
>> > >    attribute.  For subsequent communication with the TURN server,
>
>> > > the
>
>> > >
>
>> > >    client uses the responding server's unicast address.  This has to
>
>> > > be
>
>> > >
>
>> > >    done because two packets addressed to an anycast address may
>
>> > > reach
>
>> > >
>
>> > >    two different anycast servers.  The client, thus, also needs to
>
>> > >
>
>> > >    ensure that the initial request fits in a single packet.  An
>
>> > >
>
>> > >    implementation may choose to send out every new TURN Allocation
>
>> > >
>
>> > >    request to the anycast address to discover the closest and the
>
>> > > most
>
>> > >
>
>> > >    optimal unicast address for the TURN server."
>
>> > >
>
>> > >
>
>> > >
>
>> > > The highlighted "A TURN anycast server"  isnothing known nor
>
>> > > described (in fact there would have to be TWO TURN servers, one
>
>> > > deployed at the anycast address and another TURN server deployed at
>
>> > > the unicast address, reacting differently to the Allocation request)
>
>> > > for this to work as clarified in WG discussions with Simon).
>
>> > >
>
>> > >
>
>> > >
>
>> > > The last sentence "An  implementation may choose to send out every
>
>> > > new TURN Allocation request to the anycast address to discover the
>
>> > > closest and the most optimal unicast address for the TURN server."
>
>> > > violates security and deployment considerations (see red lined
>
>> > > considerations in attached).
>
>> > >
>
>> > >
>
>> > >
>
>> > > Further, the authors have in version -12 (compared to from before
>
>> > > DISCUSS)  changed the text "7.2.  Recursively Encapsulated TURN " to:
>
>> > >
>
>> > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddisc&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=AMYCMt0k9_YCuab2JldMPgDJsb5neZZkNIlStXCjJGQ&e=>
>
>> > > ov ery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt
>
>> > >
>
>> > > "WebRTC endpoints SHOULD treat any TURN server discovered through
>
>> > the
>
>> > >
>
>> > >    mechanisms described in this specification as an
>
>> > > enterprise/gateway
>
>> > >
>
>> > >    or access network server, in accordance with Recursively
>
>> > > Encapsulated
>
>> > >
>
>> > >    TURN [I-D.ietf-rtcweb-return]."
>
>> > >
>
>> > >
>
>> > >
>
>> > > The text is a contradiction, since the return draft deals with TURN
>
>> > > servers provided by the local or access network, not other TURN
>
>> > > servers discovered by this draft.
>
>> > >
>
>> > >
>
>> > >
>
>> > > *Current -12 draft cannot be considered to be an RFC!*
>
>> > >
>
>> > >
>
>> > >
>
>> > > I suggest the redline version of draft -12 attached is chimed into
>
>> > > now and quickly merged into a version -13, so we can avoid the
>
>> > > "Conflict Resolution and Appeals"process hinted about in
>
>> > >
>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02202.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02202.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=d3MIEALshSLyuVc0Tp0U_RBYISTdX2sF-YW4oVWzUk4&e=>,
>
>> > > further delaying what is needed for Internet real-time communication
>
>> > > and especially for WebRTC.
>
>> > >
>
>> > >
>
>> > >
>
>> > > /Karl
>
>> > >
>
>> > >
>
>> > >
>
>> > > *Från:*tram [mailto:[e-mail]] *För *Spencer Dawkins at
>
>> > > IETF
>
>> > > *Skickat:* den 1 februari 2017 22:12
>
>> > > *Till:* Simon Perreault
>
>> > > *Kopia:* [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>;
> Tirumaleswar Reddy
>
>> > > (tireddy)
>
>> > > *Ämne:* Re: [tram] I-D Action:
>
>> > > draft-ietf-tram-turn-server-discovery-12.txt
>
>> > >
>
>> > >
>
>> > >
>
>> > > Hi, Simon,
>
>> > >
>
>> > >
>
>> > >
>
>> > > On Thu, Feb 2, 2017 at 6:00 AM, Simon Perreault <[e-mail]
>
>> > > <mailto:[e-mail]>> wrote:
>
>> > >
>
>> > > Le 2017-02-01 à 15:37, Spencer Dawkins at IETF a écrit :
>
>> > >> Dear TRAMsters,
>
>> > >>
>
>> > >> On Fri, Jan 13, 2017 at 12:59 PM, Tirumaleswar Reddy (tireddy)
>
>> > >> <[e-mail]
>
>> > >> <mailto:[e-mail]><mailto:[e-mail]
>
>> > > <mailto:[e-mail]>>> wrote:
>
>> > >>
>
>> > >>     This revision addresses comments from Brandon.
>
>> > >>
>
>> > >>     -Tiru
>
>> > >>
>
>> > >>
>
>> > >> How close are we to asking Terry to clear the (last remaining) DISCUSS?
>
>> > >
>
>> > > Thanks for the reminder.
>
>> > >
>
>> > > If my co-chair and the authors have no objection, I think we're ready.
>
>> > >
>
>> > >
>
>> > >
>
>> > > I'll give this 24 hours for people to chime in, but I do want to
>
>> > > ping Terry.
>
>> > >
>
>> > >
>
>> > >
>
>> > > It's a little-appreciated thing, but AD ballot positions go away
>
>> > > when ADs go away; this document has 12 yes/no objections now, and
>
>> > > you need
>
>> > > 10 for approval, and three are from ADs who are stepping down in
>
>> > > March
>
>> > > ;-)
>
>> > >
>
>> > >
>
>> > >
>
>> > > Spencer
>
>> > >
>
>> > >
>
>> > >
>
>> > > _______________________________________________
>
>> > > tram mailing list
>
>> > > [e-mail] <mailto:[e-mail]>
>
>> > > https://www.ietf.org/mailman/listinfo/tram
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=vmtm5H-2Ler_5PEKhheo-ob_Eiz6enqyiOnHkAKZjxQ&e=>
>
>> > >
>
>> >
>
>> >
>
>> > --
>
>> > Simon Perreault
>
>> > Director of Engineering, Platform | Jive Communications, Inc.
>
>> > https://jive.com
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jive.com&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6xMRYWWn81v-P_m3BZY8GMOvpo0ygL0wYykEsxKd66Q&e=>
> | [phone] ext. 1241 | [e-mail]
> <mailto:[e-mail]>
>
>>
>
>> _______________________________________________
>
>> tram mailing list
>
>> [e-mail] <mailto:[e-mail]>
>
>> https://www.ietf.org/mailman/listinfo/tram
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=vmtm5H-2Ler_5PEKhheo-ob_Eiz6enqyiOnHkAKZjxQ&e=>
>
>
>
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.