-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Spencer, Thanks for the review. See below for my comments. On 01/11/2010 03:07 PM, Spencer Dawkins wrote: > 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/ ? Applied. > > 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/ Applied. > > [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"? Hmmm. The purpose of this text is to prevent a client to continuously try to reach a crashed TURN server when the DNS cache will still continue to return the RRs for the duration of the TTL. I am not sure that this count as an interoperability issue but I think that this is something that must be prevented so unless someone complain I will change the "SHOULD NOT" to a "MUST NOT". > > 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. Hmm, the problem is that rules #3 and #6 do not fit nicely in a table. Actually the purpose of "Table 1" is to be able to reference the rules easily in the subsequent text, which is not the case for this set of rules. > > 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/ Applied. > > 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? No, I was thinking that the "this document" would reference the RFC after publication, but I guess that your question means that the registration template can be detached from the RFC and so needs to contain absolute references. So I added the following to the text: [Note to RFC Editor: Replace "This document" with reference to this document] - -- Marc Petit-Huguenin Personal email: marc@xxxxxxxxxxxxxxxxxx Professional email: petithug@xxxxxxx Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAktMvTcACgkQ9RoMZyVa61fRrQCeJRtQJ0rAfMOYVCPgHWZoBdba ha8An0uCiHQb/ijgzJwANuaskMVkzcz/ =03SR -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf