Re: [Dime] NAPTR fix for 3588bis

"Glen Zorn" <gwz@net-zen.net> Mon, 05 April 2010 05:12 UTC

Return-Path: <gwz@net-zen.net>
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 0908D3A68B3 for <dime@core3.amsl.com>; Sun, 4 Apr 2010 22:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.201
X-Spam-Level: *
X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=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 Xs+F9SLNsLmW for <dime@core3.amsl.com>; Sun, 4 Apr 2010 22:12:36 -0700 (PDT)
Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by core3.amsl.com (Postfix) with SMTP id 406473A68C7 for <dime@ietf.org>; Sun, 4 Apr 2010 22:12:36 -0700 (PDT)
Received: (qmail 25880 invoked from network); 5 Apr 2010 05:12:34 -0000
Received: from unknown (58.8.10.253) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 05 Apr 2010 05:12:33 -0000
From: Glen Zorn <gwz@net-zen.net>
To: 'Mark Jones' <Mark.Jones@bridgewatersystems.com>, 'jouni korhonen' <jouni.nospam@gmail.com>
References: <B4B762B06D90774E9E8016C89B66AF8756131D63@m679t05.fpmis.bridgewatersys.com> <082F9E86-364B-4535-A54D-F6759B33E023@gmail.com> <B4B762B06D90774E9E8016C89B66AF8756131DA2@m679t05.fpmis.bridgewatersys.com>
In-Reply-To: <B4B762B06D90774E9E8016C89B66AF8756131DA2@m679t05.fpmis.bridgewatersys.com>
Date: Sun, 04 Apr 2010 22:12:30 -0700
Organization: Network Zen
Message-ID: <01c101cad47e$991b6e40$cb524ac0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrQ7lmZpnDp2WD3Qoa3CaP20gcAJgADGixQAODsYBA=
Content-Language: en-us
Cc: 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: Mon, 05 Apr 2010 05:12:41 -0000

If the problem will be fixed in 3588bis then there is no need to file an
erratum.

Hope this helps.

~gwz


> -----Original Message-----
> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of
> Mark Jones
> Sent: Wednesday, March 31, 2010 11:32 AM
> To: jouni korhonen
> Cc: dime@ietf.org
> Subject: Re: [Dime] NAPTR fix for 3588bis
> 
> Thanks for the feedback, Jouni. Responses inline.
> 
> > -----Original Message-----
> > From: jouni korhonen [mailto:jouni.nospam@gmail.com]
> > Sent: March 31, 2010 12:20 PM
> > To: Mark Jones
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] NAPTR fix for 3588bis
> >
> > Hi,
> >
> > Thanks Mark for initiating the discussion and proposing text. My
> > initial comments inline.
> >
> > On Mar 31, 2010, at 4:48 PM, Mark Jones wrote:
> >
> > > Here are the proposed changes to 3588bis to implement the fix for
> the
> > NAPTR issues discussed at IETF#77 (see
> > http://www.ietf.org/proceedings/10mar/slides/dime-5.pdf)
> > >
> > > Comments appreciated.
> > >
> > > There was some discussion at the meeting of creating S-NAPTR
> > Application Service Tag entries for the unregistered NAPTR values in
> > RFC3588 ("AAA+D2x"). No consensus was reached but my impression was
> > that we were leaning towards NOT creating these entries. That would be
> > my preference too but are there any objections on the list?
> >
> > Would be ok I think.. However, I really would like to see even some
> > discussion related to them _somewhere_. Any ideas? Would an errata be
> > enough to cover that?
> >
> 
> I do agree this change needs to be discussed but I assumed we were going
> to have that discussion _here_ on this list. If the errata review
> procedure is likely to generate more discussion then I'm all for it.
> 
> >
> > >
> > > Regards
> > > Mark
> > >
> > > ************************* 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'.
> >
> > RFC3958 ABNF does not allow "." in iana-registered-protocol, so the
> > application protocol has to be changed, like "diametertcp" or "dtcp"
> > etc..
> >
> 
> Lucky for us that IANA is ignoring the RFC3958 ABNF then :)
> 
> http://www.iana.org/assignments/s-naptr-parameters/s-naptr-
> parameters.xhtml
> 
> Another errata perhaps?
> 
>    iana-registered-protocol  = ALPHA *31ALPHANUMSYM
> 
> > >
> > >       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   | TLS
> >
> > See my note above regarding the application protocol.
> >
> >
> > >
> > > ************************* 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"  ""
> > _diameter._tls.example.com
> > > IN NAPTR  100   50   "s"   "aaa:diameter.tcp"  ""
> > _aaa._tcp.example.com
> > > IN NAPTR  150   50   "s"   "aaa:diameter.sctp" ""
> > _diameter._sctp.example.com
> >
> > And lets have an example of "a" flag as well:
> >
> > IN NAPTR  150   50   "a"   "aaa:diametertls" ""
> server1.example.com
> > IN NAPTR  150   50   "a"   "aaa:diametertls" ""
> server2.example.com
> >
> 
> Fine by me.
> 
> >
> > >
> > >   This indicates that the server supports TLS, TCP and SCTP in that
> > >   order.  If the client supports TLS, TLS will be used, targeted to
> a
> > >   host determined by an SRV lookup of _diameter._tls.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
> > >
> > >
> > > ************************* FOURTH CHANGE **************************
> > >
> > > 14.1.  Normative References
> > >
> > > => Add new reference to S-NAPTR DDDS RFC3958.
> > >
> > > ************************* END OF CHANGES ***********************
> >
> > - Jouni
> >
> >
> >
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime