Re: [Dime] NAPTR fix for 3588bis

[Mark Jones <[e-mail]>]

Thanks for the feedback, Jouni. Responses inline.

> -----Original Message-----
> From: jouni korhonen [mailto:[e-mail]]
> Sent: March 31, 2010 12:20 PM
> To: Mark Jones
> Cc: [e-mail]
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dime