Re: [Dime] NAPTR fix for 3588bis
Victor Fajardo <vf0213@gmail.com> Tue, 13 April 2010 17:50 UTC
Return-Path: <vf0213@gmail.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5163A69BE for <dime@core3.amsl.com>; Tue, 13 Apr 2010 10:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level:
X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6]
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 gLApUSB+YEp8 for <dime@core3.amsl.com>; Tue, 13 Apr 2010 10:50:50 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B74753A6407 for <dime@ietf.org>; Tue, 13 Apr 2010 10:50:49 -0700 (PDT)
Received: by wwb24 with SMTP id 24so706815wwb.31 for <dime@ietf.org>; Tue, 13 Apr 2010 10:50:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=mTnpRyzZ62ZwMqVxxGGQe1SGAOGA87ahfL2o8uDO2Ig=; b=cpLacr4HXi+5JdKG5tAB6NpZAdndoBR7rAHg1ii0rZm5vQiMLA6y/OfrSTF83OtkwT WePGCCdnDRoEEp1So/b1XPYpQg6wdwDrOYRUoP9u3tE7pqwbWqLHtXwWx/1uBSjGF4dC qeJlioMxLLQBAMWk41XYU5PzOw4JJuSm+k0F0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AhmnzKF5MFRHI36ub3u9yao7gQz4No4egxyUUmV5nM8RWwj7/elHrF2UREqZ8nD33B N8fVV5yImEpE2vegc7k/2yo1FLGUJCDlBXmpBljOwP55K+DaeHusZtZKWLvZaKJ5aaNA gtWHWIwTCwqhXkkrxM2jpZL5khgEj1HHPxBRc=
MIME-Version: 1.0
Received: by 10.216.169.207 with HTTP; Tue, 13 Apr 2010 10:50:40 -0700 (PDT)
In-Reply-To: <D109C8C97C15294495117745780657AE0C73BC6D@ftrdmel1>
References: <B4B762B06D90774E9E8016C89B66AF8756131D63@m679t05.fpmis.bridgewatersys.com> <B4B762B06D90774E9E8016C89B66AF875613229B@m679t05.fpmis.bridgewatersys.com> <u2v919c9f451004081322h9f72706eg2fef6ab3517b624f@mail.gmail.com> <B4B762B06D90774E9E8016C89B66AF87561322BB@m679t05.fpmis.bridgewatersys.com> <4BC288CB.9030002@nict.go.jp> <u2x919c9f451004120527oc1ae023bj9c6f1a3b60592212@mail.gmail.com> <D109C8C97C15294495117745780657AE0C73B96F@ftrdmel1> <B4B762B06D90774E9E8016C89B66AF87561323C0@m679t05.fpmis.bridgewatersys.com> <4BC3FD95.70803@nict.go.jp> <D109C8C97C15294495117745780657AE0C73BC6D@ftrdmel1>
Date: Tue, 13 Apr 2010 12:50:40 -0500
Received: by 10.216.180.202 with SMTP id j52mr3557913wem.214.1271181040504; Tue, 13 Apr 2010 10:50:40 -0700 (PDT)
Message-ID: <w2z919c9f451004131050q2a4d00fgcfd1874bee51d395@mail.gmail.com>
From: Victor Fajardo <vf0213@gmail.com>
To: lionel.morand@orange-ftgroup.com
Content-Type: multipart/alternative; boundary="0016e656b5985d5155048421e694"
Cc: Mark.Jones@bridgewatersystems.com, dime@ietf.org
Subject: Re: [Dime] NAPTR fix for 3588bis
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2010 17:50:55 -0000
Looks good. I'll send out a bis version with the changes below. On Tue, Apr 13, 2010 at 9:46 AM, <lionel.morand@orange-ftgroup.com> wrote: > Thx Sébastien. > > So to sum up, all the existing issues are now closed. > > Any other feedback from the WG on the proposed modification? > > Hereafter the modification proposed by Mark with corrections based on the > agreement reached after email discussion: > > ************************* FIRST CHANGE ************************* > > Section 5.2 Diameter Peer Discovery > > => Replace step 2 with the following text: > > 2. The Diameter implementation performs a NAPTR query for a server > in a particular realm. The Diameter implementation has to know > in advance which realm to look for a Diameter agent in. This > could be deduced, for example, from the 'realm' in a NAI that a > Diameter implementation needed to perform a Diameter operation > on. > > The NAPTR usage in Diameter follows the S-NAPTR DDDS application > [RFC3958] which means that the SERVICE field includes tags for the > desired application and supported application protocol. > The application service tag for a Diameter application is 'aaa' and > the supported application protocol tags are 'diameter.tcp', > 'diameter.sctp' or 'diameter.tls'. > > The client follows the resolution process defined by the S-NAPTR > DDDS [RFC3958] application to find a matching SRV or A record of > a suitable peer. The domain suffixes in the NAPTR replacement field > SHOULD match the domain of the original query. > > > ************************* SECOND CHANGE ************************* > > Section 11.6 NAPTR Service Fields > > => Rename this section to S-NAPTR Parameters and replace content with: > > This document registers a S-NAPTR Application Service Tag value of "aaa". > > This document also registers the following S-NAPTR Application Protocol > Tags: > > Tag | Protocol > -------------------|--------- > diameter.tcp | TCP > diameter.sctp | SCTP > diameter.tls.tcp | TLS/TCP > > ************************* THIRD CHANGE ************************** > > Appendix B. NAPTR Example > > => Rename section to S-NAPTR Example and modify as follows. > > As an example, consider a client that wishes to resolve aaa: > example.com. The client performs a NAPTR query for that domain, and > the following NAPTR records are returned: > > ;; order pref flags service regexp replacement > IN NAPTR 50 50 "s" "aaa:diameter.tls.tcp" "" _diameter._ > tls.tcp.example.com > IN NAPTR 100 50 "s" "aaa:diameter.tcp" "" _diameter._ > tcp.example.com > IN NAPTR 150 50 "s" "aaa:diameter.sctp" "" _diameter._ > sctp.example.com > > This indicates that the server supports TLS/TCP, TCP and SCTP in that > order. If the client supports TLS/TCP, TLS/TCP will be used, targeted to > a > host determined by an SRV lookup of _diameter._tls.tcp.example.com. > That > lookup would return: > > ;; Priority Weight Port Target > IN SRV 0 1 5060 server1.example.com > IN SRV 0 2 5060 server2.example.com > > =>addition of an example with "a" flag required such as: > > IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" > server1.example.com > IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" > server2.example.com > > ************************* FOURTH CHANGE ************************** > > 14.1. Normative References > > => Add new reference to S-NAPTR DDDS RFC3958. > > ************************* END OF CHANGES *********************** > > > > > > > -----Message d'origine----- > > De : Sebastien Decugis [mailto:sdecugis@nict.go.jp] > > Envoyé : mardi 13 avril 2010 07:14 > > À : Mark Jones > > Cc : MORAND Lionel RD-CORE-ISS; vf0213@gmail.com; dime@ietf.org > > Objet : Re: [Dime] NAPTR fix for 3588bis > > > > Hi, > > > > I am fine with this approach as well. My initial intention > > was just to highlight that having TLS at the same level as > > TCP and SCTP is very confusing. > > The tag "diameter.tls.tcp" is perfectly fine for me. And it > > will be quite easy to figure what to do, should (TLS over) > > SCTP become more popular. > > > > Best regards, > > Sebastien. > > > > Le 13/04/2010 05:08, Mark Jones a écrit : > > > > > > Works for me. I assume we'd still keep "diameter.tls.tcp" > > as the tag > > > format so that "diameter.tls.sctp" can be used in the > > separate draft. > > > > > > Mark > > > > > > *From:* lionel.morand@orange-ftgroup.com > > > [mailto:lionel.morand@orange-ftgroup.com] > > > *Sent:* April 12, 2010 11:59 AM > > > *To:* vf0213@gmail.com; sdecugis@nict.go.jp > > > *Cc:* Mark Jones; dime@ietf.org > > > *Subject:* RE: [Dime] NAPTR fix for 3588bis > > > > > > Hi, > > > > > > Taking account that this topic came quite late in the > > revision process > > > and to not delay the publication of the RFC3588bis, we could maybe > > > consider to address TLS over SCTP in a separete draft in a latter > > > phase if there is a WG interest of the WG to support this option. > > > > > > Would it be acceptable? > > > > > > Regards, > > > > > > Lionel > > > > > > > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > *De :* dime-bounces@ietf.org > > [mailto:dime-bounces@ietf.org] *De la > > > part de* Victor Fajardo > > > *Envoyé :* lundi 12 avril 2010 14:28 > > > *À :* Sebastien Decugis > > > *Cc :* Mark Jones; dime@ietf.org > > > *Objet :* Re: [Dime] NAPTR fix for 3588bis > > > > > > Hi Sebastien, > > > > > > On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis > > > <sdecugis@nict.go.jp <mailto:sdecugis@nict.go.jp>> wrote: > > > > > > Hi, > > > > > > Sorry for the delay, I was on vacation. > > > > > > Le 09/04/2010 07:02, Mark Jones a écrit : > > > > 4) Application protocol tag for TLS does not differentiate > > > TLS/TCP vs > > > > TLS/SCTP (Sebastian). > > > > > > > > Conclusion: New TLS tags proposed to Sebastian. Still > > > > open. > > > > > > > > > > I am perfectly fine with the resolution you proposed, thank you! > > > > > > > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). > > > > > > > > Conclusion: Add the missing reference to 3588bis. > > > > Unrelated to this fix though. > > > > > > > I guess this resolution will require a bit more > > feedback from the > > > group, > > > there may be other ways to implement TLS over SCTP... > > Can the chairs > > > give direction on this issue? > > > > > > > > > > > > For all practical purpose, is there really a strong deployable > > > reason to support TLS over SCTP ? I'm just hesitant to delay bis > > > publication to support an academic exercise. > > > > > > regards, > > > victor > > > > > > > > > > > > Thanks! > > > Sebastien. > > > > > > -- > > > Sebastien Decugis > > > Research fellow > > > Network Architecture Group > > > NICT (nict.go.jp <http://nict.go.jp>) > > > > > > > -- > > Sebastien Decugis > > Research fellow > > Network Architecture Group > > NICT (nict.go.jp) > > > > >
- [Dime] NAPTR fix for 3588bis Mark Jones
- Re: [Dime] NAPTR fix for 3588bis jouni korhonen
- Re: [Dime] NAPTR fix for 3588bis Mark Jones
- Re: [Dime] NAPTR fix for 3588bis jouni korhonen
- Re: [Dime] NAPTR fix for 3588bis jouni korhonen
- Re: [Dime] NAPTR fix for 3588bis Sebastien Decugis
- Re: [Dime] NAPTR fix for 3588bis Glen Zorn
- Re: [Dime] NAPTR fix for 3588bis lionel.morand
- Re: [Dime] NAPTR fix for 3588bis Mark Jones
- Re: [Dime] NAPTR fix for 3588bis Victor Fajardo
- Re: [Dime] NAPTR fix for 3588bis Mark Jones
- Re: [Dime] NAPTR fix for 3588bis lionel.morand
- Re: [Dime] NAPTR fix for 3588bis Victor Fajardo
- Re: [Dime] NAPTR fix for 3588bis lionel.morand
- Re: [Dime] NAPTR fix for 3588bis Sebastien Decugis
- Re: [Dime] NAPTR fix for 3588bis Sebastien Decugis
- Re: [Dime] NAPTR fix for 3588bis Victor Fajardo
- Re: [Dime] NAPTR fix for 3588bis lionel.morand
- Re: [Dime] NAPTR fix for 3588bis Mark Jones
- Re: [Dime] NAPTR fix for 3588bis Sebastien Decugis
- Re: [Dime] NAPTR fix for 3588bis lionel.morand
- Re: [Dime] NAPTR fix for 3588bis Victor Fajardo
- Re: [Dime] NAPTR fix for 3588bis Qin Wu
- Re: [Dime] NAPTR fix for 3588bis Victor Fajardo
- Re: [Dime] NAPTR fix for 3588bis jouni korhonen
- Re: [Dime] NAPTR fix for 3588bis Qin Wu
- Re: [Dime] NAPTR fix for 3588bis Qin Wu