Re: [tram] Review of TURNbis-11

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

As suggested by Brandon, I reviewed turnbis-14 for the modifications agreed on below, and found one discrepancy.  See inline.

On 02/09/2018 05:45 AM, Konda, Tirumaleswar Reddy wrote:
>> -----Original Message-----
>> From: tram [mailto:[e-mail]] On Behalf Of Marc Petit-
>> Huguenin
>> Sent: Friday, February 9, 2018 6:54 PM
>> To: Konda, Tirumaleswar Reddy
>> <[e-mail]>; [e-mail]
>> Subject: Re: [tram] Review of TURNbis-11
>>
>> 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.
> 
> Got it, added the following line:
> The algorithm of demultiplexing packets received from
> multiple protocols is discussed in [RFC7983].
> 
>>
>>>
>>>>
>>>> - 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.

I cannot find this update in turn-14.

>>>
>>>>
>>>> - 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).
> 
> Updated second bullet.
> 
> Cheers,
> -Tiru
> 
>>
>>>
>>>>
>>>> - 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.
>>>

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