Re: [Dime] NAPTR fix for 3588bis

[jouni korhonen <[e-mail]>]

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?


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

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


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