1 / 5

Extended NAPTR Specification for Diameter Peer Discovery

This Internet-Draft introduces an extended format for NAPTR service fields, enhancing RFC 3403 to facilitate the discovery of Diameter peers that support specific Diameter applications. The proposed format “AAA+AP” allows for the identification of applications and transport protocols, such as indicating that a Diameter node supports the Diameter EAP Application ('5') and SCTP protocol. The document ensures backward compatibility with RFC 3588 and addresses prior comments by refining problem statements, references, and editorial details. It also discusses potential challenges for non-IETF SDOs in utilizing this mechanism.

schuyler
Télécharger la présentation

Extended NAPTR Specification for Diameter Peer Discovery

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Diameter Extended NAPTR Thursday, November 11, 2010 draft-ietf-dime-extended-naptr Mark Jones Jouni Korhonen IETF 79 Beijing, China

  2. I-D in a nutshell • The I-D specifies an extended RFC3403 NAPTR service field format that permits discovery of Diameter peers that support a specific Diameter application or applications: • "AAA+AP" <appn-id>:<app-protocol> • Example: • 'AAA+AP5:diameter.sctp’ • Means that the Diameter node in the SRV record supports the Diameter EAP Application ('5') and SCTP as the transport protocol. • Builds on S-NAPTR usage defined in RFC3588bis-21. • NAPTR query procedure remains backwards compatible with RFC3588.

  3. I-D Changes Since IETF#78 Rev -03 was published on November 9th. Addresses the comments received during WGLC. Added a problem statement to abstract/introduction. Added reference to RFC3958 to pickup S-NAPTR terminology. Fixed a bunch of editorial nits (rewording/ grammar/ spelling).

  4. Open Issue Re-use of the existing S-NAPTR registry may deter non-IETF SDOs from using this mechanism. Current IANA policy is “Specification Required” but specification MUST be an RFC of any category. Could we relax the requirement for an RFC? If not, what is the minimal process for a non-IETF SDO to satisfy the RFC requirement? Two reviews in WGLC  Short, simple draft...this ain’t no 3588bis. 

  5. Feedback? RFCs for dummies

More Related