Re: [tram] Review of TURNbis-11

[Marc Petit-Huguenin <[e-mail]>]

Hi,

My responses inline.

On 02/09/2018 03:53 AM, Konda, Tirumaleswar Reddy wrote:
> Hi Marc,
> 
> Please see inline
> 
>> -----Original Message-----
>> From: tram [mailto:[e-mail]] On Behalf Of Marc Petit- 
>> Huguenin
>> Sent: Sunday, October 22, 2017 10:16 PM
>> To: [e-mail]
>> Subject: [tram] Review of TURNbis-11
>>
>> This is the second part of my review of TURNbis-11, i.e. everything 
>> but the dual allocation part.
>>
>> - Section 2.1, last paragraph:
>>
>> May be a reference to RFC 5764 and RFC 7983 can be useful here.  Same 
>> in section 4, second paragraph and following.  Same at the beginning 
>> of section 11.  Again in section 11.6 (if multiplexed, the message in 
>> the reserved range is not necessarily discarded).
> 
> Even if the same host transport address is used for other protocols, incoming packets to the TURN channel can be identified by just examining the source address of the packet. 
> May be I am missing something, I did not get a problem ?

It was just an attempt to make TURN implementers aware of the demux issues.

> 
>>
>> - Section 2.2, first paragraph:
>>
>> I think that an informative reference to RFC 7635 may be useful there, 
>> as alternative to the STUN authentication mechanism.
> 
> Yes, updated. 
> 
>>
>> - Section 2.9:
>>
>> The whole 2.9 section and subsections looks normative and so should be 
>> moved after section 3, perhaps on their own top level section.
> 
> Done. 
> 
>>
>> - Section 4, 4th paragraph:
>>
>> I would replace "For each allocation..." by "For each Allocate 
>> request...", because of the dual allocation feature.
> 
> Fixed. 
> 
>>
>> - Section 4, 12th paragraph:
>>
>> Should make clear clear that UDP covers also DTLS.
> 
> Yes, updated.
> 
>>
>> - Section 6.1, 2nd paragraph:
>>
>> If the port is multiplexed with other protocols (RTP, WebRtc, etc..) 
>> then it has to reuse an existing socket.  The document should explain this.
> 
> It's already covered in Section 2.1 (last paragraph). 
> 
>>
>> - Section 6.2, 3th paragraph:
>>
>> Is it time to recommend DTLS instead of UDP?  In that case we need to 
>> make DTLS mandatory in section 4 paragraph 11 (and I support that change).
> 
> No, DTLS has both advantages (e.g. dictionary attack)  and disadvantages (e.g. double encryption of application data). 

OK.

> 
>>
>> - Section 6.4, second bullet:
>>
>> Replace "...SRV procedures)." with "...DNS resolution procedures)."
> 
> Any specific reason for the replacement ?

This is to not exclude NPATR procedures (RFC 5928).

> 
>>
>> - Sections 14, 15 and 16:
>>
>> These are no longer new methods and attributes.  See also the next 
>> comment.
> 
> Fixed. 
> 
>>
>> - Section 19:
>>
>> Here you need to update the existing methods, attributes and error 
>> code so the IANA registries point to the RFC-to-be, then you request 
>> allocation for the new attributes.  See section 17 of STUNbis on a way 
>> to do that (that was done following a discussion with the IANA representative at an IETF meeting).
> 
> Thanks, updated draft. 
> 
>>
>> Note that ICMP should be comprehension-mandatory, not optional, as we 
>> do not want an old client to reject a Data indication with an ICMP attribute.
> 
> If the indication contains unknown comprehension-required attributes, the behavior is the indication is discarded and processing ceases.
> 
>>
>> Also, I do not know what this SendErr method is.
> 
> Removed SendErr (stale entry from a previous version of the draft).
> 
>>
>>
>> Nits
>> ----
>>
>> Section 1:
>>
>> s/connection to the Internet ./connection to the Internet./
>>
>> Section 2.4, first paragraph:
>>
>> The text switches between the words "mechanisms" and "way".  Choose 
>> one.
>>
>> Section 6.2, item 8:
>>
>> s/ADDITIONAL- ADDRESS-FAMILY/ADDITIONAL-ADDRESS-FAMILY/
>>
>> Section 12.1, "Preferred Behavior"
>>
>> s/Label Field[RFC3697]/Label Field [RFC3697]/
>>
>> Section 21:
>>
>> s/ADDRESS-ERRR-CODE/ADDRESS-ERR-CODE/
>>
>> Section 22:
>>
>> s/orginal/original/
> 
> Thanks, fixed all above nits.
> 
> Cheers,
> -Tiru
> 
>>



-- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug