Re: [tram] Review of TURNbis-11

[Brandon Williams <[e-mail]>]

Hi Marc,

Does the fix look OK to you now?

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
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>