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)
> >
> >
>