idnits 2.17.1 draft-ietf-mip4-message-string-ext-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 on line 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 285. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 127: '... and MUST NOT affect operation of...' RFC 2119 keyword, line 144: '...n Agent or both, MAY add the extension...' RFC 2119 keyword, line 166: '...gistration Revocation message, it MUST...' RFC 2119 keyword, line 172: '...on Reply message, it MUST appear after...' RFC 2119 keyword, line 174: '...so the extension MUST appear before th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (September 14, 2006) is 6434 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) == Unused Reference: 'FA-ERR' is defined on line 201, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'RFC3543' is defined on line 212, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Sastry 3 Internet-Draft K. Leung 4 Intended status: Standards Track A. Patel 5 Expires: March 18, 2007 Cisco Systems 6 September 14, 2006 8 Mobile IPv4 Message String Extension 9 draft-ietf-mip4-message-string-ext-01.txt 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 March 18, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies a new extension for use in Mobile IPv4. This 43 extension can be added by the Home Agent and the Foreign Agent to 44 Registration Reply message. This extension carries a text string 45 that is intended for the user of the Mobile Node. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Mobile IPv4 Message String Extension Format . . . . . . . . . 5 52 4. Operation and Use of the Message String Extension . . . . . . 7 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 55 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 56 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 58 Intellectual Property and Copyright Statements . . . . . . . . . . 13 60 1. Introduction 62 This document specifies a new skippable extension that can be added 63 by Foreign Agent and Home Agent in registration message targeted for 64 the Mobile Node. Such a message may be either a Registration Reply 65 or Registration Revocation (i.e. collocated Care-of Address mode). 66 For the Registration Reply message, this extension can be added 67 regardless of whether the registration has succeeded or failed. 69 Content of the text string in this extension and its usage by Mobile 70 Node is implementation specific. The text string in this extension 71 is intended for the user of the Mobile Node. For example, this 72 message can be displayed on the Mobile Node's user interface, logged 73 or handled in any other implementation dependent way, depending on 74 the form of the Mobile Node. 76 Typical contents of the text string will indicate registration 77 failure reason, or a welcome message on successful registration. 78 This is important as the failure reason code gives very limited 79 information for interpretation by the user of the Mobile Node. A 80 string like "registration failed : Prepaid Quota for the user is 81 exhausted", "registration success : Unauthorized Access is 82 Prohibited", can give a human readable description of the result of 83 Mobile IP registration. 85 2. Terminology 87 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119. 91 3. Mobile IPv4 Message String Extension Format 93 The Message String Extension conforms to the Short Extension format 94 specified for Mobile IPv4 [RFC3344]. The Message String Extension is 95 a skippable extension. 97 0 1 2 3 98 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 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Type | Length | Sub-Type | Text .... 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 Type: 105 To be assigned by IANA. An 8-bit identifier of the type mobility 106 option. 108 Length: 110 8-bit unsigned integer, equaling 1 plus the length in octets of 111 the Text 113 Sub-Type: 115 1: 117 Extension is added by Home Agent 119 2: 121 Extension is added by Foreign Agent 123 Text: 125 The Text field is one or more octets, and its contents are 126 implementation dependent. It is intended to be human readable, 127 and MUST NOT affect operation of the protocol. It is recommended 128 that the message contain UTF-8 encoded 10646 [RFC3629] characters. 129 The number of octets in the UTF-8 representation of the message is 130 exactly the value of the Length field minus one. 132 4. Operation and Use of the Message String Extension 134 The Message String Extension is only valid for use within Mobile IPv4 135 Registration Reply and Registration Revocation messages. The Message 136 String Extension is a skippable extension. Either Home Agent or 137 Foreign Agent or both can add Message String Extension to 138 registration messages. Usage of Text field of the Message String 139 Extension is implementation dependent. For example, this message can 140 be displayed on the Mobile Node's user interface, logged or handled 141 in an implementation dependent way, depending on the form of the 142 Mobile Node. 144 Home Agent or Foreign Agent or both, MAY add the extension to each 145 registration message to a Mobile Node. However, Mobile Node may 146 throttle how often the user is notified of the message (either via 147 display on user interface, logging, etc.) For example, Home Agent 148 may reject the first Registration Request due to prepaid quota for 149 the user is reached and may attach a Message String Extension with 150 the text "Prepaid quota reached. Please contact www.paymore.com to 151 update balance". Mobile Node could display this on the user 152 interface. As a response user of the Mobile Node may take the 153 required action to update the prepaid account and retry the 154 registration process. Home Agent may accept this Registration 155 Request and attach a Message String Extension with the text "Welcome 156 to www.serviceprovider.com". Mobile Node could display this on the 157 user interface thus confirming successful creation of binding on Home 158 Agent. 160 5. Security Considerations 162 Message String Extension can be added by Home Agent or Foreign Agent 163 or both. 165 If the extension is added by the Home Agent (extension with subtype 166 1) to Registration Reply or Registration Revocation message, it MUST 167 appear before Mobile-Home Authentication Extension [RFC3344]. If the 168 the Mobile Node cannot understand this extension, it should be 169 skipped. 171 If the extension is added by the Foreign Agent (extension with 172 subtype 2) to Registration Reply message, it MUST appear after 173 Mobile-Home Authentication Extension [RFC3344] whenever present. 174 Also the extension MUST appear before the Mobile-Foreign 175 Authentication Extension whenever present. If Mobile Node cannot 176 understand this extension, it should be skipped. 178 6. IANA Considerations 180 This specification reserves one number for the Message String 181 Extension Section 3 from the space of numbers for skippable mobility 182 extensions (i.e., 128-255) defined for Mobile IPv4 [RFC3344] at 183 http://www.iana.org/assignments/mobileip-numbers. 185 The value 145 is recommended for this extension. 187 This specification also creates a new subtype space for the type 188 number of this extension. The subtype values 1 and 2 are defined in 189 this specification. The subtype value 1 is reserved for use by Home 190 Agent and subtype value 2 is reserved for use by Foreign Agent. 191 Other values can be allocated from this number space by IANA actions. 193 7. Acknowledgements 195 The authors would like to thank Avi Lior, Curtis Provost and Henrik 196 Levkowetz for their useful comments on an eariler version of this 197 document. 199 8. Normative References 201 [FA-ERR] Perkins, C., "Foreign Agent Error Extension for Mobile 202 IPv4", draft-ietf-mip4-faerr-02.txt (work in progress), 203 September 2005. 205 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 206 "Remote Authentication Dial In User Service (RADIUS)", 207 RFC 2865, June 2000. 209 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 210 August 2002. 212 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 213 Mobile IPv4", RFC 3543, August 2003. 215 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 216 10646", STD 63, RFC 3629, November 2003. 218 Authors' Addresses 220 Venkateshwara Sastry 221 Cisco Systems 222 Akkithimanahalli, O'Shaugnessy Road 223 Bangalore 560085 224 India 226 Phone: +91 80-51033757 227 Email: vsastry@cisco.com 229 Kent Leung 230 Cisco Systems 231 170 W. Tasman Drive 232 San Jose, CA 95134 233 US 235 Phone: +1 408-526-5030 236 Email: kleung@cisco.com 238 Alpesh Patel 239 Cisco Systems 240 170 W. Tasman Drive 241 San Jose, CA 95134 242 US 244 Phone: +1 408-853-9580 245 Email: alpesh@cisco.com 247 Full Copyright Statement 249 Copyright (C) The Internet Society (2006). 251 This document is subject to the rights, licenses and restrictions 252 contained in BCP 78, and except as set forth therein, the authors 253 retain all their rights. 255 This document and the information contained herein are provided on an 256 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 257 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 258 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 259 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 260 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 261 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 263 Intellectual Property 265 The IETF takes no position regarding the validity or scope of any 266 Intellectual Property Rights or other rights that might be claimed to 267 pertain to the implementation or use of the technology described in 268 this document or the extent to which any license under such rights 269 might or might not be available; nor does it represent that it has 270 made any independent effort to identify any such rights. Information 271 on the procedures with respect to rights in RFC documents can be 272 found in BCP 78 and BCP 79. 274 Copies of IPR disclosures made to the IETF Secretariat and any 275 assurances of licenses to be made available, or the result of an 276 attempt made to obtain a general license or permission for the use of 277 such proprietary rights by implementers or users of this 278 specification can be obtained from the IETF on-line IPR repository at 279 http://www.ietf.org/ipr. 281 The IETF invites any interested party to bring to its attention any 282 copyrights, patents or patent applications, or other proprietary 283 rights that may cover technology that may be required to implement 284 this standard. Please address the information to the IETF at 285 ietf-ipr@ietf.org. 287 Acknowledgment 289 Funding for the RFC Editor function is provided by the IETF 290 Administrative Support Activity (IASA).