idnits 2.17.1 draft-brenner-dime-peem-01.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 218. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 242. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (January 2, 2008) is 5952 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and M. Brenner 3 Extensions (DIME) Alcatel-Lucent 4 Internet-Draft January 2, 2008 5 Intended status: Informational 6 Expires: July 5, 2008 8 Diameter Policy Processing Application 9 draft-brenner-dime-peem-01 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 July 5, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes the need for a new IANA Diameter Command Code 43 to be used in a vendor-specific new application for invocation of 44 Policy Processing (Policy Evaluation, or Evaluation and Enforcement). 45 This application is needed as one of the implementations of the Open 46 Mobile Aliance (OMA) Policy Evaluation, Enforcement and Management 47 (PEEM) enabler, namely for the PEM-1 interface used to send a 48 request/responses for Policy Processing. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Diameter Policy Processing Application . . . . . . . . . . . . 3 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . . 4 62 5.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5.3. Application Identifier . . . . . . . . . . . . . . . . . . 4 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 4 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 Intellectual Property and Copyright Statements . . . . . . . . . . 6 74 1. Introduction 76 This document summarizes the use of Diameter codes in a newly defined 77 realization of a specification for invocation of policy processing 78 (PEM-1). A new Command Code is requested to be assigned by IANA. 79 The document summarizes the uses of newly defined Diameter codes 80 (Command Codes, AVP, vendor-specific application id). When combined 81 with the Diameter Base protocol, this application's specification 82 satisfies the Open Mobile Alliance (OMA) Policy Evaluation, 83 Enforcement and Management (PEEM) requirements for sending a request 84 for policy processing and receiving a response with the policy 85 processing result. See [PEM-1-TS] for the normative use of Diameter. 86 PEEM requirements are documented in [PEEM-RD] and PEEM Architecture 87 is documented in [PEEM-AD]. 89 The Diameter realization of this application assumes the use of 90 Diameter Base protocol, as per RFC 3588, and extends it only for a 91 specific application using a vendor-id (PEN), a vendor-specific 92 application ID, a new Command Code (TBD), and new AVP defined in the 93 vendor-specific namespace. Input to policy processing are being 94 passed through a new AVP, and policy results are being passed through 95 a combination of the same new AVP, and the Experimental-Result AVP. 97 2. Terminology 99 The base Diameter specification [RFC3588] Section 1.4 defines most of 100 the terminology used in this document. Additionally, the terms and 101 acronyms defined in [PEM-1-TS] are used in this document. 103 3. Diameter Policy Processing Application 105 A detailed description of the Diameter Policy Processing Application 106 can be found in Section 5.4.1 of the Policy Evaluation, Enforcement 107 and Management Callable Interface (PEM-1) Technical Specification 108 [PEM-1-TS]. 110 4. Security Considerations 112 This document describes the Diameter Policy Processing Application. 113 It builds on top of the Diameter Base protocol and the same security 114 considerations described in RFC 3588 [RFC3588] are applicable to this 115 document. No further extensions are required beyond the security 116 mechanisms offered by RFC 3588. 118 5. IANA Considerations 120 This section provides guidance to the Internet Assigned Numbers 121 Authority (IANA) regarding registration of values related to the 122 Diameter protocol, in accordance with BCP 26 [RFC2434]. 124 This document defines values in the namespaces that have been created 125 and defined in the Diameter Base [RFC3588]. The IANA Considerations 126 section of that document details the assignment criteria. Values 127 assigned in this document, or by future IANA action, must be 128 coordinated within this shared namespace. 130 5.1. Command Codes 132 This specification assigns the value TBD-Cmd-code from the Command 133 Code namespace defined in [RFC3588]. See Section 5.4.1.3.1 of 134 [PEM-1-TS] for the assignment of the TBD-Cmd-code. 136 5.2. AVP Codes 138 This specification assigns the value TBD-AVP-Code for the Policy-Data 139 AVP, in the OMA Vendor-ID (PEN) AVP namespace. See Section 5.4.1.3.3 140 of [PEM-1-TS] for the assignment of the namespace in this 141 specification. 143 5.3. Application Identifier 145 This specification uses the value 16777243 in the Application 146 Identifier namespace as registered in IANA for the Policy Processing 147 Application. See Section 5.4.1.3 of [PEM-1-TS] for more information. 149 6. Acknowledgements 151 The author would like to thank Dan Romascanu and Hannes Tschofenig 152 for their help and support. 154 Finally, the author would like to thank Alcatel-Lucent, as most of 155 the effort put into this document was done while he was in their 156 employ. 158 7. References 160 7.1. Normative References 162 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 163 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 165 [PEM-1-TS] 166 Open Mobile Alliance, "Policy Evaluation, Enforcement and 167 Management Callable Interface (PEM-1) Technical 168 Specification, Draft Version 1.0, available at http:// 169 www.openmobilealliance.org/ftp/Public_documents/ARCH/ 170 Permanent_documents/OMA-TS-PEEM_PEM1-V1_0-20071218-D.zip", 171 December 2007. 173 7.2. Informative References 175 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 176 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 177 October 1998. 179 [PEEM-RD] Open Mobile Alliance, "Policy Evaluation, Enforcement and 180 Management Requirements, Candidate Version 1.0, 12 January 181 2005, available at http://www.openmobilealliance.org/ftp/ 182 Public_documents/ARCH/permanent_documents/ 183 OMA-RD-Policy_Evaluation_Enforcement_Management-V1_0- 184 20050112-C.zip", November 2005. 186 [PEEM-AD] Open Mobile Alliance, "Policy Evaluation, Enforcement and 187 Management Architecture, Draft Version 1.0, available at h 188 ttp://www.openmobilealliance.org/ftp/Public_documents/ 189 ARCH/Permanent_documents/ 190 OMA-AD-Policy_Evaluation_Enforcement_Management-V1_0_0- 191 20060625-D.zip", June 2006. 193 Author's Address 195 Michael Brenner 196 Alcatel-Lucent 197 600-700 Mountain Avenue, 2D-148 198 Murray Hill, NJ 07974-0636 199 USA 201 Phone: +1 908-582-8753 202 Email: mrbrenner@alcatel-lucent.com 204 Full Copyright Statement 206 Copyright (C) The IETF Trust (2008). 208 This document is subject to the rights, licenses and restrictions 209 contained in BCP 78, and except as set forth therein, the authors 210 retain all their rights. 212 This document and the information contained herein are provided on an 213 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 214 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 215 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 216 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 217 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 218 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 220 Intellectual Property 222 The IETF takes no position regarding the validity or scope of any 223 Intellectual Property Rights or other rights that might be claimed to 224 pertain to the implementation or use of the technology described in 225 this document or the extent to which any license under such rights 226 might or might not be available; nor does it represent that it has 227 made any independent effort to identify any such rights. Information 228 on the procedures with respect to rights in RFC documents can be 229 found in BCP 78 and BCP 79. 231 Copies of IPR disclosures made to the IETF Secretariat and any 232 assurances of licenses to be made available, or the result of an 233 attempt made to obtain a general license or permission for the use of 234 such proprietary rights by implementers or users of this 235 specification can be obtained from the IETF on-line IPR repository at 236 http://www.ietf.org/ipr. 238 The IETF invites any interested party to bring to its attention any 239 copyrights, patents or patent applications, or other proprietary 240 rights that may cover technology that may be required to implement 241 this standard. Please address the information to the IETF at 242 ietf-ipr@ietf.org. 244 Acknowledgment 246 Funding for the RFC Editor function is provided by the IETF 247 Administrative Support Activity (IASA).