Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt

[Noriyuki Torii <[e-mail]>]

Hi Tiru,

Thank you for the update.
I hesitate to say but I noticed I've missed one more point.

That is the first paragraph of section 12.6

>   The receiver of the ChannelData message uses the first two bits to
>   distinguish it from STUN-formatted messages, as described above.  If
>   the message uses a value in the reserved range (0x8000 through
>   0xFFFF), then the message is silently discarded.

Apparently, above paragraph also need update to align with RFC7983 and
also last update of section 12.

Regards,
Noriyuki Torii


2018-03-27 23:29 GMT+09:00 Konda, Tirumaleswar Reddy
<[e-mail]>:
> Thanks Noriyuki Torii, addressed the comments in the new revision.
>
> Cheers,
> -Tiru
>
>> -----Original Message-----
>> From: Noriyuki Torii [mailto:[e-mail]]
>> Sent: Monday, March 19, 2018 6:29 AM
>> To: Konda, Tirumaleswar Reddy <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt
>>
>> Hi Tiru,
>>
>> I checked updated I-D and found some more points in section 12 below.
>>
>> >      0x4000 through 0x4FFF: These values are the allowed channel
>> >      numbers (16,384 possible values).
>>                 ~~~~~~
>> This value also need to be amended to 4,096.
>>
>> >      0x8000 through 0xFFFF: These values are reserved for future use.
>>
>> This line can be removed now because the previous sentence imply it, too.
>>
>> And also, I think it may be preferable if the following paragraph is updated so as
>> to alignment to RFC 7983.
>>
>> >   Because of this division, ChannelData messages can be distinguished
>> >   from STUN-formatted messages (e.g., Allocate request, Send
>> >   indication, etc.) by examining the first two bits of the message:
>> >
>> >      0b00: STUN-formatted message (since the first two bits of a STUN-
>> >      formatted message are always zero).
>> >
>> >      0b01: ChannelData message (since the channel number is the first
>> >      field in the ChannelData message and channel numbers fall in the
>> >      range 0x4000 - 0x7FFF).
>> >
>> >      0b10: Reserved
>> >
>> >      0b11: Reserved
>> >
>> >   The reserved values may be used in the future to extend the range of
>> >   channel numbers.  Thus, an implementation MUST NOT assume that a TURN
>> >   message always starts with a 0 bit.
>>
>> I guess it could be
>>
>>     According to RFC 7983, ChannelData messages can be distinguished
>>     from other multiplexed protocols by examining the first byte of the
>>     message:
>>
>>           [0..3]  STUN
>>         [16..19]  ZRTP
>>         [20..63]  DTLS
>>         [64..79]  TURN Channel
>>       [128..191]  RTP/RTCP
>>           others  reserved, MUST be dropped and an alert MAY be logged
>>
>>     Reserved values may be used in the future by other protocols.
>>     Thus, an implementation MUST comply the discrimination above.
>>
>>
>> Finally, in section 18, the example Refresh request in the diagram of the page 67
>> doesn't have the PASSWORD-ALGORITHMS attribute nevertheless it has the
>> PASSWORD-ALGORITHM attributes, also need to be fixed.
>>
>> Regards,
>> Noriyuki Torii
>>
>> ----------------
>>
>> 2018-03-18 17:50 GMT+09:00 Konda, Tirumaleswar Reddy
>> <[e-mail]>:
>> > This revision addresses comments from Mark, Karl and Noriyuki Torii.
>> >
>> > -Tiru
>> >
>> >> -----Original Message-----
>> >> From: tram [mailto:[e-mail]] On Behalf Of internet-
>> >> [e-mail]
>> >> Sent: Sunday, March 18, 2018 8:43 AM
>> >> To: [e-mail]
>> >> Cc: [e-mail]
>> >> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt
>> >>
>> >>
>> >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> >> This draft is a work item of the TURN Revised and Modernized WG of
>> >> the IETF.
>> >>
>> >>         Title           : Traversal Using Relays around NAT (TURN): Relay Extensions
>> >> to Session Traversal Utilities for NAT (STUN)
>> >>         Authors         : Tirumaleswar Reddy
>> >>                           Alan Johnston
>> >>                           Philip Matthews
>> >>                           Jonathan Rosenberg
>> >>       Filename        : draft-ietf-tram-turnbis-15.txt
>> >>       Pages           : 84
>> >>       Date            : 2018-03-18
>> >>
>> >> Abstract:
>> >>    If a host is located behind a NAT, then in certain situations it can
>> >>    be impossible for that host to communicate directly with other hosts
>> >>    (peers).  In these situations, it is necessary for the host to use
>> >>    the services of an intermediate node that acts as a communication
>> >>    relay.  This specification defines a protocol, called TURN (Traversal
>> >>    Using Relays around NAT), that allows the host to control the
>> >>    operation of the relay and to exchange packets with its peers using
>> >>    the relay.  TURN differs from some other relay control protocols in
>> >>    that it allows a client to communicate with multiple peers using a
>> >>    single relay address.
>> >>
>> >>    The TURN protocol was designed to be used as part of the ICE
>> >>    (Interactive Connectivity Establishment) approach to NAT traversal,
>> >>    though it also can be used without ICE.
>> >>
>> >>    This document obsoletes RFC 5766 and RFC 6156.
>> >>
>> >>
>> >> The IETF datatracker status page for this draft is:
>> >> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
>> >>
>> >> There are also htmlized versions available at:
>> >> https://tools.ietf.org/html/draft-ietf-tram-turnbis-15
>> >> https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-15
>> >>
>> >> A diff from the previous version is available at:
>> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-15
>> >>
>> >>
>> >> Please note that it may take a couple of minutes from the time of
>> >> submission until the htmlized version and diff are available at tools.ietf.org.
>> >>
>> >> Internet-Drafts are also available by anonymous FTP at:
>> >> ftp://ftp.ietf.org/internet-drafts/
>> >>
>> >> _______________________________________________
>> >> tram mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/tram
>> >
>> > _______________________________________________
>> > tram mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/tram
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram