Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.txt
Marc Petit-Huguenin <petithug@acm.org> Thu, 05 November 2009 22:40 UTC
Return-Path: <petithug@acm.org>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD57628C128 for <behave@core3.amsl.com>; Thu, 5 Nov 2009 14:40:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.016
X-Spam-Level:
X-Spam-Status: No, score=-102.016 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPSfY4Crpzk8 for <behave@core3.amsl.com>; Thu, 5 Nov 2009 14:40:51 -0800 (PST)
Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 98D7728C0E2 for <behave@ietf.org>; Thu, 5 Nov 2009 14:40:51 -0800 (PST)
Received: by server.implementers.org (Postfix, from userid 1001) id 1C4DFDC04082; Thu, 5 Nov 2009 22:41:14 +0000 (UTC)
Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 5195ADC0407E; Thu, 5 Nov 2009 22:41:13 +0000 (UTC)
Message-ID: <4AF35488.7060605@acm.org>
Date: Thu, 05 Nov 2009 14:41:12 -0800
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701)
MIME-Version: 1.0
To: Margaret Wasserman <mrw@lilacglade.org>
References: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> <4ADE0BAB.1040402@acm.org> <FF53CDBF-9204-490D-8D04-9DF806EFE275@lilacglade.org> <4AE0A9F0.2010106@acm.org> <839B17D7-0BDE-4F11-8DC6-BDF694F7521D@lilacglade.org> <4AE4A119.5050007@acm.org> <9009E8A3-5FFE-4692-8EC6-BD038C5E728D@lilacglade.org>
In-Reply-To: <9009E8A3-5FFE-4692-8EC6-BD038C5E728D@lilacglade.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Behave WG <behave@ietf.org>
Subject: Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2009 22:40:52 -0000
Hi Margaret, Margaret Wasserman wrote: > > Hi Marc, > > On Oct 25, 2009, at 3:03 PM, Marc Petit-Huguenin wrote: [...] >> I still think that examples must not be added until the text is so >> clear that >> the examples are useless. > > If no one else supports my position that example would be valuable, I will > yield to your opinion on this point, as document editor. I will add examples (it's easy as all the examples are automatically generated by my reference implementation, to be sure that they are valid), but my point is that the text should not rely on examples, as they are not normative. [...] >>>> 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, port and transport tuples returned by the SRV >>>> algorithm then the resolution MUST stop with an error." >>> >>> This has the same problem as the one you fixed in section 4. We >>> don't return an error if the SRV fails, only if both the SRV lookup >>> and the subsequent A/AAAA lookup fail, right? >> >> I disagree here. The text says "SRV algorithm" not "SRV query". The >> fallback >> to A is part of the SRV algorithm, not something added by this text, >> so the >> tuples returned by the SRV algorithm eventually contains the result of >> the A >> query (and AAAA as modified by the text). >> >> And thinking of it, I am not sure I should have modified step 4, but >> see below. > > I understand what you are trying to say, but you haven't defined the > term "SRV > algorithm" (to include the A/AAAA lookup) anywhere, so it is my opinion > that > the meaning of this paragraph is still ambiguous. This is the type of > thing > that I think could be made very clear by an example, but if you don't want > to include examples, you need to be very clear about the step by step > process in each of these paragraphs. Here's the new proposed text: "3. If <host> is a domain name and <port> is not defined but <transport> is defined, then the SRV algorithm defined in [RFC2782] is used to generate a list of IP address and port tuples. <host> is used as Name, <scheme> as Service and <transport> as Protocol in the SRV algorithm. <scheme> and <transport> are converted to a TURN transport as specified in Table 1 and this transport is used with each tuple for contacting the TURN server. The SRV algorithm 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 SRV service name defined in <scheme> 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 transport converted from the <scheme> and <transport> then the resolution MUST stop with an error." > I am not sure that it is valid to indicate that section 4 stops with an > error, > and then indicate that there are some cases where you would > continue (presumably) without an error... > > Maybe you should add a line to section 4, in the middle, indicating that > if the NAPTR query returns an error, you should proceed to step 5? Here's the new proposed text: "4. If <host> is a domain name and <port> and <transport> are not defined, then <host> is converted to an ordered list of IP address, port and transport tuples via the S-NAPTR algorithm defined in [RFC3958] by using <host> as the initial target domain name and "RELAY" as the Application Service Tag. The filtered list of TURN transports supported by the application are converted in Application Protocol Tags by using "turn.udp" if the TURN transport is UDP, "turn.tcp" if the TURN transport is TCP and "turn.tls" if the TURN transport is TLS. The order to try the Application Protocol Tags is provided by the ranking of the first set of NAPTR records. If multiple Application Protocol Tags have the same ranking, the preferred order set by the application is used. If the first NAPTR query fails, the processing continues in step 5. If the TURN client cannot contact a TURN server with any of the IP address, port and transport tuples returned by the S-NAPTR algorithm 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 and <scheme> for the Service. 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 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 SRV service name defined in <scheme> 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." > > Also, you mention "the first NAPTR query". Will there be more than one? NAPTR queries are recursive. See RFC 3958 section 2.2.3. > If so, why and what will the subsequent queries contain? RFC 3958 section 2.2.4 explains what to do if the subsequent NAPTR queries fails (i.e. backtrack), this is why the turn-uri I-D explains only what should be done when the first NAPTR query fails. >>> >>> It is still not clear to me, from your text, how the S-NAPTR lookup >>> would be constructed, but that may reflect my limited understanding >>> of S-NAPTR. > > Could you give me an example of how the NAPTR query would be > constructed from the URI? for TURN URI "turn:example.org": $host -t NAPTR example.org example.org has NAPTR record 100 10 "" "RELAY:turn.udp" "" datagram.example.org. example.org has NAPTR record 200 10 "" "RELAY:turn.tcp:turn.tls" "" stream.example.org. The Application Service Tag and Application Protocol Tags are used by the RFC 3958 algorithm, not to generate a NAPTR query. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org
- [BEHAVE] Opsdir Review of draft-ietf-behave-turn-… Margaret Wasserman
- Re: [BEHAVE] Opsdir Review of draft-ietf-behave-t… Marc Petit-Huguenin
- Re: [BEHAVE] Opsdir Review of draft-ietf-behave-t… Marc Petit-Huguenin
- Re: [BEHAVE] Opsdir Review of draft-ietf-behave-t… Margaret Wasserman
- Re: [BEHAVE] Opsdir Review of draft-ietf-behave-t… Margaret Wasserman
- Re: [BEHAVE] Opsdir Review of draft-ietf-behave-t… Marc Petit-Huguenin
- Re: [BEHAVE] Opsdir Review of draft-ietf-behave-t… Margaret Wasserman
- Re: [BEHAVE] Opsdir Review of draft-ietf-behave-t… Marc Petit-Huguenin
- Re: [BEHAVE] Opsdir Review of draft-ietf-behave-t… WashamFan
- Re: [BEHAVE] Opsdir Review of draft-ietf-behave-t… Marc Petit-Huguenin
- [BEHAVE] Using TLS with a "turn:" URI [was Re: Op… Marc Petit-Huguenin
- [BEHAVE] TURN URI implicit processing [was Re: Op… Marc Petit-Huguenin
- Re: [BEHAVE] Opsdir Review of draft-ietf-behave-t… Marc Petit-Huguenin
- Re: [BEHAVE] TURN URI implicit processing [was Re… Margaret Wasserman
- Re: [BEHAVE] TURN URI implicit processing [was Re… Marc Petit-Huguenin