idnits 2.17.1 draft-ietf-mip4-message-string-ext-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 289. 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 15, 2007) is 6308 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 V. Sastry 3 Internet-Draft Samsung Electronics 4 Intended status: Standards Track K. Leung 5 Expires: July 19, 2007 A. Patel 6 Cisco Systems 7 January 15, 2007 9 Mobile IPv4 Message String Extension 10 draft-ietf-mip4-message-string-ext-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 19, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies a new extension for use in Mobile IPv4. This 44 extension can be added by the Home Agent and the Foreign Agent to 45 Registration Reply messages. This extension carries a text string 46 that is intended for the user of the Mobile Node. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Mobile IPv4 Message String Extension Format . . . . . . . . . 5 53 4. Operation and Use of the Message String Extension . . . . . . 7 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 57 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 59 Intellectual Property and Copyright Statements . . . . . . . . . . 13 61 1. Introduction 63 This document specifies a new skippable extension that can be added 64 by the Foreign Agent and Home Agent in any registration message 65 targeted for the Mobile Node. Such a message may be either a 66 Registration Reply or Registration Revocation (i.e. co-located 67 Care-of Address mode). For the Registration Reply message, this 68 extension can be added regardless of whether the registration has 69 succeeded or failed. 71 The content of the text string in this extension and its usage by the 72 Mobile Node is implementation specific. The text string in this 73 extension is intended for the user of the Mobile Node. For example, 74 this message can be displayed on the Mobile Node's user interface, 75 logged, or handled in any other implementation dependent way, 76 depending on the form of the Mobile Node. 78 Typical contents of the text string will indicate a registration 79 failure reason, or give a welcome message on successful registration. 80 This is important as the failure reason code gives very limited 81 information for interpretation by the user of the Mobile Node. For 82 example, a string like "registration failed : Prepaid Quota for the 83 user is exhausted" can give a human readable description of the 84 result of Mobile IP registration. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 3. Mobile IPv4 Message String Extension Format 94 The Message String Extension conforms to the Short Extension format 95 specified for Mobile IPv4 [RFC3344]. The Message String Extension is 96 a skippable extension. 98 0 1 2 3 99 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Type | Length | Sub-Type | Text .... 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 Type: 106 To be assigned by IANA. An 8-bit identifier of the type mobility 107 option. 109 Length: 111 8-bit unsigned integer. Length of the extension, in bytes, 112 excluding the extension Type and the extension Length fields. 113 This field MUST be set to 1 plus the total length of the Text 114 field. 116 Sub-Type: 118 1: 120 Extension comes from the Home Agent 122 2: 124 Extension comes from the Foreign Agent 126 Text: 128 The Text field is one or more octets, and its contents are 129 implementation dependent. It is intended to be human readable, 130 and MUST NOT affect operation of the protocol. It is RECOMMENDED 131 that the message contain UTF-8 encoded 10646 [RFC3629] characters. 132 The number of octets in the encoded representation of the message 133 is always exactly the value of the Length field minus one. (In 134 the UTF-8 case, the number of unicode characters represented by 135 this octet sequence may be smaller than the number of octets.) 136 Other encoding methods than UTF-8 may only be used in closed 137 environments where it can be guaranteed that both message sender 138 and receiver know the exact encoding method, and know that the 139 encoding method is different from UTF-8. 141 4. Operation and Use of the Message String Extension 143 The Message String Extension is only valid for use within Mobile IPv4 144 Registration Reply and Registration Revocation messages. The Message 145 String Extension is a skippable extension. Either the Home Agent or 146 Foreign Agent or both can add the Message String Extension to 147 registration messages. The usage of Text field of the Message String 148 Extension is implementation dependent. For example, the message can 149 be displayed on the Mobile Node's user interface, logged, or handled 150 in an implementation dependent way, depending on the form of the 151 Mobile Node. 153 The Mobile Node may throttle how often the user is notified of the 154 message (either via display on user interface, logging, etc.) For 155 example, the Home Agent may reject the first Registration Request due 156 to prepaid quota for the user is reached and may attach a Message 157 String Extension with the text "Prepaid quota reached. Please 158 contact www.paymore.example.com to update balance". The Mobile Node 159 could display this on the user interface. As a response, the user of 160 the Mobile Node may take the required action to update the prepaid 161 account and retry the registration process. The Home Agent may 162 accept this Registration Request and attach a Message String 163 Extension with the text "Welcome to www.serviceprovider.example.com". 164 The Mobile Node could display this on the user interface thus 165 confirming successful creation of binding on Home Agent. 167 5. Security Considerations 169 The Message String Extension can be added by the Home Agent or 170 Foreign Agent or both. 172 If the extension is added by the Home Agent (extension with subtype 173 1) to a Registration Reply or Registration Revocation message, it 174 MUST appear before Mobile-Home Authentication Extension [RFC3344]. 176 If the extension is added by the Foreign Agent (extension with 177 subtype 2) to a Registration Reply message, it MUST appear after 178 Mobile-Home Authentication Extension [RFC3344] whenever present. 179 Also the extension MUST appear before the Mobile-Foreign 180 Authentication Extension whenever present. 182 6. IANA Considerations 184 This specification reserves one number for the Message String 185 Extension in Section 3 from the space of numbers for skippable 186 mobility extensions (i.e., 128-255) defined for Mobile IPv4 [RFC3344] 187 at http://www.iana.org/assignments/mobileip-numbers. 189 The value 145 is suggested for this extension. 191 This specification also creates a new subtype space for the type 192 number of this extension. The subtype values 1 and 2 are defined in 193 this specification. The subtype value 1 is reserved for use by Home 194 Agent and subtype value 2 is reserved for use by Foreign Agent. 195 Similar to the procedures specified for Mobile IPv4 [RFC3344] number 196 spaces, future allocations from this number space require expert 197 review [RFC2434]. 199 7. Acknowledgements 201 The authors would like to thank Avi Lior, Curtis Provost and Henrik 202 Levkowetz for their useful comments on an eariler version of this 203 document. 205 8. Normative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 211 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 212 October 1998. 214 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 215 August 2002. 217 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 218 10646", STD 63, RFC 3629, November 2003. 220 Authors' Addresses 222 Venkateshwara Sastry 223 Samsung Electronics 224 Bagmane Lake View, 'Block -B' 225 66/1, Bagmane Tech Park, Byrasandra, 226 C. V. Raman Nagar 227 Bangalpre 560093 228 India 230 Phone: +91-80-41819999 231 Email: venkat.s@samsung.com 233 Kent Leung 234 Cisco Systems 235 170 W. Tasman Drive 236 San Jose, CA 95134 237 US 239 Phone: +1 408-526-5030 240 Email: kleung@cisco.com 242 Alpesh Patel 243 Cisco Systems 244 170 W. Tasman Drive 245 San Jose, CA 95134 246 US 248 Phone: +1 408-853-9580 249 Email: alpesh@cisco.com 251 Full Copyright Statement 253 Copyright (C) The IETF Trust (2007). 255 This document is subject to the rights, licenses and restrictions 256 contained in BCP 78, and except as set forth therein, the authors 257 retain all their rights. 259 This document and the information contained herein are provided on an 260 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 261 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 262 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 263 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 264 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 265 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 267 Intellectual Property 269 The IETF takes no position regarding the validity or scope of any 270 Intellectual Property Rights or other rights that might be claimed to 271 pertain to the implementation or use of the technology described in 272 this document or the extent to which any license under such rights 273 might or might not be available; nor does it represent that it has 274 made any independent effort to identify any such rights. Information 275 on the procedures with respect to rights in RFC documents can be 276 found in BCP 78 and BCP 79. 278 Copies of IPR disclosures made to the IETF Secretariat and any 279 assurances of licenses to be made available, or the result of an 280 attempt made to obtain a general license or permission for the use of 281 such proprietary rights by implementers or users of this 282 specification can be obtained from the IETF on-line IPR repository at 283 http://www.ietf.org/ipr. 285 The IETF invites any interested party to bring to its attention any 286 copyrights, patents or patent applications, or other proprietary 287 rights that may cover technology that may be required to implement 288 this standard. Please address the information to the IETF at 289 ietf-ipr@ietf.org. 291 Acknowledgment 293 Funding for the RFC Editor function is provided by the IETF 294 Administrative Support Activity (IASA).