idnits 2.17.1 draft-jones-3gpp-eps-command-codes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 215. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 221. 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 16 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 14, 2008) is 5671 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and M. Jones 3 Extensions (DIME) Bridgewater Systems 4 Internet-Draft L. Morand 5 Intended status: Informational Orange Labs 6 Expires: April 17, 2009 October 14, 2008 8 Diameter Command Codes for 3GPP EPS Diameter Applications 9 draft-jones-3gpp-eps-command-codes-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 17, 2009. 36 Abstract 38 This document describes a set of new IANA Diameter Command Codes to 39 be used in new vendor-specific Diameter applications defined for the 40 Third Generation Partnership Project (3GPP) Evolved Packet System 41 (EPS). 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 58 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 60 Intellectual Property and Copyright Statements . . . . . . . . . . 6 62 1. Introduction 64 The Third Generation Partnership Project (3GPP) is defining the 65 Evolved Packet System (EPS) as part of their Release 8 architecture. 66 As part of this architecture, the interfaces based on the Diameter 67 protocol [RFC3588] required the definition of two new Diameter 68 applications: the 3GPP S6a application (vendor-specific application 69 id: 1677251) and 3GPP S13 application (vendor-specific application 70 id: 1677252), both defined under the 3GPP vendor-id "10415". These 71 Diameter applications are described in [TS29.272]. 73 2. Terminology 75 The base Diameter specification (Section 1.4 of [RFC3588]) defines 76 most of the terminology used in this document. Additionally, the 77 terms and acronyms defined in [TS29.272] are used in this document. 79 3. Command Codes 81 As described in [TS29.272], the 3GPP S6a application specifies the 82 following command pairs: 84 o Update-Location-Request/Answer (ULR/ULA) 86 o Cancel-Location-Request/Answer (CLR/CLA) 88 o Authentication-Information-Request/ Answer (AIR/AIA) 90 o Insert-Subscriber-Data-Request/Answer (IDR/IDA) 92 o Delete-Subscriber-Data-Request/Answer (DSR/DSA) 94 o Purge-UE-Request/Answer (PUR/PUA) 96 o Reset-Request/Answer (RSR/RSA) 98 o Notify-Request/Answer (NOR/NOA) 100 Also described in [TS29.272], the 3GPP S13 application specifies the 101 following command pair: 103 o ME-Identity-Check-Request/Answer (ECR/ECA) 105 4. IANA Considerations 107 This section provides guidance to the Internet Assigned Numbers 108 Authority (IANA) regarding registration of values related to the 109 Diameter protocol, in accordance with BCP 26 [RFC2434]. 111 This document defines values in the namespaces that have been created 112 and defined in the Diameter Base [RFC3588]. The IANA Considerations 113 section of that document details the assignment criteria. Values 114 assigned in this document, or by future IANA action, must be 115 coordinated within this shared namespace. 117 4.1. Command Codes 119 IANA is requested to allocate the following command code values: 121 +------------------------------------------------------------------------+ 122 | Code Command Name Abbreviation Defined in | 123 +------------------------------------------------------------------------+ 124 | tbd Update-Location-Request/Answer ULR/ULA 3GPP TS 29.272 | 125 | tbd Cancel-Location-Request/Answer CLR/CLA 3GPP TS 29.272 | 126 | tbd Authentication-Information-Request/ AIR/AIA 3GPP TS 29.272 | 127 | Answer | 128 | tbd Insert-Subscriber-Data-Request/ IDR/IDA 3GPP TS 29.272 | 129 | Answer | 130 | tbd Delete-Subscriber-Data-Request/ DSR/DSA 3GPP TS 29.272 | 131 | Answer | 132 | tbd Purge-UE-Request/Answer PUR/PUA 3GPP TS 29.272 | 133 | tbd Reset-Request/Answer RSR/RSA 3GPP TS 29.272 | 134 | tbd Notify-Request/Answer NOR/NOA 3GPP TS 29.272 | 135 | tbd ME-Identity-Check-Request/Answer ECR/ECA 3GPP TS 29.272 | 136 +------------------------------------------------------------------------+ 138 5. Security Considerations 140 This document describes command codes used in applications which 141 build on top of the Diameter base protocol and the same security 142 considerations described in [RFC3588] are applicable to this 143 document. No further extensions are required beyond the security 144 mechanisms offered by [RFC3588]. 146 6. Acknowledgements 148 We would like to thank the 3GPP CT4 delegates for their review and 149 comments. 151 7. Normative References 153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 154 Requirement Levels", BCP 14, RFC 2119, March 1997. 156 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 157 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 158 October 1998. 160 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 161 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 163 [TS29.272] 164 3rd Generation Partnership Project, "3GPP TS 29.272 165 V8.0.0; Technical Specification Group Core Network and 166 Terminals; Evolved Packet System; MME and SGSN Related 167 Interfaces Based on Diameter Protocol (Release 8)", 168 http://www.3gpp.org/ftp/Specs/html-info/29272.htm, 169 09 2008. 171 Authors' Addresses 173 Mark Jones 174 Bridgewater Systems 176 Email: mark.jones@bridgewatersystems.com 178 Lionel Morand 179 Orange Labs 181 Email: lionel.morand@orange-ftgroup.com 183 Full Copyright Statement 185 Copyright (C) The IETF Trust (2008). 187 This document is subject to the rights, licenses and restrictions 188 contained in BCP 78, and except as set forth therein, the authors 189 retain all their rights. 191 This document and the information contained herein are provided on an 192 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 193 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 194 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 195 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 196 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 197 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 199 Intellectual Property 201 The IETF takes no position regarding the validity or scope of any 202 Intellectual Property Rights or other rights that might be claimed to 203 pertain to the implementation or use of the technology described in 204 this document or the extent to which any license under such rights 205 might or might not be available; nor does it represent that it has 206 made any independent effort to identify any such rights. Information 207 on the procedures with respect to rights in RFC documents can be 208 found in BCP 78 and BCP 79. 210 Copies of IPR disclosures made to the IETF Secretariat and any 211 assurances of licenses to be made available, or the result of an 212 attempt made to obtain a general license or permission for the use of 213 such proprietary rights by implementers or users of this 214 specification can be obtained from the IETF on-line IPR repository at 215 http://www.ietf.org/ipr. 217 The IETF invites any interested party to bring to its attention any 218 copyrights, patents or patent applications, or other proprietary 219 rights that may cover technology that may be required to implement 220 this standard. Please address the information to the IETF at 221 ietf-ipr@ietf.org.