Diameter Maintenance and Extensions L. Bertz Internet-Draft Sprint Intended status: Standards Track June 29, 2017 Expires: December 31, 2017 Diameter Specification Recommendations draft-bertz-dime-diamimpr-00 Abstract This document reports on formatting errors, uses cases, and inconsistencies found in various standards specifications related to the Diameter interface requirements. Recommendations are made to reduce errors, support common use cases and build specifications in such a way that programmatic verification of Diameter specifications can be done with minimal to no errors. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 31, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Bertz Expires December 31, 2017 [Page 1] Internet-Draft Diameter Specification Recommendations June 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Survey of Existing Specifications . . . . . . . . . . . . . . 4 3.1. Summary of Challenges and Errors . . . . . . . . . . . . 6 3.2. Summary of Indirect Use Cases . . . . . . . . . . . . . . 7 3.2.1. Refinements . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Enumerations . . . . . . . . . . . . . . . . . . . . 8 3.3. Summary of Ingestion Barriers . . . . . . . . . . . . . . 8 4. Specification Survey . . . . . . . . . . . . . . . . . . . . 10 4.1. Survey Process . . . . . . . . . . . . . . . . . . . . . 10 4.2. Summary of Errors And Use Cases . . . . . . . . . . . . . 11 4.2.1. RFC 4004 . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. RFC 4006 bis (draft 03) . . . . . . . . . . . . . . . 11 4.2.3. RFC 4950 . . . . . . . . . . . . . . . . . . . . . . 12 4.2.4. RFC 5447 . . . . . . . . . . . . . . . . . . . . . . 12 4.2.5. RFC 5777 . . . . . . . . . . . . . . . . . . . . . . 12 4.2.6. RFC 5778 . . . . . . . . . . . . . . . . . . . . . . 13 4.2.7. Draft Diameter Load . . . . . . . . . . . . . . . . . 13 4.2.8. RFC 6733 . . . . . . . . . . . . . . . . . . . . . . 13 4.2.9. RFC 7155 . . . . . . . . . . . . . . . . . . . . . . 13 4.2.10. RFC 7683 . . . . . . . . . . . . . . . . . . . . . . 14 4.2.11. RFC 7944 . . . . . . . . . . . . . . . . . . . . . . 14 4.2.12. 3GPP TS 29.214 . . . . . . . . . . . . . . . . . . . 14 4.2.13. 3GPP TS 29.229 . . . . . . . . . . . . . . . . . . . 14 4.2.14. 3GPP TS 29.468 . . . . . . . . . . . . . . . . . . . 15 4.2.15. 3GPP TS 29.345 . . . . . . . . . . . . . . . . . . . 15 4.2.16. 3GPP TS 29.344 . . . . . . . . . . . . . . . . . . . 15 4.2.17. 3GPP TS 29.343 . . . . . . . . . . . . . . . . . . . 16 4.2.18. 3GPP TS 29.338 . . . . . . . . . . . . . . . . . . . 16 4.2.19. 3GPP TS 29.337 . . . . . . . . . . . . . . . . . . . 16 4.2.20. 3GPP TS 29.336 . . . . . . . . . . . . . . . . . . . 17 Bertz Expires December 31, 2017 [Page 2] Internet-Draft Diameter Specification Recommendations June 2017 4.2.21. 3GPP TS 29.329 . . . . . . . . . . . . . . . . . . . 17 4.2.22. 3GPP TS 32.299 . . . . . . . . . . . . . . . . . . . 17 4.2.23. 3GPP TS 29.154 . . . . . . . . . . . . . . . . . . . 19 4.2.24. 3GPP TS 29.215 . . . . . . . . . . . . . . . . . . . 19 4.2.25. 3GPP TS 29.368 . . . . . . . . . . . . . . . . . . . 20 4.2.26. 3GPP TS 29.128 . . . . . . . . . . . . . . . . . . . 20 4.2.27. 3GPP TS 29.173 . . . . . . . . . . . . . . . . . . . 20 4.2.28. 3GPP TS 29.217 . . . . . . . . . . . . . . . . . . . 20 4.2.29. 3GPP TS 29.273 . . . . . . . . . . . . . . . . . . . 20 4.2.30. 3GPP TS 29.272 . . . . . . . . . . . . . . . . . . . 21 4.2.31. 3GPP TS 29.061 . . . . . . . . . . . . . . . . . . . 21 4.2.32. 3GPP TS 29.212 . . . . . . . . . . . . . . . . . . . 22 5. Recommendations for Specification Improvement and Automation 23 5.1. Error Reduction . . . . . . . . . . . . . . . . . . . . . 23 5.1.1. Defined AVPs . . . . . . . . . . . . . . . . . . . . 23 5.1.2. Imported AVPs . . . . . . . . . . . . . . . . . . . . 25 5.1.3. Grouped AVPs . . . . . . . . . . . . . . . . . . . . 25 5.1.4. Command Errors . . . . . . . . . . . . . . . . . . . 26 5.1.5. Enumeration Errors . . . . . . . . . . . . . . . . . 27 5.2. Formats for automated validation . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction This document identifies common errors and uses of Diameter in order to document requirements and possible extensions to the Diameter Command Code Format (CCF) and other formats, e.g. Grouped Attribute Value Pair (AVP) format defined in [RFC6733]. It is by no means an exhaustive analysis of all Diameter specifications but provides a survey of a few dozen RFCs and 3GPP Technical Specifications to determine what improvements can be made in Diameter specifications. There are no issues with respect to over the wire communication of Diameter as evidenced by the successful implementation of Diameter applications based upon the specifications surveyed in this document. However, the development and implementation time of Diameter applications can be significantly improved when errors and inconsistencies of the message format as documented in the specifications are minimized or non-existent. An automated tool was developed and used to perform the survey analysis of the technical specifications. The tool would perform automated checking, syntax validation, and language generation and was ran against the various specifications to set a benchmark on the current state and quality of Bertz Expires December 31, 2017 [Page 3] Internet-Draft Diameter Specification Recommendations June 2017 the Diameter specifications. The '.dia' format of a fork of the diafuzzer project (https://github.com/Orange-OpenSource/diafuzzer) was used. It is a simple, deterministic format that provides semantic cross checks of Diameter specifications. With the goal of automated '.dia' format in mind a survey of various Diameter related RFCs and 3GPP Technical Specifications was executed. During the process several issues, errors, omissions and usage patterns were discovered, and they are outlined in section 4 (Specification Survey) of this document. Diameter Applications Design Guidelines [RFC7423] does an excellent job of noting common diameter desing use cases but it does not describe how the CCF or related grammers may represent some of these scenarios. To do this the '.dia' format was extended. A few new use cases were also identified that were not covered in [RFC7423]. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Survey of Existing Specifications The tool was ran against the following standards specifications for diameter applications: RFC 4004 [RFC4004] RFC 4006 bis [I-D.bertz-dime-rfc4006bis] RFC 4950 [RFC4950] RFC 5447 [RFC5447] RFC 5777 [RFC5777] RFC 5778 [RFC5778] Diameter Load (draft) [I-D.ietf-dime-load] RFC 6733 [RFC6733] RFC 7155 [RFC7155] RFC 7683 [RFC7683] Bertz Expires December 31, 2017 [Page 4] Internet-Draft Diameter Specification Recommendations June 2017 RFC 7944 [RFC7944] 3GPP TS 29.214 [TGPP.29.214] 3GPP TS 29.345 [TGPP.29.345] 3GPP TS 29.344 [TGPP.29.344] 3GPP TS 29.343 [TGPP.29.343] 3GPP TS 29.338 [TGPP.29.338] 3GPP TS 29.337 [TGPP.29.337] 3GPP TS 29.336 [TGPP.29.336] 3GPP TS 29.329 [TGPP.29.329] 3GPP TS 32.299 [TGPP.32.299] 3GPP TS 29.154 [TGPP.29.154] 3GPP TS 29.215 [TGPP.29.215] 3GPP TS 29.368 [TGPP.29.368] 3GPP TS 29.128 [TGPP.29.128] 3GPP TS 29.173 [TGPP.29.173] 3GPP TS 29.217 [TGPP.29.217] 3GPP TS 29.273 [TGPP.29.273] 3GPP TS 29.272 [TGPP.29.272] 3GPP TS 29.061 [TGPP.29.061] 3GPP TS 29.212 [TGPP.29.212] 3GPP TS 32.299 [TGPP.32.299] 3GPP TS 29.229 [TGPP.29.229] 3GPP TS 29.468 [TGPP.29.468] Bertz Expires December 31, 2017 [Page 5] Internet-Draft Diameter Specification Recommendations June 2017 3.1. Summary of Challenges and Errors Enumeration issues have their own section below. General issues include but are not limited to: Spelling and spacing errors. Inconsistent Table formats over time. Arguably this reflects the changes in Diameter but these inconsistencies occur with documents released in close time frames. There are also too many formats to claim it is a 'change over time' and not just an inconsistency issue. Missing AVPs and/or AVP Code values. Case Sensitive inconsistencies. The wrong name for AVPs in Tables, referenced across specs, etc. that have the same AVP Code. Claiming an AVP is defined in a spec when in fact it is referenced. Incorrect references. Not noting an AVP is referenced at all but including it in a Grouped AVP or Command. Some AVPs mentioned in Grouped AVPs and not defined anywhere. This happened a few times in accounting related 3GPP specifications. Enumerations do not have a specific format in the base specificaton [RFC6733]. Over the wire the labels themselves are not used as the value is transported in integer formats. When received by a Client or Server the value is checked against a list of valid values. The label only appears in displayed information for errors, logging, etc. However, many of the specifications used varying case, spaces and formats such as parenthesis around numbers, tables, numbers then labels, labels then numbers, etc. An algorithm keying off of the expression 'is of type Enumerated' was used to figure out the text between enumerations. A function was then used to attempt to parse various label patterns, generate a label that may be acceptable to a coding language and capture the value assigned to the label. This yielded partial success. In some cases, especially billing in 3GPP, hand edits were required to fix Bertz Expires December 31, 2017 [Page 6] Internet-Draft Diameter Specification Recommendations June 2017 duplicate labels and formats that were inconsistent with the rest of the document's enumerations. A few cases even referenced their values as coming from other enums or registries associated with the IETF or other standards organizations. These were removed in some cases due to their size while others were copied from the existing enumeration file in the diafuzzer project if it had already been generated. Although enumerations are now available in the intermediate '.dia' format, many of the labels will not be valid in specific programming languages. More work is required regarding enumerations to accommodate these situations. 3.2. Summary of Indirect Use Cases Several Use Cases appeared that where the dia format was extended to capture them. 3.2.1. Refinements Refinement (Extension) of Commands and Grouped AVPs. This is a case where the same AVP/Command is referenced, i.e. same code or vendor/ code combination but the underlying members of the structure are different. Two variants of this were found: The base (original definition) of the structure was refined. In this case, the 'Refines' Statement in the header may not include the application. A refinement of a refinement. In this case the specific refinement (AVP + App ID it was specified in) was the part of the refinement clause. Note: this is not inheritance. In inheritance the children also inherit the attributes (AVPs) of the parent. In many cases the new definition removed some of the parents AVPs or further limited the occurrence amount of the AVPs. Refinements can only occur if the Command/Grouped AVP is extensible, i.e. it includes *[AVP] in its definition. The rationale for this can be shown by example. A value of 2[AVP] would not be considered extensible and its behavior is undefined. Can someone limit the number of AVPs present in a Command/Grouped AVP when that value is less than the total sum of the upper bounds of all member AVPs. For example, if a Grouped AVP permits at most 2 Bertz Expires December 31, 2017 [Page 7] Internet-Draft Diameter Specification Recommendations June 2017 occurrences of AVP member "X" and 2 of AVP member "Y", how/why could/ would one limit the Grouped AVP to no more than 3 AVPs? In the dia format Refinement is captured by adding 'Refines [application id]' at the end of the header/Grouped AVP definition. 3.2.2. Enumerations Enumeration use cases included definitions that referenced other Enumerations registries found on the web In the second case the Enumeration was typically removed. In a few cases Enumerations referenced other enumerations and then, in Notes, limited the values (was a proper subset). The opposite case (a proper superset) never presented itself. Later specifications assigned Unsigned32 as a value in what appears to be an attempt to avoid registries or provide some pseudo extensibility. The exact purpose is actually unclear. 3.3. Summary of Ingestion Barriers Errors, inconsistencies and Use Cases that could not be easily fulfilled aside. Format differences hampered our ability to quickly ingest Diameter strcutures from specifications. The following is a list of patterns for just AVP header tables: Pattern 1: Parses the original table format for AVPs defined in an IETF spec. The header for an RFC is AVP Section | | |SHLD|MUST| | Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr| Pattern 2: Parses the original table format for AVPs defined in a 3GPP spec Attribute Name|AVP Code|Section defined|Value Type|Must|May|Should - not| Must not | May Encr. | Pattern 3: Parses the original table format for AVPs defined for freediameter is BUT some rows define a spec boundary such as the row below the header in this example Bertz Expires December 31, 2017 [Page 8] Internet-Draft Diameter Specification Recommendations June 2017 |Attribute Name|Code|Section|Data|MUST|MAY|SHLD NOT|MUST NOT|Encr| Pattern 4: Parses the original table format for AVPs defined in later IETF specs. The header for an RFC is | | AVP | Section | | |MUST | | Attribute Name | Code | Defined | Data Type |MUST| NOT | An AVP can be 2-line Accounting- 483 9.8.7 Enumerated | M | V | Realtime-Required | | | Pattern 5: Parses the original table format for AVPs defined in some IETF specs like RFC 7155. The header for an RFC is | | Section | |MUST | | Attribute Name | Defined |MUST| NOT | Pattern 6: Parses the original table format for AVPs defined in some IETF specs that don't define applications.. The header for an RFC is | | AVP | Section | | | Attribute Name | Code | Defined | Data Type | Pattern 7: Parses the original table format for AVPs defined in an IETF spec. The header for an RFC is AVP Section | |MUST| Attribute Name Code Defined Data Type |MUST| NOT| Pattern 8: Parses the original table format for AVPs defined in later IETF specs. The header for an RFC is | | AVP | Section | | | MAY |MUST | | Attribute Name | Code | Defined | Data Type |MUST| | NOT | An AVP can be 2-line Accounting- 483 9.8.7 Enumerated | M | V | Realtime-Required | | | Pattern 9: Parses the original table format for AVPs defined in a 3GPP spec Attribute Name|AVP Code|Clause defined|Value Type|Must|May|Should - Bertz Expires December 31, 2017 [Page 9] Internet-Draft Diameter Specification Recommendations June 2017 not|Must not| Pattern 10: Parses the original table format for AVPs defined in a 3GPP spec Attribute Name|AVP Code|Value Type|Must|May|Should not|Must not| Figure 1: Table Patterns Even with the patterns present some cleanup for "Notes..." was required to get the headers parsable. Not all specifications used an import table. In fact some inter- mixed the tables used to note AVPs defined in the spec and those that were referenced. Some columns were removed to ensure that they fit within known formats as well. In other words, there are more formats in the specifications than shown here but with some manipulation they can be reduced to this core set. For AVP imports a 3-column and 4-column format were common. Further they often had references that needed to be removed (an enhancement is planned to overcome this in the test code. Multiple application specific AVP tables that occurred in a single spec and unified. This was for research convenience but will hamper the generation of small dictionaries. Command codes have a long name and three letter acronym typically in a table. However, neither of those were used in the definition. For example, it is quite common to see Re-Authorization-Request and RAR but Re-Auth-Request in the command code definition. There is no easy, programmatic way to identify an application and relations to command codes or result codes. 4. Specification Survey 4.1. Survey Process The current process for performing validation is to perform the following tasks: Separate AVP and AVP import tables. The primary goal of this was to study the table formats to develop code to process them. Bertz Expires December 31, 2017 [Page 10] Internet-Draft Diameter Specification Recommendations June 2017 Save the file in a text format. This document is then modified to correct the errors. 'Repair' enumerations as required through the use of a separate enum file that is modified as issues are discovered. Create a filter format file that captured data that was hard to find in the specifcation related to Diameter Applications. The time spent for each document is the total amount of time from start to finish where the various files were split as described above and the software was then ran. As errors were discovered they were documented and then, as required, repaired. In some cases new software was developed to accommodate new use cases or formats. That was added to the total processing time for the document unless otherwise noted. 4.2. Summary of Errors And Use Cases 4.2.1. RFC 4004 For RFC 4004 [RFC4004], processing took approximately 20 minutes. Defect corrections were approximately an hour. The AVP Table is a unique format. Line continuations of the table are not consistent. Enumerations are backwards - # Label Some issues were noted but not resolved in 4004. See https://www.ietf.org/mail-archive/web/dime/current/msg02053.html Note that MIP-MN-FA-SPI, MIP-MN-HA-SPI and MIP-HA-to-MN-SPI are missing in the specification. They were removed from their respective Grouped AVPs. MIP-Nonce is in the AVP definition but MIP-nonce (lowercase 'n' for nonce) in Grouped definitions 4.2.2. RFC 4006 bis (draft 03) For RFC 4006 bis [I-D.bertz-dime-rfc4006bis], processing took approximately 25 minutes. The AVP table contains inconsistent continuation lines. No import tables have been provided and had to be constructed. Bertz Expires December 31, 2017 [Page 11] Internet-Draft Diameter Specification Recommendations June 2017 Had to change the User-Equipment-Info-Type AVP to the format of 'AVP (AVP Code XXX) is of type Enumerated' to keep the pattern to one type. Had to stub in TBD values. Misspelling of IPFiltrRule in table. Many enums referenced to registry values in the spec. Section 8.6 removes dashes for Check Balance Result Redirect-Address-Type Enumerations have spacing so appear as duplicates. CC-Session-Failover was phrased as 'is type of Enumerated' instead of 'is of type Enumerated' 4.2.3. RFC 4950 For RFC 4950 [RFC4950], processing took approximately 15 minutes. No major issues were found. 4.2.4. RFC 5447 For RFC 5447 [RFC5447], processing took approximately 10 minutes. No major issues were found. 4.2.5. RFC 5777 For RFC 5777 [RFC5777], processing took approximately 3 hours. A unique AVP table format. Had to hand enter ALL Enum formats. The approach taken for enum processing is not correct for this document. Treatment-Action listed as Grouped in AVP table IP-Bit-Mask-Width not present in table 4.1.7.7 and table are inconsistent with AVP definition used in groups 'IP-Bit-Mask-Width' vs. 'IP-Mask-Bit-Mask-Width' Filter-Rule's use of ';' for comment is unconventional in parsing Bertz Expires December 31, 2017 [Page 12] Internet-Draft Diameter Specification Recommendations June 2017 4.2.6. RFC 5778 For RFC 5778 [RFC5778], processing took 24 minutes. Continuations in AVP tables are inconsistent which required hand editing. The continuation '-' sometimes appears on the first line or not until the second which will require more complex code to deal with the situation. Imports of AVPs were mixed in with the table definitions specification. This took the most time work out. Subtype field of the MN-HA and MN-AAA authentication mobility options are not defined in spec and needed to be stitched in (corrected) later. Although noted properly in text, MIP-Session-Key, MIP-Algorithm- Type, MIP-Replay-Mode was not listed as being imported from an RFC in the AVP table. 4.2.7. Draft Diameter Load For Diameter Load [I-D.ietf-dime-load], processing completed by hand in 10 minutes. IANA allocations have occurred but the document has not left editors queue which means scripts would not work anyway 4.2.8. RFC 6733 For RFC 6733 [RFC6733], processing took approximately 15 minutes. Continuations were inconsistent. The spec does not follow its own CCF. 4.2.9. RFC 7155 For RFC 7155 [RFC7155], processing took several hours. The original RFC was used to fill in many of the gaps in the AVP table code. AVPs only used for compatibility are in the messages but not mentioned in the document, e.g. NAS-Identifier is still present. RA-XXX to Re-Auth but Command acronyms, names and custom names are inter-mixed which is a bit confusing and makes it problematic to automate. Hand stitched the enum values which often pointed to entire registries Bertz Expires December 31, 2017 [Page 13] Internet-Draft Diameter Specification Recommendations June 2017 4.2.10. RFC 7683 For RFC 7683 [RFC7683], processing took approximately 40 minutes. The AVP table has a unique format. Continuations were on the second line requiring look ahead logic. 4.2.11. RFC 7944 For RFC 7944 [RFC7944], processing took approximately 10 minutes. No major issues were found. 4.2.12. 3GPP TS 29.214 For TS 29.214 [TGPP.29.214], processing took approximately 45 minutes. In the AVP tables a dot is used as a separator instead of a comma. In the Specific-Action AVP, the Label 'Void' occurs twice. A hand modification was made. The Service-Info-Status AVP has spaces between the names in the labels. This was corrected. 4.2.13. 3GPP TS 29.229 For TS 29.229 [TGPP.29.229], processing this took 2 hours; 20 minutes. Many AVPs are listed as being DEFINED in the specification but they are references. It does not import RFC 4005, 7155 or 4006 despite using their AVPs. Although restored in Dec 2011 in a change request, Wildcarded-IMPU was not added back to the AVP table Table 6.3.1: Diameter Multimedia Application AVPs Line-Identifier also does not appear in the Table and this AVP has Vendor Id ETSI (13019) Bertz Expires December 31, 2017 [Page 14] Internet-Draft Diameter Specification Recommendations June 2017 4.2.14. 3GPP TS 29.468 For TS 29.468 [TGPP.29.468], processing took approximately 60 minutes Another AVP Table format. The Commands were abbreviated in a manner not seen elsewhere in the document, e.g. GA-Request is only used in the command definition. AVP Definitions table removes dashes of the Grouped AVPs. Duplicate AVP names with different codes for MBMS-GW-SSM-IP- Address and MBMS-GW-SSM-Ipv6-Address. TMGI-Number in the Grouped AVP but it is defined in the table as TMGINumber. 4.2.15. 3GPP TS 29.345 For TS 29.345 [TGPP.29.345], processing took approximately 70 minutes AVP Table inter-mixes '.' and ',' separation in the flags fields. Code was finally written to overcome this. In the AVP Table, App-Identifier was typed as 'Group' and not 'Grouped'. In the AVP Table, 'Assistance-info' was incorrect case for 'Info'. Section 6.3.31, WiFi-P2P-Assistance-Iinfo has an extra 'i' in it User-Identity's, ProSe-Response-Code's and ProSe-Query-Code's origin are unclear. They is not in a reference section but in several groups. Discovery-Auth-Request and Match-Report-Info use incorrect case - ProSe-App-ID. ProSe-Query-Code and ProSe-Response-Code are noted in Grouped AVPs but do not exist elsewhere in the spec. 4.2.16. 3GPP TS 29.344 For TS 29.344 [TGPP.29.344], processing took approximately 50 minutes ProSe-Subscriber-Information-Request is the name for ProSe- Initial-Location-Information-Request. Bertz Expires December 31, 2017 [Page 15] Internet-Draft Diameter Specification Recommendations June 2017 Authorized-Discovery-Range was not listed as a defined AVP and has no values assigned. Filled in as 3708 but these sections are not present in 29.230 at all 4.2.17. 3GPP TS 29.343 For TS 29.343 [TGPP.29.343], processing took approximately 10 minutes No issues. 4.2.18. 3GPP TS 29.338 For TS 29.338 [TGPP.29.338], processing took approximately 55 minutes Table 6.3.2.2/1: Command-Code values for SGd/Gdd has spaces in the command names. Send-Routing-info-for-SM-Answer in the command definition is lowercase and can't be linked to the command table. Not an issue but an observation. There is no Load Control draft reference. SGSN-Absent-User-Diagnostic SM has a space in it in the AVP table SM-Delivery- Failure-Cause has spacing issue in table. SMSMI-Correlation-ID has dash issues in its definition.. SM-Delivery-Not-Intended has values as a list with ending of ',' and period. Similar issues for SM-RP-MTI MME-SM-Delivery-Outcome- There is an extra > at the end of the header definition SM-Enumerated-Delivery-Failure-Cause used ',' and '.' for the list. Also the data type 'Enumerated' was not capitalized causing a miss in the system. MSISDN import is from 29.329 and not 23.329 4.2.19. 3GPP TS 29.337 For TS 29.337 [TGPP.29.337], processing took approximately 20 minutes No issues. Bertz Expires December 31, 2017 [Page 16] Internet-Draft Diameter Specification Recommendations June 2017 4.2.20. 3GPP TS 29.336 For TS 29.336 [TGPP.29.336], processing took approximately 9 hours as it was used for testing. Spacing issues in AVP tables for Maximum Latency, Maximum Response Time Scheduled-communication-time definition is lower case. Periodic-Time is lowercase in the AVP Table. Found a '/' in the Flags portion of the AVP Table. eNodeB-ID and Extended-eNodeB-ID in this spec but 'Id' in defining spec .217 4.2.21. 3GPP TS 29.329 For TS 29.329 [TGPP.29.329], processing took approximately a billion minutes Spacing issues in AVP User-Data-Request command. Does not specify the Supported-Features, Feature-List, Feature- List-ID, Supported-Applications, Server-Name, Public-Identity from another app in the AVP table. 4.2.22. 3GPP TS 32.299 For TS 32.399 [TGPP.32.299], processing took approximately 9 hours Unique Table format. Required to remove imported AVPs and create a new table. UTF8string case incorrect in AVP table for a number of entries. ProSe-Direct-Communication- Transmission-Data-Container and Status- AS-Code have spaces. LCS-Client-ID changed to LCS-Client-Id. ProSe-Direct-Communication- Transmission-Data-Container Related- Change-Condition- Information Trunk-Group-ID was Trunk-Group-Id in AVP table. Bertz Expires December 31, 2017 [Page 17] Internet-Draft Diameter Specification Recommendations June 2017 Wrote more software to deal with the values flipped in enums (int first then label) Enums were a large issue so hand editing had to take place to clean up the values. 'is of type of Enumerated' and 'is of type enumerated' were present in the document AoC-Service-Type had to be repaired by hand as the algorithm picked up the overloaded Change-Condition values MBMS-User-Service-Type Node-Functionality needs fixing Online-Charging-Flag had to be corrected Originator had missing elements Void numbers get caught in enums PoC-Event-Type used semicolons ProSe-Direst-Discovery-Mode spelling issue ProSe- Role-Of-UE spacing issue Participant-Access-Priority uses colons in enum labels and mixed descriptions Changed Type-Number Unsigned32 as the registry is too difficult to code Submission-Timestamp not defined PoC-User-Role-Ids instead of PoC-User-Role-IDs Removed [ Monitored-HPLMN-Identifier ] as it made no sense and was not defined [ Prose-Function-PLMN-Identifier ] removed [ VASP-Id ] & [ VAS-Id ] removed from MMS-Information Service-Generic-Information removed from Service-Information defined in OMA-DDS-Charging_Data [223]. Bertz Expires December 31, 2017 [Page 18] Internet-Draft Diameter Specification Recommendations June 2017 [ 3GPP-Session-Stop-Indicator ] removed IM-Information DCD-Information removed from Service-Information defined in OMA-DDS-Charging_Data [223] ePDG-Address vs EPDG-Address M2M-Information removed from Service-Information as it was missing SM-Device-Trigger-Information's Reference-Number removed since it was missing Incoming-Trunk-Group-ID removed 4.2.23. 3GPP TS 29.154 For TS 29.154 [TGPP.29.154], processing took approximately 10 minutes Variance of a later Table format. Command Codes were abbreviated in such a way that they had to be changed so the software could match them up properly Time-window grouped AVP definition corrected to Time-Window 4.2.24. 3GPP TS 29.215 For TS 29.215 [TGPP.29.215], processing took approximately 60 minutes S9a* reference table has a TS reference instead of 3GPP TS. UE-Local-IPv6-Prefix type in AVP table is all lower case. Note that ' is of type of Enumerated" was corrected to allow the software to catch the Subsession-Operation and DRA-Binding. Imports are missing. Change Framed-Ipv6-Prefix to Framed-IPv6-Prefix. Logical-Access-ID to Logical-Access-Id Physical-Access-ID to Physical-Access-Id Bertz Expires December 31, 2017 [Page 19] Internet-Draft Diameter Specification Recommendations June 2017 4.2.25. 3GPP TS 29.368 For TS 29.368 [TGPP.29.368], processing took approximately 20 minutes TS used in imported AVP tables. Command Codes were abbreviated in such a way that they had to be changed so the software could match them up properly. 'Feature-Supported-In-Final-Target AVP' in the AVP definitions table. External-Id used instead of External-Identifier. 4.2.26. 3GPP TS 29.128 For TS 29.128 [TGPP.29.128], processing took approximately 30 minutes Result Codes were not found DRMP definitions are not handled. Non-IP-Data had type of OctetString 4.2.27. 3GPP TS 29.173 For TS 29.173 [TGPP.29.173], processing took approximately 25 minutes 4.2.28. 3GPP TS 29.217 Processing took approximately 43 minutes. The Modify-Uecontext-Request / Answer command definitions did not match anything in the Command Table. 4.2.29. 3GPP TS 29.273 For TS 29.273 [TGPP.29.273], processing took 60 minutes. The AN-Trusted enum wasn't picked up by the code. Transport-Acess-Type - misspelling resulting in loss in the document. Case issue - Subscription-ID vs Subscription-Id MIP6-Feature-Vector shows as 64 bit in the document but 32 in RFC 5447. Bertz Expires December 31, 2017 [Page 20] Internet-Draft Diameter Specification Recommendations June 2017 4.2.30. 3GPP TS 29.272 For TS 29.272 [TGPP.29.272], processing took approximately 3 hours. Multiple issues were found but this document was used as a reference for development and not considered in processing efficiencies calculations. Table 7.3.1/1: S6a/S6d, S7a/S7d and S13/S13' specific Diameter AVPs Alert-Reason has type of 'Enumerate' ProSe-Subscription-Data Grouped AVP has a type ID of 'xxx' Supported-Services AVP has a type of 'zzzz' 'Subscriber Status' AVP needs a dash 'Notification- To-UE-User' has a space. 'IDR- Flags' has a space. 'Monitoring Event Report' has multiple spaces. 'eNodeB-ID' and 'Extended-eNodeB-ID' in this spec but 'Id' in defining spec .217 Claims QoS-Capability as a defined AVP but it is part of RFC 5777 Trace-Depth is an enum in 32.422 and had to be manually added. Job-Type reference vague. From the specification, 'The possible values are those defined in 3GPP TS 32.422 [23] for Job-Type.' 'Report Interval' has a space. Preferred-Data-Mode was listed as a Grouped type but is Unsigned32. 4.2.31. 3GPP TS 29.061 For TS 29.2061 [TGPP.29.061], processing took approximately 2 hours. Enums use 'AVP code' vs. 'AVP Code' 3 AVP tables created for 4 of the apps Enums have to be added by hand as they are not tied by application ID Bertz Expires December 31, 2017 [Page 21] Internet-Draft Diameter Specification Recommendations June 2017 Messages did not have App IDs in the CCF headers as they are extensions MBMS-Session-Repetition-Number has 'M.V' ('.' instead of comma) MBMS-User-Data-Mode-Indication Enumeration uses spaces for its label values 3BPP-PDP-Type - Enum defined as RADIUS; not available to parser in Diameter 4.2.32. 3GPP TS 29.212 For TS 29.212 [TGPP.29.212], processing took approximately 7 hours. Logical-Access-ID and Physical-Access-ID have case inconsistencies with other specifications. Acronyms in the command code lines but they do not correlate to previously described acronyms in the document. Table 5c.6.1.1 is incomplete. Periods, '.', were used as separators in AVP tables, e.g.'M.V'. Sd and St use TS-Request and TS-Answer but they are don't have application assigned codes. 'Enumerated' appears in a type definition Incorrect reference of 7863 vs 7683 Manual correction was required in the document. Somehow PCC-Rule- Status did not got the enums it needed. It appears no spacing created an error. Hopefully software can be updated to overcome this. Pre-emption Vulnerability (in the Section's first line) spacing kills the correct name identification. In many Enumerations there is an extra space between 'of type' and 'Enumerated' PCC-Rule-Status has a label of 'TEMPORARILY INACTIVE' Bearer-Control-Mode 'is of type of Enumerated' issue Network-Request-Support Label spaces Bertz Expires December 31, 2017 [Page 22] Internet-Draft Diameter Specification Recommendations June 2017 For the Default-Access AVP - 'The values defined in the Default- Access AVP are the same as the ones defined in IP-CAN-Type AVP.' Also, mentions '3GPP-EPS IP-CAN' as an option but it is not an option in the referenced type. CS-Service-QoS-Request-Operation 'is type of Enumerated, CS-Service-Resource-Failure-Cause AVP (AVP code2814) has a spacing issue 'Logical-Access-ID to 'Logical-Access-Id' CS-Service-QoS-Request-Identifier is in table as CS-Service-Qos- Request-Identifier Some enumerations with duplicate labels, e.g. Specific-Action 5. Recommendations for Specification Improvement and Automation 5.1. Error Reduction The overall recommendations are as follows: The name of all AVPs, Commands and Grouped AVPs appear consistently throughout the document. The letter case MUST be consistent for all names. No spaces should appear in the names. Use of underscores is discouraged except for line continuations in tables. 5.1.1. Defined AVPs This section addresses AVPs defined in the specification. The following recommendations are made: Tables MUST include the following columns: Attribute Name AVP Code Section Defined Data Type Bertz Expires December 31, 2017 [Page 23] Internet-Draft Diameter Specification Recommendations June 2017 AVP Flag Rules for MUST and MUST NOT Tables MAY include Notes and other notations in the column headers but MUST NOT exceed more than 8 lines of text to describe the header. The columns may be separated by space, '|' or both when in text format that follows one of the following styles. All columns except AVP Flags are separated by whitespace and Flag column boundaries are pipe delimited. Pipe delimited columns with the exception of the first column. AVP Names MUST NOT have spaces or underscores. Use '.' or ',' as Flag separators. Although no space is also acceptable. Use of two lines for an AVP is permitted. The following conditions apply. An underscore MUST be used at the end of the first line or at the beginning of the second (not both). An underscore is not a part of the AVP name All other columns except the Name MUST appear on the same line. All Defined AVP Tables in the specification MUST use the same header format. Imported or Re-used AVPs MUST NOT be present in defined AVP tables. Bertz Expires December 31, 2017 [Page 24] Internet-Draft Diameter Specification Recommendations June 2017 Example One AVP Section | |MUST | Attribute Name Code Defined Data Type |MUST| NOT | -----------------------------------------|----+-----| AVP-Name 85 9.8.2 Unsigned32 | M | V | Example Two | AVP | Section | | |MUST | Attribute Name | Code | Defined | Data Type |MUST| NOT | ---------------|------+---------+------------+----+-----| AVP-Name | 85 | 9.8.2 | Unsigned32 | M | V | Figure 2: Accepted Table Patterns An open question exists when multiple AVPs tables are present and associated with a specific application within the specification. How the application can be associated to the table is an open question. 5.1.2. Imported AVPs Imported or Re-used AVPs MUST be included in the specification. A table MUST be present if AVPs are re-used/imported. The table MUST include the AVP and Source document columns. The table MAY include a Comment column. An M-bit column MAY be present as required. The table MUST be pipe delimited when in text format. 5.1.3. Grouped AVPs When a Grouped AVP is refined a Refine keyword is appended to the end of the header. It MUST include an application identifier of the Grouped AVP it refines if that application was not the original specification or 'version' of the Grouped AVP. When the Grouped AVP refines the original definition of the Gropued AVP it SHOULD include the referenced application identifier. The refined Grouped AVP MUST be included in the AVP Import table and NOT in the defined AVPs table. Open question, should the vendor and application identifiers of the application that created be in the Grouped AVP header? Bertz Expires December 31, 2017 [Page 25] Internet-Draft Diameter Specification Recommendations June 2017 When refining a Grouped AVP the following conditions apply: The original AVP MUST be extensible, i.e. it MUST have the '*[AVP]' member. Any refinement of an AVP present in the refined Group MUST adhere to the restrictions, if any, that were defined by inherited Groups. For example, if a Grouped AVP refines an attribute 'Foo' to the range X*Y and 'Foo'x is defined in the original AVP with a range of A*B then X >= A and Y <= B. AVPs retained without further restriction of the number of occurrences MUST be kept in the Refining AVP's definition otherwise they are assumed to be dropped from the new AVP definition. Otherwise, it is impossible to determine the Author's intent. Open question, can a Grouped AVP have a range limited [AVP] member, e.g. *5[AVP]? Figure Figure 3 shows an example refinement. In it all but the User- Name AVP are dropped in the new definition. From TS 29.336 User-Identifier ::= [User-Name] [MSISDN] [External-Identifier] [LMSI] *[AVP] From TS 29.128 User-Identifier ::= [User-Name] *[AVP] Figure 3: Refined AVP from TS 29.128 and TS 29.336 5.1.4. Command Errors The largest issue with Commands is the inconsistent values between the name, three letter acronym defined in the table and the actual name used in the command definition. Maintaining consistency will resolve this issue. Like Grouped AVP refinement, a Refine keyword is appended to the end of the header. It MUST include an application identifier of the Command it refines if that application was not the original Bertz Expires December 31, 2017 [Page 26] Internet-Draft Diameter Specification Recommendations June 2017 specification or 'version' of the Command. When the Command refines the original definition of the Command it SHOULD include its application identifier. When refining a Command the following conditions apply: The original Command MUST be extensible, i.e. it MUST have the '*[AVP]' member. Any refinement of an AVP present in the refined Command MUST adhere to the restrictions, if any, that were defined by inherited Commands. For example, if a Command refines an attribute 'Foo' to the range X*Y and 'Foo' is defined in the original Command with a range of A*B then X >= A and Y <= B. Commands retained without further restriction of the number of occurrences MUST be kept in the Refining Command's definition otherwise they are assumed to be dropped from the new Commands definition. Otherwise, it is impossible to determine the Author's intent. 5.1.5. Enumeration Errors Enumeration Value Names MUST adhere to alphanumeric and underscore characters. Enumeration Value Names MUST not begin with an underscore. When being defined the format MUST include the label and the value assigned with the label enclosed in parenthesis on a single. Otherwise, this will confusion when the label values end in integers and are close to the numeric value. For example, 'speed_10 10' is okay, 'speed_1010' is a error. This can be avoided by requiring the enclosure of the values in parenthesis, e.g. 'speed_10 (10)' and 'speed_10(10)'. The last example may not be as readable as desired but it can be understood. 5.2. Formats for automated validation This section discusses ways by which further clarity can be defined in a specification and automated validation can occur for a diameter application. Following the recommendations in the previous section will reduce errors but there are still many pieces of information that cannot be programmatically validated. This includes the following: GAP 1: The application identifier and name of an application. Bertz Expires December 31, 2017 [Page 27] Internet-Draft Diameter Specification Recommendations June 2017 GAP 2: The application and vendor identifiers associated with a defined AVP table. GAP 3: The application and vendor identifiers associated with Commands. GAP 4: Reused and newly defined result codes for an application. GAP 5: Easily parsed enumerations that cover all use cases. The following formats show an example of how information could be added to an Appendix to close these gaps. 1: AppFoo ::= 2: Command1-Name-Request C1R 3: Command1-Name-Answer C1A 4: 5: Result-Codes ::= 6: NEW_RESULT (4999) 7: IMPORTED_RESULT IMPORT (4010) Figure 4: Example Application and Result Code Formats GAP 1 is closed in line 1. GAP 3 is closed in lines 1 through 3 while GAP 4 is closed by lines 5 through 7. GAP 2 can be closed by using a common discernable Table Name format, e.g. AppFoo defined AVPs. In this case the Application Name can be looked up and associated to the defined AVP table. Gap 5 can be partially closed by following a pattern similar to Result-Codes but this does not resolve all uses cases. Result-Codes ::= Label_1 (0) LABEL_Two (2) Figure 5: Example Enumeration AVP Further work is required to comprehensively cover all Enumeration Use Cases. 6. IANA Considerations Bertz Expires December 31, 2017 [Page 28] Internet-Draft Diameter Specification Recommendations June 2017 7. Security Considerations This document is informational and provides some guidance on issues related to formatting and possible extensions of the Diameter CCF to improve understanding and code generation capabilities. It has no impact to the Security of Diameter or Diameter applications. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . 8.2. Informative References [I-D.bertz-dime-rfc4006bis] Bertz, L., Dolson, D., ylifshitz@sandvine.com, y., Hakala, H., Mattila, L., Koskinen, J., Stura, M., and J. Loughney, "Diameter Credit-Control Application", draft-bertz-dime- rfc4006bis-01 (work in progress), July 2016. [I-D.ietf-dime-load] Campbell, B., Donovan, S., and J. Trottin, "Diameter Load Information Conveyance", draft-ietf-dime-load-09 (work in progress), March 2017. [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, DOI 10.17487/RFC4004, August 2005, . [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, DOI 10.17487/RFC4950, August 2007, . Bertz Expires December 31, 2017 [Page 29] Internet-Draft Diameter Specification Recommendations June 2017 [RFC5447] Korhonen, J., Ed., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, DOI 10.17487/RFC5447, February 2009, . [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, DOI 10.17487/RFC5777, February 2010, . [RFC5778] Korhonen, J., Ed., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", RFC 5778, DOI 10.17487/RFC5778, February 2010, . [RFC7155] Zorn, G., Ed., "Diameter Network Access Server Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, . [RFC7423] Morand, L., Ed., Fajardo, V., and H. Tschofenig, "Diameter Applications Design Guidelines", BCP 193, RFC 7423, DOI 10.17487/RFC7423, November 2014, . [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. Morand, "Diameter Overload Indication Conveyance", RFC 7683, DOI 10.17487/RFC7683, October 2015, . [RFC7944] Donovan, S., "Diameter Routing Message Priority", RFC 7944, DOI 10.17487/RFC7944, August 2016, . [TGPP.29.061] 3GPP, "Policy and Charging Control (PCC); Reference points", 3GPP TS 29.061 14.3.0, March 2017. [TGPP.29.128] 3GPP, "Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) interfaces for interworking with packet data networks and applications", 3GPP TS 29.128 14.2.0, March 2017. Bertz Expires December 31, 2017 [Page 30] Internet-Draft Diameter Specification Recommendations June 2017 [TGPP.29.154] 3GPP, "Service capability exposure functionality over Nt reference point", 3GPP TS 29.154 14.1.0, March 2017. [TGPP.29.173] 3GPP, "Location Services (LCS); Diameter-based SLh interface for Control Plane LCS", 3GPP TS 29.173 14.0.0, March 2017. [TGPP.29.212] 3GPP, "Policy and Charging Control (PCC); Reference points", 3GPP TS 29.212 14.3.0, March 2017. [TGPP.29.214] 3GPP, "Policy and charging control over Rx reference point", 3GPP TS 29.214 14.3.0, March 2017. [TGPP.29.215] 3GPP, "Policy and Charging Control (PCC) over S9 reference point; Stage 3", 3GPP TS 29.215 14.1.0, March 2017. [TGPP.29.217] 3GPP, "Policy and Charging Control (PCC); Congestion reporting over Np reference point", 3GPP TS 29.217 14.1.0, March 2017. [TGPP.29.229] 3GPP, "Cx and Dx interfaces based on the Diameter protocol; Protocol details", 3GPP TS 29.229 14.1.0, March 2017. [TGPP.29.272] 3GPP, "Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol", 3GPP TS 29.272 14.3.0, March 2017. [TGPP.29.273] 3GPP, "Evolved Packet System (EPS); 3GPP EPS AAA interfaces", 3GPP TS 29.273 14.2.0, March 2017. [TGPP.29.329] 3GPP, "Sh interface based on the Diameter protocol; Protocol details", 3GPP TS 29.329 14.2.0, March 2017. Bertz Expires December 31, 2017 [Page 31] Internet-Draft Diameter Specification Recommendations June 2017 [TGPP.29.336] 3GPP, "Home Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applications", 3GPP TS 29.336 14.1.0, March 2017. [TGPP.29.337] 3GPP, "Diameter-based T4 Interface for communications with packet data networks and applications", 3GPP TS 29.337 14.0.0, March 2017. [TGPP.29.338] 3GPP, "Diameter based protocols to support Short Message Service (SMS) capable Mobile Management Entities (MMEs)", 3GPP TS 29.338 14.1.0, March 2017. [TGPP.29.343] 3GPP, "Proximity-services (ProSe) function to ProSe application server aspects (PC2); Stage 3", 3GPP TS 29.343 14.1.0, March 2017. [TGPP.29.344] 3GPP, "Proximity-services (ProSe) function to Home Subscriber Server (HSS) aspects; Stage 3", 3GPP TS 29.344 14.1.0, March 2017. [TGPP.29.345] 3GPP, "Inter-Proximity-services (Prose) function signalling aspects; Stage 3", 3GPP TS 29.345 14.1.0, March 2017. [TGPP.29.368] 3GPP, "Tsp interface protocol between the MTC Interworking Function (MTC-IWF) and Service Capability Server (SCS)", 3GPP TS 29.368 14.1.0, March 2017. [TGPP.29.468] 3GPP, "Group Communication System Enablers for LTE (GCSE_LTE); MB2 reference point; Stage 3", 3GPP TS 29.468 14.1.0, March 2017. [TGPP.32.299] 3GPP, "Telecommunication management; Charging management; Diameter charging applications", 3GPP TS 32.299 14.3.0, March 2017. Bertz Expires December 31, 2017 [Page 32] Internet-Draft Diameter Specification Recommendations June 2017 Author's Address Lyle Bertz Sprint 6220 Sprint Parkway Overland Park, KS 66251 United States Email: lylebe551144@gmail.com Bertz Expires December 31, 2017 [Page 33]