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