1 / 5

Diameter Extended NAPTR

Diameter Extended NAPTR. Thursday, November 11, 2010 draft-ietf-dime-extended-naptr Mark Jones Jouni Korhonen IETF 79 Beijing, China. I-D in a nutshell.

schuyler
Download Presentation

Diameter Extended NAPTR

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