Gen-ART Review of draft-ietf-behave-turn-uri-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-behave-turn-uri-05
Reviewer: Spencer Dawkins
Review Date: 2010-01-11
IETF LC End Date: 2010-01-13
IESG Telechat date: (not known)

Summary: This draft is almost ready for publication as a Proposed Standard. I have a couple of minor questions, shown below in sections 3 and 6.1.

Nits and readability comments aren't actually part of the review - they're for the author and editors...

Spencer

1.  Introduction

  The TURN specification [I-D.ietf-behave-turn] defines a process for a
  TURN client to find TURN servers by using DNS SRV resource records,
  but this process does not let the TURN server administrators
  provision the preferred TURN transport protocol between the client
  and the server and for the TURN client to discover this preference.

Spencer (readability): s/for/does not allow/ ?

  This document defines an S-NAPTR application [RFC3958] for this
  purpose.  This application defines "RELAY" as an application service
  tag and "turn.udp", "turn.tcp", and "turn.tls" as application
  protocol tags.

  Another usage of the resolution mechanism described in this document
  would be Remote Hosting as described in [RFC3958] section 4.4.  For
  example a VoIP provider who does not want to deploy TURN servers
  could use the servers deployed by another company but could still
  want to provide configuration parameters to its customers without
  explicitly showing this relationship.  The mechanism permits one to
  implement this indirection, without preventing the company hosting
  the TURN servers from managing them as it see fit.

Spencer (nit): s/see/sees/

  [I-D.petithuguenin-behave-turn-uri-bis] can be used as a convenient
  way of carrying the four components needed by the resolution
  mechanism described in this document.

3.  Resolution Mechanism

  An Allocate error response as specified in section 6.4 of
  [I-D.ietf-behave-turn] is processed as a failure as specified by
  [RFC3958] section 2.2.4.  The resolution stops when a TURN client
  gets a successful Allocate response from a TURN server.  After an
  allocation succeeds or all the allocations fail, the resolution
  context MUST be discarded and the resolution algorithm MUST be
  restarted from the beginning for any subsequent allocation.  Servers
  blacklisted as described in section 6.4 of [I-D.ietf-behave-turn]
  SHOULD NOT be used for the specified duration even if returned by a

Spencer (minor): I'm not sure why SHOULD NOT is appropriate here. If this isn't MUST NOT, I'm not sure it should be 2119 language. Is this just saying "if you include blacklisted servers, good things will probably not happen"?

  subsequent resolution.

  First the resolution algorithm checks that the parameters can be
  resolved with the list of TURN transports supported by the
  application:

Spencer (readability): I'm surprised that the following information is not shown as a table - Table 1 is showing something a lot more straightfoward, so I know you guys know how to create tables!

  o  If <secure> is false and <transport> is defined as "udp" but the
     list of TURN transports supported by the application does not
     contain UDP then the resolution MUST stop with an error.
  o  If <secure> is false and <transport> is defined as "tcp" but the
     list of TURN transports supported by the application does not
     contain TCP then the resolution MUST stop with an error.
  o  If <secure> is true and <transport> is defined as "udp" then the
     algorithm MUST stop with an error.
  o  If <secure> is true and <transport> is defined as "tcp" but the
     list of TURN transports supported by the application does not
     contain TLS then the resolution MUST stop with an error.
  o  If <secure> is true and <transport> is not defined but the list of
     TURN transports supported by the application does not contain TLS
     then the resolution MUST stop with an error.
  o  If <transport> is defined but unknown then the resolution MUST
     stop with an error.

  5.  If the first NAPTR query in the previous step does not return any
      result then the SRV algorithm defined in [RFC2782] is used to
      generate a list of IP address and port tuples.  The SRV algorithm
      is applied by using each transport in the filtered list of TURN
      transports supported by the application for the Protocol, <host>
      for the Name, "turn" for the Service if <secure> is false or
      "turns" for the Service if <secure> is true.  The same transport
      that was used to generate a list of tuples is used with each of
      this tuples for contacting the TURN server.  The SRV algorithm

Spencer (nit): s/this/these/

      recommends doing an A query if the SRV query returns an error or
      no SRV RR; in this case the default port declared in
      [I-D.ietf-behave-turn] for the "turn" SRV service name if
      <secure> is false, or the "turns" SRV service name if <secure> is
      true MUST be used for contacting the TURN server.  Also in this
      case, this specification modifies the SRV algorithm by
      recommending an A and AAAA query.  If the TURN client cannot
      contact a TURN server at any of the IP address and port tuples
      returned by the SRV algorithm with the transports from the
      filtered list then the resolution MUST stop with an error.

6.1.  RELAY Application Service Tag Registration

  Application Protocol Tag: RELAY

  Intended usage: See Section 3.

  Interoperability considerations: N/A

  Security considerations: See Section 5.

  Relevant publications: This document.

Spencer (minor): do you intend that the IANA replace the "This document" occurences with an RFC number before publication?
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]