idnits 2.17.1 draft-bertz-dime-diamimpr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Enumeration Value Names MUST not begin with an underscore. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 29, 2017) is 2307 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AVP' is mentioned on line 1190, but not defined -- Looks like a reference, but probably isn't: '223' on line 857 -- Looks like a reference, but probably isn't: '23' on line 977 == Missing Reference: 'User-Name' is mentioned on line 1205, but not defined == Missing Reference: 'MSISDN' is mentioned on line 1198, but not defined == Missing Reference: 'External-Identifier' is mentioned on line 1199, but not defined == Missing Reference: 'LMSI' is mentioned on line 1200, but not defined Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions L. Bertz 3 Internet-Draft Sprint 4 Intended status: Standards Track December 29, 2017 5 Expires: July 2, 2018 7 Diameter Specification Recommendations 8 draft-bertz-dime-diamimpr-01 10 Abstract 12 This document reports on formatting errors, uses cases, and 13 inconsistencies found in various standards specifications related to 14 the Diameter interface requirements. Recommendations are made to 15 reduce errors, support common use cases and build specifications in 16 such a way that programmatic verification of Diameter specifications 17 can be done with minimal to no errors. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 2, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 67 3. Survey of Existing Specifications . . . . . . . . . . . . . . 4 68 3.1. Summary of Challenges and Errors . . . . . . . . . . . . 6 69 3.2. Summary of Indirect Use Cases . . . . . . . . . . . . . . 7 70 3.2.1. Refinements . . . . . . . . . . . . . . . . . . . . . 7 71 3.2.2. Enumerations . . . . . . . . . . . . . . . . . . . . 8 72 3.3. Summary of Ingestion Barriers . . . . . . . . . . . . . . 8 73 4. Specification Survey . . . . . . . . . . . . . . . . . . . . 10 74 4.1. Survey Process . . . . . . . . . . . . . . . . . . . . . 10 75 4.2. Summary of Errors And Use Cases . . . . . . . . . . . . . 11 76 4.2.1. RFC 4004 . . . . . . . . . . . . . . . . . . . . . . 11 77 4.2.2. RFC 4006 bis (draft 03) . . . . . . . . . . . . . . . 11 78 4.2.3. RFC 4950 . . . . . . . . . . . . . . . . . . . . . . 12 79 4.2.4. RFC 5447 . . . . . . . . . . . . . . . . . . . . . . 12 80 4.2.5. RFC 5777 . . . . . . . . . . . . . . . . . . . . . . 12 81 4.2.6. RFC 5778 . . . . . . . . . . . . . . . . . . . . . . 13 82 4.2.7. Draft Diameter Load . . . . . . . . . . . . . . . . . 13 83 4.2.8. RFC 6733 . . . . . . . . . . . . . . . . . . . . . . 13 84 4.2.9. RFC 7155 . . . . . . . . . . . . . . . . . . . . . . 13 85 4.2.10. RFC 7683 . . . . . . . . . . . . . . . . . . . . . . 14 86 4.2.11. RFC 7944 . . . . . . . . . . . . . . . . . . . . . . 14 87 4.2.12. 3GPP TS 29.214 . . . . . . . . . . . . . . . . . . . 14 88 4.2.13. 3GPP TS 29.229 . . . . . . . . . . . . . . . . . . . 14 89 4.2.14. 3GPP TS 29.468 . . . . . . . . . . . . . . . . . . . 15 90 4.2.15. 3GPP TS 29.345 . . . . . . . . . . . . . . . . . . . 15 91 4.2.16. 3GPP TS 29.344 . . . . . . . . . . . . . . . . . . . 15 92 4.2.17. 3GPP TS 29.343 . . . . . . . . . . . . . . . . . . . 16 93 4.2.18. 3GPP TS 29.338 . . . . . . . . . . . . . . . . . . . 16 94 4.2.19. 3GPP TS 29.337 . . . . . . . . . . . . . . . . . . . 16 95 4.2.20. 3GPP TS 29.336 . . . . . . . . . . . . . . . . . . . 17 96 4.2.21. 3GPP TS 29.329 . . . . . . . . . . . . . . . . . . . 17 97 4.2.22. 3GPP TS 32.299 . . . . . . . . . . . . . . . . . . . 17 98 4.2.23. 3GPP TS 29.154 . . . . . . . . . . . . . . . . . . . 19 99 4.2.24. 3GPP TS 29.215 . . . . . . . . . . . . . . . . . . . 19 100 4.2.25. 3GPP TS 29.368 . . . . . . . . . . . . . . . . . . . 20 101 4.2.26. 3GPP TS 29.128 . . . . . . . . . . . . . . . . . . . 20 102 4.2.27. 3GPP TS 29.173 . . . . . . . . . . . . . . . . . . . 20 103 4.2.28. 3GPP TS 29.217 . . . . . . . . . . . . . . . . . . . 20 104 4.2.29. 3GPP TS 29.273 . . . . . . . . . . . . . . . . . . . 20 105 4.2.30. 3GPP TS 29.272 . . . . . . . . . . . . . . . . . . . 21 106 4.2.31. 3GPP TS 29.061 . . . . . . . . . . . . . . . . . . . 21 107 4.2.32. 3GPP TS 29.212 . . . . . . . . . . . . . . . . . . . 22 108 5. Recommendations for Specification Improvement and Automation 23 109 5.1. Error Reduction . . . . . . . . . . . . . . . . . . . . . 23 110 5.1.1. Defined AVPs . . . . . . . . . . . . . . . . . . . . 23 111 5.1.2. Imported AVPs . . . . . . . . . . . . . . . . . . . . 25 112 5.1.3. Grouped AVPs . . . . . . . . . . . . . . . . . . . . 25 113 5.1.4. Command Errors . . . . . . . . . . . . . . . . . . . 26 114 5.1.5. Enumeration Errors . . . . . . . . . . . . . . . . . 27 115 5.2. Formats for automated validation . . . . . . . . . . . . 27 116 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 117 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 118 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 119 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 120 8.2. Informative References . . . . . . . . . . . . . . . . . 29 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 123 1. Introduction 125 This document identifies common errors and uses of Diameter in order 126 to document requirements and possible extensions to the Diameter 127 Command Code Format (CCF) and other formats, e.g. Grouped Attribute 128 Value Pair (AVP) format defined in [RFC6733]. It is by no means an 129 exhaustive analysis of all Diameter specifications but provides a 130 survey of a few dozen RFCs and 3GPP Technical Specifications to 131 determine what improvements can be made in Diameter specifications. 133 There are no issues with respect to over the wire communication of 134 Diameter as evidenced by the successful implementation of Diameter 135 applications based upon the specifications surveyed in this document. 136 However, the development and implementation time of Diameter 137 applications can be significantly improved when errors and 138 inconsistencies of the message format as documented in the 139 specifications are minimized or non-existent. An automated tool was 140 developed and used to perform the survey analysis of the technical 141 specifications. The tool would perform automated checking, syntax 142 validation, and language generation and was ran against the various 143 specifications to set a benchmark on the current state and quality of 144 the Diameter specifications. The '.dia' format of a fork of the 145 diafuzzer project (https://github.com/Orange-OpenSource/diafuzzer) 146 was used. It is a simple, deterministic format that provides 147 semantic cross checks of Diameter specifications. 149 With the goal of automated '.dia' format in mind a survey of various 150 Diameter related RFCs and 3GPP Technical Specifications was executed. 151 During the process several issues, errors, omissions and usage 152 patterns were discovered, and they are outlined in section 4 153 (Specification Survey) of this document. 155 Diameter Applications Design Guidelines [RFC7423] does an excellent 156 job of noting common diameter desing use cases but it does not 157 describe how the CCF or related grammers may represent some of these 158 scenarios. To do this the '.dia' format was extended. A few new use 159 cases were also identified that were not covered in [RFC7423]. 161 2. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 3. Survey of Existing Specifications 169 The tool was ran against the following standards specifications for 170 diameter applications: 172 RFC 4004 [RFC4004] 174 RFC 4006 bis [I-D.bertz-dime-rfc4006bis] 176 RFC 4950 [RFC4950] 178 RFC 5447 [RFC5447] 180 RFC 5777 [RFC5777] 182 RFC 5778 [RFC5778] 184 Diameter Load (draft) [I-D.ietf-dime-load] 186 RFC 6733 [RFC6733] 188 RFC 7155 [RFC7155] 190 RFC 7683 [RFC7683] 191 RFC 7944 [RFC7944] 193 3GPP TS 29.214 [TGPP.29.214] 195 3GPP TS 29.345 [TGPP.29.345] 197 3GPP TS 29.344 [TGPP.29.344] 199 3GPP TS 29.343 [TGPP.29.343] 201 3GPP TS 29.338 [TGPP.29.338] 203 3GPP TS 29.337 [TGPP.29.337] 205 3GPP TS 29.336 [TGPP.29.336] 207 3GPP TS 29.329 [TGPP.29.329] 209 3GPP TS 32.299 [TGPP.32.299] 211 3GPP TS 29.154 [TGPP.29.154] 213 3GPP TS 29.215 [TGPP.29.215] 215 3GPP TS 29.368 [TGPP.29.368] 217 3GPP TS 29.128 [TGPP.29.128] 219 3GPP TS 29.173 [TGPP.29.173] 221 3GPP TS 29.217 [TGPP.29.217] 223 3GPP TS 29.273 [TGPP.29.273] 225 3GPP TS 29.272 [TGPP.29.272] 227 3GPP TS 29.061 [TGPP.29.061] 229 3GPP TS 29.212 [TGPP.29.212] 231 3GPP TS 32.299 [TGPP.32.299] 233 3GPP TS 29.229 [TGPP.29.229] 235 3GPP TS 29.468 [TGPP.29.468] 237 3.1. Summary of Challenges and Errors 239 Enumeration issues have their own section below. General issues 240 include but are not limited to: 242 Spelling and spacing errors. 244 Inconsistent Table formats over time. Arguably this reflects the 245 changes in Diameter but these inconsistencies occur with documents 246 released in close time frames. There are also too many formats to 247 claim it is a 'change over time' and not just an inconsistency 248 issue. 250 Missing AVPs and/or AVP Code values. 252 Case Sensitive inconsistencies. 254 The wrong name for AVPs in Tables, referenced across specs, etc. 255 that have the same AVP Code. 257 Claiming an AVP is defined in a spec when in fact it is 258 referenced. 260 Incorrect references. 262 Not noting an AVP is referenced at all but including it in a 263 Grouped AVP or Command. 265 Some AVPs mentioned in Grouped AVPs and not defined anywhere. 266 This happened a few times in accounting related 3GPP 267 specifications. 269 Enumerations do not have a specific format in the base specificaton 270 [RFC6733]. Over the wire the labels themselves are not used as the 271 value is transported in integer formats. When received by a Client 272 or Server the value is checked against a list of valid values. The 273 label only appears in displayed information for errors, logging, etc. 274 However, many of the specifications used varying case, spaces and 275 formats such as parenthesis around numbers, tables, numbers then 276 labels, labels then numbers, etc. 278 An algorithm keying off of the expression 'is of type Enumerated' was 279 used to figure out the text between enumerations. A function was 280 then used to attempt to parse various label patterns, generate a 281 label that may be acceptable to a coding language and capture the 282 value assigned to the label. This yielded partial success. In some 283 cases, especially billing in 3GPP, hand edits were required to fix 284 duplicate labels and formats that were inconsistent with the rest of 285 the document's enumerations. 287 A few cases even referenced their values as coming from other enums 288 or registries associated with the IETF or other standards 289 organizations. These were removed in some cases due to their size 290 while others were copied from the existing enumeration file in the 291 diafuzzer project if it had already been generated. 293 Although enumerations are now available in the intermediate '.dia' 294 format, many of the labels will not be valid in specific programming 295 languages. More work is required regarding enumerations to 296 accommodate these situations. 298 3.2. Summary of Indirect Use Cases 300 Several Use Cases appeared that where the dia format was extended to 301 capture them. 303 3.2.1. Refinements 305 Refinement (Extension) of Commands and Grouped AVPs. This is a case 306 where the same AVP/Command is referenced, i.e. same code or vendor/ 307 code combination but the underlying members of the structure are 308 different. Two variants of this were found: 310 The base (original definition) of the structure was refined. In 311 this case, the 'Refines' Statement in the header may not include 312 the application. 314 A refinement of a refinement. In this case the specific 315 refinement (AVP + App ID it was specified in) was the part of the 316 refinement clause. 318 Note: this is not inheritance. In inheritance the children also 319 inherit the attributes (AVPs) of the parent. In many cases the new 320 definition removed some of the parents AVPs or further limited the 321 occurrence amount of the AVPs. 323 Refinements can only occur if the Command/Grouped AVP is extensible, 324 i.e. it includes *[AVP] in its definition. 326 The rationale for this can be shown by example. A value of 2[AVP] 327 would not be considered extensible and its behavior is undefined. 328 Can someone limit the number of AVPs present in a Command/Grouped AVP 329 when that value is less than the total sum of the upper bounds of all 330 member AVPs. For example, if a Grouped AVP permits at most 2 331 occurrences of AVP member "X" and 2 of AVP member "Y", how/why could/ 332 would one limit the Grouped AVP to no more than 3 AVPs? 334 In the dia format Refinement is captured by adding 'Refines 335 [application id]' at the end of the header/Grouped AVP definition. 337 3.2.2. Enumerations 339 Enumeration use cases included definitions that referenced 341 other Enumerations 343 registries found on the web 345 In the second case the Enumeration was typically removed. 347 In a few cases Enumerations referenced other enumerations and then, 348 in Notes, limited the values (was a proper subset). The opposite 349 case (a proper superset) never presented itself. 351 Later specifications assigned Unsigned32 as a value in what appears 352 to be an attempt to avoid registries or provide some pseudo 353 extensibility. The exact purpose is actually unclear. 355 3.3. Summary of Ingestion Barriers 357 Errors, inconsistencies and Use Cases that could not be easily 358 fulfilled aside. Format differences hampered our ability to quickly 359 ingest Diameter strcutures from specifications. The following is a 360 list of patterns for just AVP header tables: 362 Pattern 1: Parses the original table format for AVPs defined in an 363 IETF spec. 365 The header for an RFC is 366 AVP Section | | |SHLD|MUST| | 367 Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr| 369 Pattern 2: Parses the original table format for AVPs defined in a 370 3GPP spec 372 Attribute Name|AVP Code|Section defined|Value Type|Must|May|Should - 373 not| Must not | May Encr. | 375 Pattern 3: Parses the original table format for AVPs defined for 376 freediameter is BUT some rows define a spec boundary 377 such as the row below the header in this example 379 |Attribute Name|Code|Section|Data|MUST|MAY|SHLD NOT|MUST NOT|Encr| 381 Pattern 4: Parses the original table format for AVPs defined in 382 later IETF specs. 384 The header for an RFC is 385 | | AVP | Section | | |MUST | 386 | Attribute Name | Code | Defined | Data Type |MUST| NOT | 388 An AVP can be 2-line 389 Accounting- 483 9.8.7 Enumerated | M | V | 390 Realtime-Required | | | 392 Pattern 5: Parses the original table format for AVPs defined in 393 some IETF specs like RFC 7155. 395 The header for an RFC is 396 | | Section | |MUST | 397 | Attribute Name | Defined |MUST| NOT | 399 Pattern 6: Parses the original table format for AVPs defined in some 400 IETF specs that don't define applications.. 402 The header for an RFC is 403 | | AVP | Section | | 404 | Attribute Name | Code | Defined | Data Type | 406 Pattern 7: Parses the original table format for AVPs defined in 407 an IETF spec. 409 The header for an RFC is 410 AVP Section | |MUST| 411 Attribute Name Code Defined Data Type |MUST| NOT| 413 Pattern 8: Parses the original table format for AVPs defined in 414 later IETF specs. 416 The header for an RFC is 417 | | AVP | Section | | | MAY |MUST | 418 | Attribute Name | Code | Defined | Data Type |MUST| | NOT | 420 An AVP can be 2-line 421 Accounting- 483 9.8.7 Enumerated | M | V | 422 Realtime-Required | | | 424 Pattern 9: Parses the original table format for AVPs defined in a 425 3GPP spec 426 Attribute Name|AVP Code|Clause defined|Value Type|Must|May|Should - 427 not|Must not| 429 Pattern 10: Parses the original table format for AVPs defined in a 430 3GPP spec 432 Attribute Name|AVP Code|Value Type|Must|May|Should not|Must not| 434 Figure 1: Table Patterns 436 Even with the patterns present some cleanup for "Notes..." was 437 required to get the headers parsable. 439 Not all specifications used an import table. In fact some inter- 440 mixed the tables used to note AVPs defined in the spec and those that 441 were referenced. Some columns were removed to ensure that they fit 442 within known formats as well. In other words, there are more formats 443 in the specifications than shown here but with some manipulation they 444 can be reduced to this core set. 446 For AVP imports a 3-column and 4-column format were common. Further 447 they often had references that needed to be removed (an enhancement 448 is planned to overcome this in the test code. 450 Multiple application specific AVP tables that occurred in a single 451 spec and unified. This was for research convenience but will hamper 452 the generation of small dictionaries. 454 Command codes have a long name and three letter acronym typically in 455 a table. However, neither of those were used in the definition. For 456 example, it is quite common to see Re-Authorization-Request and RAR 457 but Re-Auth-Request in the command code definition. 459 There is no easy, programmatic way to identify an application and 460 relations to command codes or result codes. 462 4. Specification Survey 464 4.1. Survey Process 466 The current process for performing validation is to perform the 467 following tasks: 469 Separate AVP and AVP import tables. The primary goal of this was 470 to study the table formats to develop code to process them. 472 Save the file in a text format. This document is then modified to 473 correct the errors. 475 'Repair' enumerations as required through the use of a separate 476 enum file that is modified as issues are discovered. 478 Create a filter format file that captured data that was hard to 479 find in the specifcation related to Diameter Applications. 481 The time spent for each document is the total amount of time from 482 start to finish where the various files were split as described above 483 and the software was then ran. As errors were discovered they were 484 documented and then, as required, repaired. In some cases new 485 software was developed to accommodate new use cases or formats. That 486 was added to the total processing time for the document unless 487 otherwise noted. 489 4.2. Summary of Errors And Use Cases 491 4.2.1. RFC 4004 493 For RFC 4004 [RFC4004], processing took approximately 20 minutes. 494 Defect corrections were approximately an hour. 496 The AVP Table is a unique format. Line continuations of the table 497 are not consistent. 499 Enumerations are backwards - # Label 501 Some issues were noted but not resolved in 4004. See 502 https://www.ietf.org/mail-archive/web/dime/current/msg02053.html 504 Note that MIP-MN-FA-SPI, MIP-MN-HA-SPI and MIP-HA-to-MN-SPI are 505 missing in the specification. They were removed from their 506 respective Grouped AVPs. 508 MIP-Nonce is in the AVP definition but MIP-nonce (lowercase 'n' 509 for nonce) in Grouped definitions 511 4.2.2. RFC 4006 bis (draft 03) 513 For RFC 4006 bis [I-D.bertz-dime-rfc4006bis], processing took 514 approximately 25 minutes. 516 The AVP table contains inconsistent continuation lines. 518 No import tables have been provided and had to be constructed. 520 Had to change the User-Equipment-Info-Type AVP to the format of 521 'AVP (AVP Code XXX) is of type Enumerated' to keep the pattern to 522 one type. 524 Had to stub in TBD values. 526 Misspelling of IPFiltrRule in table. 528 Many enums referenced to registry values in the spec. 530 Section 8.6 removes dashes for Check Balance Result 532 Redirect-Address-Type Enumerations have spacing so appear as 533 duplicates. 535 CC-Session-Failover was phrased as 'is type of Enumerated' instead 536 of 'is of type Enumerated' 538 4.2.3. RFC 4950 540 For RFC 4950 [RFC4950], processing took approximately 15 minutes. No 541 major issues were found. 543 4.2.4. RFC 5447 545 For RFC 5447 [RFC5447], processing took approximately 10 minutes. No 546 major issues were found. 548 4.2.5. RFC 5777 550 For RFC 5777 [RFC5777], processing took approximately 3 hours. 552 A unique AVP table format. 554 Had to hand enter ALL Enum formats. 556 The approach taken for enum processing is not correct for this 557 document. 559 Treatment-Action listed as Grouped in AVP table 561 IP-Bit-Mask-Width not present in table 563 4.1.7.7 and table are inconsistent with AVP definition used in 564 groups 'IP-Bit-Mask-Width' vs. 'IP-Mask-Bit-Mask-Width' 566 Filter-Rule's use of ';' for comment is unconventional in parsing 568 4.2.6. RFC 5778 570 For RFC 5778 [RFC5778], processing took 24 minutes. 572 Continuations in AVP tables are inconsistent which required hand 573 editing. The continuation '-' sometimes appears on the first line 574 or not until the second which will require more complex code to 575 deal with the situation. 577 Imports of AVPs were mixed in with the table definitions 578 specification. This took the most time work out. 580 Subtype field of the MN-HA and MN-AAA authentication mobility 581 options are not defined in spec and needed to be stitched in 582 (corrected) later. 584 Although noted properly in text, MIP-Session-Key, MIP-Algorithm- 585 Type, MIP-Replay-Mode was not listed as being imported from an RFC 586 in the AVP table. 588 4.2.7. Draft Diameter Load 590 For Diameter Load [I-D.ietf-dime-load], processing completed by hand 591 in 10 minutes. IANA allocations have occurred but the document has 592 not left editors queue which means scripts would not work anyway 594 4.2.8. RFC 6733 596 For RFC 6733 [RFC6733], processing took approximately 15 minutes. 598 Continuations were inconsistent. 600 The spec does not follow its own CCF. 602 4.2.9. RFC 7155 604 For RFC 7155 [RFC7155], processing took several hours. The original 605 RFC was used to fill in many of the gaps in the AVP table code. 607 AVPs only used for compatibility are in the messages but not 608 mentioned in the document, e.g. NAS-Identifier is still present. 610 RA-XXX to Re-Auth but Command acronyms, names and custom names are 611 inter-mixed which is a bit confusing and makes it problematic to 612 automate. 614 Hand stitched the enum values which often pointed to entire 615 registries 617 4.2.10. RFC 7683 619 For RFC 7683 [RFC7683], processing took approximately 40 minutes. 621 The AVP table has a unique format. 623 Continuations were on the second line requiring look ahead logic. 625 4.2.11. RFC 7944 627 For RFC 7944 [RFC7944], processing took approximately 10 minutes. No 628 major issues were found. 630 4.2.12. 3GPP TS 29.214 632 For TS 29.214 [TGPP.29.214], processing took approximately 45 633 minutes. 635 In the AVP tables a dot is used as a separator instead of a comma. 637 In the Specific-Action AVP, the Label 'Void' occurs twice. A hand 638 modification was made. 640 The Service-Info-Status AVP has spaces between the names in the 641 labels. This was corrected. 643 4.2.13. 3GPP TS 29.229 645 For TS 29.229 [TGPP.29.229], processing this took 2 hours; 20 646 minutes. 648 Many AVPs are listed as being DEFINED in the specification but 649 they are references. 651 It does not import RFC 4005, 7155 or 4006 despite using their 652 AVPs. 654 Although restored in Dec 2011 in a change request, Wildcarded-IMPU 655 was not added back to the AVP table Table 6.3.1: Diameter 656 Multimedia Application AVPs 658 Line-Identifier also does not appear in the Table and this AVP has 659 Vendor Id ETSI (13019) 661 4.2.14. 3GPP TS 29.468 663 For TS 29.468 [TGPP.29.468], processing took approximately 60 minutes 665 Another AVP Table format. 667 The Commands were abbreviated in a manner not seen elsewhere in 668 the document, e.g. GA-Request is only used in the command 669 definition. 671 AVP Definitions table removes dashes of the Grouped AVPs. 673 Duplicate AVP names with different codes for MBMS-GW-SSM-IP- 674 Address and MBMS-GW-SSM-Ipv6-Address. 676 TMGI-Number in the Grouped AVP but it is defined in the table as 677 TMGINumber. 679 4.2.15. 3GPP TS 29.345 681 For TS 29.345 [TGPP.29.345], processing took approximately 70 minutes 683 AVP Table inter-mixes '.' and ',' separation in the flags fields. 684 Code was finally written to overcome this. 686 In the AVP Table, App-Identifier was typed as 'Group' and not 687 'Grouped'. 689 In the AVP Table, 'Assistance-info' was incorrect case for 'Info'. 691 Section 6.3.31, WiFi-P2P-Assistance-Iinfo has an extra 'i' in it 693 User-Identity's, ProSe-Response-Code's and ProSe-Query-Code's 694 origin are unclear. They is not in a reference section but in 695 several groups. 697 Discovery-Auth-Request and Match-Report-Info use incorrect case - 698 ProSe-App-ID. 700 ProSe-Query-Code and ProSe-Response-Code are noted in Grouped AVPs 701 but do not exist elsewhere in the spec. 703 4.2.16. 3GPP TS 29.344 705 For TS 29.344 [TGPP.29.344], processing took approximately 50 minutes 707 ProSe-Subscriber-Information-Request is the name for ProSe- 708 Initial-Location-Information-Request. 710 Authorized-Discovery-Range was not listed as a defined AVP and has 711 no values assigned. Filled in as 3708 but these sections are not 712 present in 29.230 at all 714 4.2.17. 3GPP TS 29.343 716 For TS 29.343 [TGPP.29.343], processing took approximately 10 minutes 718 No issues. 720 4.2.18. 3GPP TS 29.338 722 For TS 29.338 [TGPP.29.338], processing took approximately 55 minutes 724 Table 6.3.2.2/1: Command-Code values for SGd/Gdd has spaces in the 725 command names. 727 Send-Routing-info-for-SM-Answer in the command definition is 728 lowercase and can't be linked to the command table. 730 Not an issue but an observation. There is no Load Control draft 731 reference. 733 SGSN-Absent-User-Diagnostic SM has a space in it in the AVP table 735 SM-Delivery- Failure-Cause has spacing issue in table. 737 SMSMI-Correlation-ID has dash issues in its definition.. 739 SM-Delivery-Not-Intended has values as a list with ending of ',' 740 and period. Similar issues for SM-RP-MTI 742 MME-SM-Delivery-Outcome- There is an extra > at the end of the 743 header definition 745 SM-Enumerated-Delivery-Failure-Cause used ',' and '.' for the 746 list. Also the data type 'Enumerated' was not capitalized causing 747 a miss in the system. 749 MSISDN import is from 29.329 and not 23.329 751 4.2.19. 3GPP TS 29.337 753 For TS 29.337 [TGPP.29.337], processing took approximately 20 minutes 755 No issues. 757 4.2.20. 3GPP TS 29.336 759 For TS 29.336 [TGPP.29.336], processing took approximately 9 hours as 760 it was used for testing. 762 Spacing issues in AVP tables for Maximum Latency, Maximum Response 763 Time 765 Scheduled-communication-time definition is lower case. 767 Periodic-Time is lowercase in the AVP Table. 769 Found a '/' in the Flags portion of the AVP Table. 771 eNodeB-ID and Extended-eNodeB-ID in this spec but 'Id' in defining 772 spec .217 774 4.2.21. 3GPP TS 29.329 776 For TS 29.329 [TGPP.29.329], processing took approximately a billion 777 minutes 779 Spacing issues in AVP User-Data-Request command. 781 Does not specify the Supported-Features, Feature-List, Feature- 782 List-ID, Supported-Applications, Server-Name, Public-Identity from 783 another app in the AVP table. 785 4.2.22. 3GPP TS 32.299 787 For TS 32.399 [TGPP.32.299], processing took approximately 9 hours 789 Unique Table format. 791 Required to remove imported AVPs and create a new table. 793 UTF8string case incorrect in AVP table for a number of entries. 795 ProSe-Direct-Communication- Transmission-Data-Container and 796 Status- AS-Code have spaces. 798 LCS-Client-ID changed to LCS-Client-Id. 800 ProSe-Direct-Communication- Transmission-Data-Container 802 Related- Change-Condition- Information 804 Trunk-Group-ID was Trunk-Group-Id in AVP table. 806 Wrote more software to deal with the values flipped in enums (int 807 first then label) 809 Enums were a large issue so hand editing had to take place to 810 clean up the values. 812 'is of type of Enumerated' and 'is of type enumerated' were 813 present in the document 815 AoC-Service-Type had to be repaired by hand as the algorithm 816 picked up the overloaded Change-Condition values 818 MBMS-User-Service-Type 820 Node-Functionality needs fixing 822 Online-Charging-Flag had to be corrected 824 Originator had missing elements 826 Void numbers get caught in enums 828 PoC-Event-Type used semicolons 830 ProSe-Direst-Discovery-Mode spelling issue 832 ProSe- Role-Of-UE spacing issue 834 Participant-Access-Priority uses colons in enum labels and mixed 835 descriptions 837 Changed Type-Number Unsigned32 as the registry is too difficult to 838 code 840 Submission-Timestamp not defined 842 PoC-User-Role-Ids instead of PoC-User-Role-IDs 844 Removed [ Monitored-HPLMN-Identifier ] as it made no sense and was 845 not defined 847 [ Prose-Function-PLMN-Identifier ] removed 849 [ VASP-Id ] & [ VAS-Id ] removed from MMS-Information 851 Service-Generic-Information removed from Service-Information 852 defined in OMA-DDS-Charging_Data [223]. 854 [ 3GPP-Session-Stop-Indicator ] removed 856 IM-Information DCD-Information removed from Service-Information 857 defined in OMA-DDS-Charging_Data [223] 859 ePDG-Address vs EPDG-Address 861 M2M-Information removed from Service-Information as it was missing 863 SM-Device-Trigger-Information's Reference-Number removed since it 864 was missing 866 Incoming-Trunk-Group-ID removed 868 4.2.23. 3GPP TS 29.154 870 For TS 29.154 [TGPP.29.154], processing took approximately 10 minutes 872 Variance of a later Table format. 874 Command Codes were abbreviated in such a way that they had to be 875 changed so the software could match them up properly 877 Time-window grouped AVP definition corrected to Time-Window 879 4.2.24. 3GPP TS 29.215 881 For TS 29.215 [TGPP.29.215], processing took approximately 60 minutes 883 S9a* reference table has a TS reference instead of 3GPP TS. 885 UE-Local-IPv6-Prefix type in AVP table is all lower case. 887 Note that ' is of type of Enumerated" was corrected to allow the 888 software to catch the Subsession-Operation and DRA-Binding. 890 Imports are missing. 892 Change Framed-Ipv6-Prefix to Framed-IPv6-Prefix. 894 Logical-Access-ID to Logical-Access-Id 896 Physical-Access-ID to Physical-Access-Id 898 4.2.25. 3GPP TS 29.368 900 For TS 29.368 [TGPP.29.368], processing took approximately 20 minutes 902 TS used in imported AVP tables. 904 Command Codes were abbreviated in such a way that they had to be 905 changed so the software could match them up properly. 907 'Feature-Supported-In-Final-Target AVP' in the AVP definitions 908 table. 910 External-Id used instead of External-Identifier. 912 4.2.26. 3GPP TS 29.128 914 For TS 29.128 [TGPP.29.128], processing took approximately 30 minutes 916 Result Codes were not found 918 DRMP definitions are not handled. 920 Non-IP-Data had type of OctetString 922 4.2.27. 3GPP TS 29.173 924 For TS 29.173 [TGPP.29.173], processing took approximately 25 minutes 926 4.2.28. 3GPP TS 29.217 928 Processing took approximately 43 minutes. 930 The Modify-Uecontext-Request / Answer command definitions did not 931 match anything in the Command Table. 933 4.2.29. 3GPP TS 29.273 935 For TS 29.273 [TGPP.29.273], processing took 60 minutes. 937 The AN-Trusted enum wasn't picked up by the code. 939 Transport-Acess-Type - misspelling resulting in loss in the 940 document. 942 Case issue - Subscription-ID vs Subscription-Id 944 MIP6-Feature-Vector shows as 64 bit in the document but 32 in RFC 945 5447. 947 4.2.30. 3GPP TS 29.272 949 For TS 29.272 [TGPP.29.272], processing took approximately 3 hours. 950 Multiple issues were found but this document was used as a reference 951 for development and not considered in processing efficiencies 952 calculations. 954 Table 7.3.1/1: S6a/S6d, S7a/S7d and S13/S13' specific Diameter 955 AVPs Alert-Reason has type of 'Enumerate' 957 ProSe-Subscription-Data Grouped AVP has a type ID of 'xxx' 959 Supported-Services AVP has a type of 'zzzz' 961 'Subscriber Status' AVP needs a dash 963 'Notification- To-UE-User' has a space. 965 'IDR- Flags' has a space. 967 'Monitoring Event Report' has multiple spaces. 969 'eNodeB-ID' and 'Extended-eNodeB-ID' in this spec but 'Id' in 970 defining spec .217 972 Claims QoS-Capability as a defined AVP but it is part of RFC 5777 974 Trace-Depth is an enum in 32.422 and had to be manually added. 976 Job-Type reference vague. From the specification, 'The possible 977 values are those defined in 3GPP TS 32.422 [23] for Job-Type.' 979 'Report Interval' has a space. 981 Preferred-Data-Mode was listed as a Grouped type but is 982 Unsigned32. 984 4.2.31. 3GPP TS 29.061 986 For TS 29.2061 [TGPP.29.061], processing took approximately 2 hours. 988 Enums use 'AVP code' vs. 'AVP Code' 990 3 AVP tables created for 4 of the apps 992 Enums have to be added by hand as they are not tied by application 993 ID 994 Messages did not have App IDs in the CCF headers as they are 995 extensions 997 MBMS-Session-Repetition-Number has 'M.V' ('.' instead of comma) 999 MBMS-User-Data-Mode-Indication Enumeration uses spaces for its 1000 label values 1002 3BPP-PDP-Type - Enum defined as RADIUS; not available to parser in 1003 Diameter 1005 4.2.32. 3GPP TS 29.212 1007 For TS 29.212 [TGPP.29.212], processing took approximately 7 hours. 1009 Logical-Access-ID and Physical-Access-ID have case inconsistencies 1010 with other specifications. 1012 Acronyms in the command code lines but they do not correlate to 1013 previously described acronyms in the document. 1015 Table 5c.6.1.1 is incomplete. 1017 Periods, '.', were used as separators in AVP tables, e.g.'M.V'. 1019 Sd and St use TS-Request and TS-Answer but they are don't have 1020 application assigned codes. 1022 'Enumerated' appears in a type definition 1024 Incorrect reference of 7863 vs 7683 1026 Manual correction was required in the document. Somehow PCC-Rule- 1027 Status did not got the enums it needed. It appears no spacing 1028 created an error. Hopefully software can be updated to overcome 1029 this. 1031 Pre-emption Vulnerability (in the Section's first line) spacing 1032 kills the correct name identification. 1034 In many Enumerations there is an extra space between 'of type' and 1035 'Enumerated' 1037 PCC-Rule-Status has a label of 'TEMPORARILY INACTIVE' 1039 Bearer-Control-Mode 'is of type of Enumerated' issue 1041 Network-Request-Support Label spaces 1042 For the Default-Access AVP - 'The values defined in the Default- 1043 Access AVP are the same as the ones defined in IP-CAN-Type AVP.' 1045 Also, mentions '3GPP-EPS IP-CAN' as an option but it is not an 1046 option in the referenced type. 1048 CS-Service-QoS-Request-Operation 'is type of Enumerated, 1050 CS-Service-Resource-Failure-Cause AVP (AVP code2814) has a spacing 1051 issue 1053 'Logical-Access-ID to 'Logical-Access-Id' 1055 CS-Service-QoS-Request-Identifier is in table as CS-Service-Qos- 1056 Request-Identifier 1058 Some enumerations with duplicate labels, e.g. Specific-Action 1060 5. Recommendations for Specification Improvement and Automation 1062 5.1. Error Reduction 1064 The overall recommendations are as follows: 1066 The name of all AVPs, Commands and Grouped AVPs appear 1067 consistently throughout the document. 1069 The letter case MUST be consistent for all names. 1071 No spaces should appear in the names. 1073 Use of underscores is discouraged except for line continuations in 1074 tables. 1076 5.1.1. Defined AVPs 1078 This section addresses AVPs defined in the specification. The 1079 following recommendations are made: 1081 Tables MUST include the following columns: 1083 Attribute Name 1085 AVP Code 1087 Section Defined 1089 Data Type 1090 AVP Flag Rules for MUST and MUST NOT 1092 Tables MAY include Notes and other notations in the column headers 1093 but MUST NOT exceed more than 8 lines of text to describe the 1094 header. 1096 The columns may be separated by space, '|' or both when in text 1097 format that follows one of the following styles. 1099 All columns except AVP Flags are separated by whitespace and 1100 Flag column boundaries are pipe delimited. 1102 Pipe delimited columns with the exception of the first column. 1104 AVP Names MUST NOT have spaces or underscores. 1106 Use '.' or ',' as Flag separators. Although no space is also 1107 acceptable. 1109 Use of two lines for an AVP is permitted. The following 1110 conditions apply. 1112 An underscore MUST be used at the end of the first line or at 1113 the beginning of the second (not both). 1115 An underscore is not a part of the AVP name 1117 All other columns except the Name MUST appear on the same line. 1119 All Defined AVP Tables in the specification MUST use the same 1120 header format. 1122 Imported or Re-used AVPs MUST NOT be present in defined AVP 1123 tables. 1125 Example One 1127 AVP Section | |MUST | 1128 Attribute Name Code Defined Data Type |MUST| NOT | 1129 -----------------------------------------|----+-----| 1130 AVP-Name 85 9.8.2 Unsigned32 | M | V | 1132 Example Two 1134 | AVP | Section | | |MUST | 1135 Attribute Name | Code | Defined | Data Type |MUST| NOT | 1136 ---------------|------+---------+------------+----+-----| 1137 AVP-Name | 85 | 9.8.2 | Unsigned32 | M | V | 1139 Figure 2: Accepted Table Patterns 1141 An open question exists when multiple AVPs tables are present and 1142 associated with a specific application within the specification. How 1143 the application can be associated to the table is an open question. 1145 5.1.2. Imported AVPs 1147 Imported or Re-used AVPs MUST be included in the specification. A 1148 table MUST be present if AVPs are re-used/imported. 1150 The table MUST include the AVP and Source document columns. 1152 The table MAY include a Comment column. 1154 An M-bit column MAY be present as required. 1156 The table MUST be pipe delimited when in text format. 1158 5.1.3. Grouped AVPs 1160 When a Grouped AVP is refined a Refine keyword is appended to the end 1161 of the header. It MUST include an application identifier of the 1162 Grouped AVP it refines if that application was not the original 1163 specification or 'version' of the Grouped AVP. When the Grouped AVP 1164 refines the original definition of the Gropued AVP it SHOULD include 1165 the referenced application identifier. 1167 The refined Grouped AVP MUST be included in the AVP Import table and 1168 NOT in the defined AVPs table. 1170 Open question, should the vendor and application identifiers of the 1171 application that created be in the Grouped AVP header? 1172 When refining a Grouped AVP the following conditions apply: 1174 The original AVP MUST be extensible, i.e. it MUST have the 1175 '*[AVP]' member. 1177 Any refinement of an AVP present in the refined Group MUST adhere 1178 to the restrictions, if any, that were defined by inherited 1179 Groups. For example, if a Grouped AVP refines an attribute 'Foo' 1180 to the range X*Y and 'Foo'x is defined in the original AVP with a 1181 range of A*B then X >= A and Y <= B. 1183 AVPs retained without further restriction of the number of 1184 occurrences MUST be kept in the Refining AVP's definition 1185 otherwise they are assumed to be dropped from the new AVP 1186 definition. Otherwise, it is impossible to determine the Author's 1187 intent. 1189 Open question, can a Grouped AVP have a range limited [AVP] member, 1190 e.g. *5[AVP]? 1192 Figure Figure 3 shows an example refinement. In it all but the User- 1193 Name AVP are dropped in the new definition. 1195 From TS 29.336 1196 User-Identifier ::= 1197 [User-Name] 1198 [MSISDN] 1199 [External-Identifier] 1200 [LMSI] 1201 *[AVP] 1203 From TS 29.128 1204 User-Identifier ::= 1205 [User-Name] 1206 *[AVP] 1208 Figure 3: Refined AVP from TS 29.128 and TS 29.336 1210 5.1.4. Command Errors 1212 The largest issue with Commands is the inconsistent values between 1213 the name, three letter acronym defined in the table and the actual 1214 name used in the command definition. Maintaining consistency will 1215 resolve this issue. 1217 Like Grouped AVP refinement, a Refine keyword is appended to the end 1218 of the header. It MUST include an application identifier of the 1219 Command it refines if that application was not the original 1220 specification or 'version' of the Command. When the Command refines 1221 the original definition of the Command it SHOULD include its 1222 application identifier. 1224 When refining a Command the following conditions apply: 1226 The original Command MUST be extensible, i.e. it MUST have the 1227 '*[AVP]' member. 1229 Any refinement of an AVP present in the refined Command MUST 1230 adhere to the restrictions, if any, that were defined by inherited 1231 Commands. For example, if a Command refines an attribute 'Foo' to 1232 the range X*Y and 'Foo' is defined in the original Command with a 1233 range of A*B then X >= A and Y <= B. 1235 Commands retained without further restriction of the number of 1236 occurrences MUST be kept in the Refining Command's definition 1237 otherwise they are assumed to be dropped from the new Commands 1238 definition. Otherwise, it is impossible to determine the Author's 1239 intent. 1241 5.1.5. Enumeration Errors 1243 Enumeration Value Names MUST adhere to alphanumeric and underscore 1244 characters. 1246 Enumeration Value Names MUST not begin with an underscore. 1248 When being defined the format MUST include the label and the value 1249 assigned with the label enclosed in parenthesis on a single. 1250 Otherwise, this will confusion when the label values end in integers 1251 and are close to the numeric value. For example, 'speed_10 10' is 1252 okay, 'speed_1010' is a error. This can be avoided by requiring the 1253 enclosure of the values in parenthesis, e.g. 'speed_10 (10)' and 1254 'speed_10(10)'. The last example may not be as readable as desired 1255 but it can be understood. 1257 5.2. Formats for automated validation 1259 This section discusses ways by which further clarity can be defined 1260 in a specification and automated validation can occur for a diameter 1261 application. 1263 Following the recommendations in the previous section will reduce 1264 errors but there are still many pieces of information that cannot be 1265 programmatically validated. This includes the following: 1267 GAP 1: The application identifier and name of an application. 1269 GAP 2: The application and vendor identifiers associated with a 1270 defined AVP table. 1272 GAP 3: The application and vendor identifiers associated with 1273 Commands. 1275 GAP 4: Reused and newly defined result codes for an application. 1277 GAP 5: Easily parsed enumerations that cover all use cases. 1279 The following formats show an example of how information could be 1280 added to an Appendix to close these gaps. 1282 1: AppFoo ::= 1283 2: Command1-Name-Request C1R 1284 3: Command1-Name-Answer C1A 1285 4: 1286 5: Result-Codes ::= 1287 6: NEW_RESULT (4999) 1288 7: IMPORTED_RESULT IMPORT (4010) 1290 Figure 4: Example Application and Result Code Formats 1292 GAP 1 is closed in line 1. GAP 3 is closed in lines 1 through 3 1293 while GAP 4 is closed by lines 5 through 7. 1295 GAP 2 can be closed by using a common discernable Table Name format, 1296 e.g. AppFoo defined AVPs. In this case the Application Name can be 1297 looked up and associated to the defined AVP table. 1299 Gap 5 can be partially closed by following a pattern similar to 1300 Result-Codes but this does not resolve all uses cases. 1302 Result-Codes ::= 1303 Label_1 (0) 1304 LABEL_Two (2) 1306 Figure 5: Example Enumeration AVP 1308 Further work is required to comprehensively cover all Enumeration Use 1309 Cases. 1311 6. IANA Considerations 1312 7. Security Considerations 1314 This document is informational and provides some guidance on issues 1315 related to formatting and possible extensions of the Diameter CCF to 1316 improve understanding and code generation capabilities. It has no 1317 impact to the Security of Diameter or Diameter applications. 1319 8. References 1321 8.1. Normative References 1323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1324 Requirement Levels", BCP 14, RFC 2119, 1325 DOI 10.17487/RFC2119, March 1997, 1326 . 1328 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1329 Ed., "Diameter Base Protocol", RFC 6733, 1330 DOI 10.17487/RFC6733, October 2012, 1331 . 1333 8.2. Informative References 1335 [I-D.bertz-dime-rfc4006bis] 1336 Bertz, L., Dolson, D., ylifshitz@sandvine.com, y., Hakala, 1337 H., Mattila, L., Koskinen, J., Stura, M., and J. Loughney, 1338 "Diameter Credit-Control Application", draft-bertz-dime- 1339 rfc4006bis-01 (work in progress), July 2016. 1341 [I-D.ietf-dime-load] 1342 Campbell, B., Donovan, S., and J. Trottin, "Diameter Load 1343 Information Conveyance", draft-ietf-dime-load-09 (work in 1344 progress), March 2017. 1346 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., 1347 and P. McCann, "Diameter Mobile IPv4 Application", 1348 RFC 4004, DOI 10.17487/RFC4004, August 2005, 1349 . 1351 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 1352 Extensions for Multiprotocol Label Switching", RFC 4950, 1353 DOI 10.17487/RFC4950, August 2007, 1354 . 1356 [RFC5447] Korhonen, J., Ed., Bournelle, J., Tschofenig, H., Perkins, 1357 C., and K. Chowdhury, "Diameter Mobile IPv6: Support for 1358 Network Access Server to Diameter Server Interaction", 1359 RFC 5447, DOI 10.17487/RFC5447, February 2009, 1360 . 1362 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 1363 Ed., and A. Lior, "Traffic Classification and Quality of 1364 Service (QoS) Attributes for Diameter", RFC 5777, 1365 DOI 10.17487/RFC5777, February 2010, 1366 . 1368 [RFC5778] Korhonen, J., Ed., Tschofenig, H., Bournelle, J., 1369 Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: 1370 Support for Home Agent to Diameter Server Interaction", 1371 RFC 5778, DOI 10.17487/RFC5778, February 2010, 1372 . 1374 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 1375 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 1376 . 1378 [RFC7423] Morand, L., Ed., Fajardo, V., and H. Tschofenig, "Diameter 1379 Applications Design Guidelines", BCP 193, RFC 7423, 1380 DOI 10.17487/RFC7423, November 2014, 1381 . 1383 [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. 1384 Morand, "Diameter Overload Indication Conveyance", 1385 RFC 7683, DOI 10.17487/RFC7683, October 2015, 1386 . 1388 [RFC7944] Donovan, S., "Diameter Routing Message Priority", 1389 RFC 7944, DOI 10.17487/RFC7944, August 2016, 1390 . 1392 [TGPP.29.061] 1393 3GPP, "Policy and Charging Control (PCC); Reference 1394 points", 3GPP TS 29.061 14.3.0, March 2017. 1396 [TGPP.29.128] 1397 3GPP, "Mobility Management Entity (MME) and Serving GPRS 1398 Support Node (SGSN) interfaces for interworking with 1399 packet data networks and applications", 3GPP TS 29.128 1400 14.2.0, March 2017. 1402 [TGPP.29.154] 1403 3GPP, "Service capability exposure functionality over Nt 1404 reference point", 3GPP TS 29.154 14.1.0, March 2017. 1406 [TGPP.29.173] 1407 3GPP, "Location Services (LCS); Diameter-based SLh 1408 interface for Control Plane LCS", 3GPP TS 29.173 14.0.0, 1409 March 2017. 1411 [TGPP.29.212] 1412 3GPP, "Policy and Charging Control (PCC); Reference 1413 points", 3GPP TS 29.212 14.3.0, March 2017. 1415 [TGPP.29.214] 1416 3GPP, "Policy and charging control over Rx reference 1417 point", 3GPP TS 29.214 14.3.0, March 2017. 1419 [TGPP.29.215] 1420 3GPP, "Policy and Charging Control (PCC) over S9 reference 1421 point; Stage 3", 3GPP TS 29.215 14.1.0, March 2017. 1423 [TGPP.29.217] 1424 3GPP, "Policy and Charging Control (PCC); Congestion 1425 reporting over Np reference point", 3GPP TS 29.217 14.1.0, 1426 March 2017. 1428 [TGPP.29.229] 1429 3GPP, "Cx and Dx interfaces based on the Diameter 1430 protocol; Protocol details", 3GPP TS 29.229 14.1.0, March 1431 2017. 1433 [TGPP.29.272] 1434 3GPP, "Evolved Packet System (EPS); Mobility Management 1435 Entity (MME) and Serving GPRS Support Node (SGSN) related 1436 interfaces based on Diameter protocol", 3GPP TS 29.272 1437 14.3.0, March 2017. 1439 [TGPP.29.273] 1440 3GPP, "Evolved Packet System (EPS); 3GPP EPS AAA 1441 interfaces", 3GPP TS 29.273 14.2.0, March 2017. 1443 [TGPP.29.329] 1444 3GPP, "Sh interface based on the Diameter protocol; 1445 Protocol details", 3GPP TS 29.329 14.2.0, March 2017. 1447 [TGPP.29.336] 1448 3GPP, "Home Subscriber Server (HSS) diameter interfaces 1449 for interworking with packet data networks and 1450 applications", 3GPP TS 29.336 14.1.0, March 2017. 1452 [TGPP.29.337] 1453 3GPP, "Diameter-based T4 Interface for communications with 1454 packet data networks and applications", 3GPP TS 29.337 1455 14.0.0, March 2017. 1457 [TGPP.29.338] 1458 3GPP, "Diameter based protocols to support Short Message 1459 Service (SMS) capable Mobile Management Entities (MMEs)", 1460 3GPP TS 29.338 14.1.0, March 2017. 1462 [TGPP.29.343] 1463 3GPP, "Proximity-services (ProSe) function to ProSe 1464 application server aspects (PC2); Stage 3", 3GPP TS 29.343 1465 14.1.0, March 2017. 1467 [TGPP.29.344] 1468 3GPP, "Proximity-services (ProSe) function to Home 1469 Subscriber Server (HSS) aspects; Stage 3", 3GPP TS 29.344 1470 14.1.0, March 2017. 1472 [TGPP.29.345] 1473 3GPP, "Inter-Proximity-services (Prose) function 1474 signalling aspects; Stage 3", 3GPP TS 29.345 14.1.0, March 1475 2017. 1477 [TGPP.29.368] 1478 3GPP, "Tsp interface protocol between the MTC Interworking 1479 Function (MTC-IWF) and Service Capability Server (SCS)", 1480 3GPP TS 29.368 14.1.0, March 2017. 1482 [TGPP.29.468] 1483 3GPP, "Group Communication System Enablers for LTE 1484 (GCSE_LTE); MB2 reference point; Stage 3", 3GPP TS 29.468 1485 14.1.0, March 2017. 1487 [TGPP.32.299] 1488 3GPP, "Telecommunication management; Charging management; 1489 Diameter charging applications", 3GPP TS 32.299 14.3.0, 1490 March 2017. 1492 Author's Address 1494 Lyle Bertz 1495 Sprint 1496 6220 Sprint Parkway 1497 Overland Park, KS 66251 1498 United States 1500 Email: lylebe551144@gmail.com