Re: [tram] Review of TURNbis-11

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

On 03/09/2018 01:21 PM, Brandon Williams wrote:
> Hi Marc,
> 
> Does the fix look OK to you now?

Yes, thanks.

> 
> Thanks,
> --Brandon
> 
> On 03/04/2018 07:50 AM, Konda, Tirumaleswar Reddy wrote:
>> Thanks Marc, fixed the discrepancy.
>>
>> -Tiru
>>
>>> -----Original Message-----
>>> From: Marc Petit-Huguenin [mailto:[e-mail]]
>>> Sent: Saturday, March 3, 2018 3:04 AM
>>> To: Konda, Tirumaleswar Reddy
>>> <[e-mail]>; [e-mail]
>>> Subject: Re: [tram] Review of TURNbis-11
>>>
>>> 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