[Dime] NAPTR fix for 3588bis

[Mark Jones <[e-mail]>]

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?

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'. 

       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

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

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