Re: [tram] Review of TURNbis-11

["Konda, Tirumaleswar Reddy" <[e-mail]>]

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