Skip to main content

Diameter Specification Recommendations
draft-bertz-dime-diamimpr-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Lyle Bertz
Last updated 2017-06-30
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-bertz-dime-diamimpr-00
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 ::= <AVP-Header: 3102, 10415>
            [User-Name]
            [MSISDN]
            [External-Identifier]
            [LMSI]
            *[AVP]

          From TS 29.128
          User-Identifier ::= <AVP-Header: 3102, 10415, Refines>
            [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 ::= <Diameter Application: 10415 101010>
            2: Command1-Name-Request C1R
            3:  Command1-Name-Answer C1A
            4:
            5: Result-Codes ::= <Diameter Result-Codes: 101010>
            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 ::= <Diameter Enumeration: 123, 45678>
              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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
              <http://www.rfc-editor.org/info/rfc6733>.

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,
              <http://www.rfc-editor.org/info/rfc4004>.

   [RFC4950]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
              Extensions for Multiprotocol Label Switching", RFC 4950,
              DOI 10.17487/RFC4950, August 2007,
              <http://www.rfc-editor.org/info/rfc4950>.

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,
              <http://www.rfc-editor.org/info/rfc5447>.

   [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,
              <http://www.rfc-editor.org/info/rfc5777>.

   [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,
              <http://www.rfc-editor.org/info/rfc5778>.

   [RFC7155]  Zorn, G., Ed., "Diameter Network Access Server
              Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,
              <http://www.rfc-editor.org/info/rfc7155>.

   [RFC7423]  Morand, L., Ed., Fajardo, V., and H. Tschofenig, "Diameter
              Applications Design Guidelines", BCP 193, RFC 7423,
              DOI 10.17487/RFC7423, November 2014,
              <http://www.rfc-editor.org/info/rfc7423>.

   [RFC7683]  Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
              Morand, "Diameter Overload Indication Conveyance",
              RFC 7683, DOI 10.17487/RFC7683, October 2015,
              <http://www.rfc-editor.org/info/rfc7683>.

   [RFC7944]  Donovan, S., "Diameter Routing Message Priority",
              RFC 7944, DOI 10.17487/RFC7944, August 2016,
              <http://www.rfc-editor.org/info/rfc7944>.

   [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]