1. DIME WG IETF 84 Diameter Design Guidelines draft-ietf-dime-app-design-guide-15 Tuesday, July 31, 2012 Lionel Morand

2. What it should be about… Key deliverable to be used: –by Diameter application designers From IETF, vendors, SDOs –to clarify and/or reassess existing rules/recommendations that could be spread across specifications –to answer to the most frequent questions Raised during application design or Based on implementation and operational feedback –to avoid repeating misbehavior/error from the past in the future

3. Previous Step -13 submitted… with no major change -14 submitted right after IETF 83 –capturing feedback received in the meeting -15 sent on the DIME ML –due to missed deadline for draft submission –15 will be submitted unmodified as soon as possible

4. From -14 Reshape the document Editorial corrections Add guidelines on –creation of new commands –session management –Enumareted AVP used as boolean –routing of request/answer –use of IPsec as security mechanism

5. New ToC 4. Reusing existing Diameter applications............ 8 4.1. Adding a new command................... 8 4.2. Deleting a command.................... 9 4.3. Reusing existing commands................ 9 4.4. Reusing existing AVPs.................. 12 5. Defining new Diameter applications.............. 13 5.1. Introduction....................... 13 5.2. Defining new commands.................. 13 5.3. Use of Application-Id in a message............ 14 5.4. Application specific Session State Machine........ 14 5.5. Session-Id AVP and session management.......... 15 5.6. AVPs defined as Boolean flag............... 15 5.7. Application-specific message routing........... 16 5.8. About Translation Agent................. 17 5.9. End-to-End applications capabilities exchange...... 17 5.10. Diameter accounting support............... 18 5.11. Diameter security mechanisms............... 20 6. Defining Generic Diameter Extensions............. 22

6. #1: Defining new command Flexibility provided by use of optional AVPs in the command’s CCF good if: –state the condition of presence –define the behaviour when AVPs absent Remainder of the recommendation to add "* [AVP]" in the command's CCF to allow the addition of any arbitrary AVP

7. #2: Session-Id AVP and session management Some applications don’t need to rely on the Session-Id to manage user sessions –can rely on other info e.g. User-Name Auth- Session-State AVP set to NO_STATE_MAINTAINED in all messages Application commands can be defined without the Session-Id AVP. –clearly specify how the session is handled between client and server

8. #3: AVP defined as Boolean flag AVPs of type Enumerated are too often used as simple Boolean flag recommendation to use bitmask instead AVPs defined as bitmask can be reused and extended to multiplex several indications without major impact on the Diameter application

9. #4: Application-specific message routing Applications may need to rely on the User- Name AVP or any other AVP to determine the final destination of a request Additional application-level routing mechanisms have to be described in the application documentation Answer routing should follow the reverse path of the request, using transaction states and Hop-by-hop identifier matching.

10. #5: About Translation Agent protocol designers cannot assume the availability of "standard" Diameter-to- RADIUS gateways agent Required translation mechanism should be specified along with the Diameter application.

11. #6: Diameter security mechanisms Copy/paste of information on IPsec use initially present in RFC3588 and remove from RFC3588bis.

12. Objectives I’m ONLY EDITOR of the document. The content of this draft should reflect WG position. Feedback from the WG is required Launch a WGLC in August 2012 the draft should be submitted to IESG just after