idnits 2.17.1 draft-arkko-acctrqlis-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 66: '...more of the MUST or MUST NOT requireme...' RFC 2119 keyword, line 67: '...sion that satisfies all the MUST, MUST...' RFC 2119 keyword, line 68: '...NOT, SHOULD and SHOULD NOT requirement...' RFC 2119 keyword, line 69: '...e that satisfies all the MUST and MUST...' RFC 2119 keyword, line 70: '... but not all the SHOULD or SHOULD NOT ...' (46 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 401 has weird spacing: '...imed to perta...' == Line 443 has weird spacing: '...>, and expir...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 339 looks like a reference -- Missing reference section? '6' on line 359 looks like a reference -- Missing reference section? '2' on line 343 looks like a reference -- Missing reference section? '5' on line 355 looks like a reference -- Missing reference section? '3' on line 347 looks like a reference -- Missing reference section? '4' on line 351 looks like a reference -- Missing reference section? '7' on line 362 looks like a reference -- Missing reference section? '8' on line 365 looks like a reference -- Missing reference section? '9' on line 369 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AAA Working Group Jari Arkko 2 INTERNET-DRAFT Ericsson 3 Category: Informational 4 6 Accounting Requirements 8 1. Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. Internet- 16 Drafts are draft documents valid for a maximum of six months and may be 17 updated, replaced, or obsoleted by other documents at any time. It is 18 inappropriate to use Internet-Drafts as reference material or to cite 19 them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 The distribution of this memo is unlimited. It is filed as , and expires April 22, 2000. Please send com- 29 ments to the author. 31 2. Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 3. Abstract 37 This document is a common list of accounting requirements collected from 38 a number of documents from the NASREQ, ROAMOPS, MOBILEIP, and AAA work- 39 ing groups. The intention is to present a detailed-level list of the 40 summarized requirements in [1] as well as including some important 41 requirements from [2,3, and 4]. 43 4. Introduction 45 This document is a common list of accounting requirements collected from 46 a number of documents from the NASREQ, ROAMOPS, MOBILEIP, and AAA work- 47 ing groups. The intention is to present a detailed-level list of the 48 summarized requirements in [1] as well as including some important 49 requirements from [2,3, and 4]. 51 4.1. Requirements language 53 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 54 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 55 described in [6]. 57 Please note that the requirements specified in this document are to be 58 used in evaluating AAA protocol submissions. As such, the requirements 59 language refers to capabilities of these protocols; the protocol docu- 60 ments will specify whether these features are required, recommended, or 61 optional. For example, requiring that a protocol support confidential- 62 ity is NOT the same thing as requiring that all protocol traffic be 63 encrypted. 65 A protocol submission is not compliant if it fails to satisfy one or 66 more of the MUST or MUST NOT requirements for the capabilities that it 67 implements. A protocol submission that satisfies all the MUST, MUST 68 NOT, SHOULD and SHOULD NOT requirements for its capabilities is said to 69 be "unconditionally compliant"; one that satisfies all the MUST and MUST 70 NOT requirements but not all the SHOULD or SHOULD NOT requirements for 71 its protocols is said to be "conditionally compliant." 73 5. Requirements 75 Requirements are listed in five categories: 76 - General 77 - Accounted Events 78 - Data Formats 79 - Data Contents 80 - Security 82 5.1. General Requirements 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | | | | 86 | REQUIREMENT | LEVEL | REFERENCE | 87 | | | | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | | | | 90 | Real-time accounting | MUST | [8, 3.1] | 91 | | | [4, 5.5] | 92 | | | [5, 8.4.1.2] | 93 | | | | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | | | | 96 | Batch accounting | MUST | [5, 8.4.1.3] | 97 | | | [4, 5.2] | 98 | | | [1, 4.3] | 99 | | | | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | | | | 102 | On-demand re-sync | MUST | [5, 8.4.1.6] | 103 | | | | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | | | | 106 | Accounting data available | SHOULD | [9, 3.3] | 107 | before service given | | | 108 | | | | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | | | | 111 | Negotiation of transfer | SHOULD | [2, 5] | 112 | method and format, | | | 113 | capabilities | | | 114 | | | | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | | | | 117 | On-line usage summaries | SHOULD | [9, 3.3] | 118 | to involved parties | | | 119 | | | | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | | | | 122 | Reliable delivery even | MUST | [4, 6.1] | 123 | with small packet loss | | | 124 | | | | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | | | | 127 | Reliable delivery even | MUST | [4, 6.1] | 128 | with small packet loss | | | 129 | | | | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | | | | 132 | Reliable delivery even | MUST | [4, 6.1] | 133 | with large packet loss | | | 134 | | | | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | | | | 137 | Reliable delivery even | MUST | [4, 6.1] | 138 | with server failures | | | 139 | | | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | | | 142 | Reliable delivery even | MUST | [4, 6.1] | 143 | with device failures | | | 144 | | | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | | | | 147 | Reliable delivery even | MUST | [4, 6.1] | 148 | with network problems | | | 149 | | | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 5.2. Accounted Event Requirements 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | | | | 156 | REQUIREMENT | LEVEL | REFERENCE | 157 | | | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | | | | 160 | Start of a session | MUST | [5, 8.4.1.5] | 161 | | | | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | | | 164 | End of a session | MUST | [5, 8.4.1.5] | 165 | | | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | | | 168 | Expiration of repeating | MUST | [5, 8.4.1.5] | 169 | time interval | | | 170 | | | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | | | 173 | Dynamic re-authorization | MUST | [5, 8.4.1.5] | 174 | | | [9, 3.3] | 175 | | | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | | | 178 | Dynamic re-authentication | MUST | [5, 8.4.1.5] | 179 | | | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 5.3. Data Format Requirements 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | | | | 186 | REQUIREMENT | LEVEL | REFERENCE | 187 | | | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | | | 190 | Simple standard format | MUST | [1, 4.3] | 191 | | | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | | | 194 | Compact record format | MUST | [7, 4.3] | 195 | | | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | | | 198 | Allow large records | MUST | - | 199 | | | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | | | 202 | Accounting record | MUST | [5, 8.1.3.3] | 203 | Extensibility | | | 204 | | | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | | | 207 | Standard data types | MUST | [2, 4.2.1] | 208 | | | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | | | | 211 | Tagged and typed data | MUST | [2, 4.2] | 212 | | | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | | | 215 | Versioned services | SHOULD | [2, 4.4.2] | 216 | | | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | | | 219 | Service namespace | MUST | [2, 4.4.4] | 220 | management | | | 221 | | | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | | | 224 | Multiple record encoding | MAY | [2, 5] | 225 | formats | | | 226 | | | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 5.4. Data Contents Requirements 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | | | 233 | REQUIREMENT | LEVEL | REFERENCE | 234 | | | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | | | 237 | Time stamps | MUST | [5, 8.4.1.4] | 238 | | | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | | | 241 | All authentication | MUST | [5, 8.4.2] | 242 | parameters | | | 243 | | | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | | | 246 | All authorization profile | MUST | [5, 8.4.2] | 247 | parameters | | | 248 | | | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | | | 251 | Duration | MUST | [5, 8.4.2] | 252 | | | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | | | 255 | Termination cause | MUST | [5, 8.4.2] | 256 | | | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | | | 259 | Diagnostics | MUST | [5, 8.4.2] | 260 | | | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | | | 263 | Transaction identifier | MUST | [2, 4.3] | 264 | | | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | | | 267 | Identification of the | MUST | [2, 4.4.4] | 268 | service | | | 269 | | | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | | | 272 | Compound services | MUST | [2, 4.4.3] | 273 | | | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | | | 276 | Parameters specific to | MUST | [2, 4.4.1] | 277 | the particular service | | | 278 | | | | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 5.5. Security Requirements 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | | | 285 | REQUIREMENT | LEVEL | REFERENCE | 286 | | | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | | | 289 | Integrity protection | MUST | [8, 3.1] | 290 | | | [4, 5.5] | 291 | | | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | | | | 294 | Confidentiality protection| MUST | [4, 5.5] | 295 | | | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | | | 298 | Replay protection | MUST | [4, 5.5] | 299 | | | [8, 3.1] | 300 | | | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | | | 303 | Authentication | MUST | [8, 3.1] | 304 | | | [4, 5.5] | 305 | | | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | | | 308 | End-to-end integrity | MUST | [5, 8.4.3.1] | 309 | protection | | [1, 4.3] | 310 | | | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | | | | 313 | End-to-end confidentiality| SHOULD | [5, 8.4.3.1] | 314 | protection | | [1, 4.3] | 315 | | | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | | | 318 | Non-repudiation | SHOULD | [5, 8.4.3.2] | 319 | | | [8, 3.1] | 320 | | | [1, 4.3] | 321 | | | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | | | 324 | Archival accounting | MUST | [4, 5.1] | 325 | | | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | | | 328 | Matching accounting record| MUST | [8, 3.1] | 329 | with authorization event | | | 330 | | | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | | | 333 | Data-based access control | MUST | [4, 7.1.3.3] | 334 | | | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 6. References 339 [1] Beadles, M. et al., "Network Access AAA Evaluation Criteria", 340 Internet draft (work in progress), draft-ietf-aaa-na-reqts-00.txt, 341 October 1999. 343 [2] Blount, A., "Accounting Protocol and Record Format Features", 344 Internet draft (work in progress), draft-blount-acct-service- 345 00.txt, September, 1999. 347 [3] Brownlee, N., "Accounting Attributes and Record Formats", Internet 348 draft (work in progress), draft-brownlee-accounting-attributes- 349 00.txt, May, 1999. 351 [4] Aboba, B. and Arkko, J., "Introduction to Accounting Management", 352 Internet draft (work in progress), draft-aboba-acct-02.txt, October 353 1999. 355 [5] Beadles, M., "Criteria for Evaluating Network Access Server Proto- 356 cols", Internet draft (work in progress), draft-ietf-nasreq- 357 criteria-03.txt, October 1999. 359 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 360 Levels", BCP 14, RFC 2119, March 1997. 362 [7] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming Proto- 363 cols", RFC 2477, January 1999. 365 [8] Hiller, T., et al., "Cdma2000 Wireless Data Requirements for AAA", 366 Internet draft (work in progress), draft-hiller-cdma2000-AAA- 367 00.txt, October 1999. 369 [9] Glass, S., Jacobs, S., Perkins, C., "Mobile IP Authentication, 370 Authorization, and Accounting Requirements", Internet draft (work 371 in progress), draft-ietf-mobileip-aaa-reqs-01.txt, October 1999. 373 7. Security Considerations 375 This document, being a requirements document, does not have any security 376 concerns. It does set some security requirements, however. 378 8. IANA Considerations 380 This draft does not create any new number spaces for IANA administra- 381 tion. 383 9. Acknowledgements 385 Credit from discovering the requirements is due to the referenced docu- 386 ments and their authors, as well as the whole IETF AAA working group. 388 10. Author's Address 390 Jari Arkko 391 Oy LM Ericsson Ab 392 02420 Jorvas 393 Finland 395 Phone: +358 40 5079256 396 EMail: jari.arkko@ericsson.com 398 11. Intellectual Property Statement 400 The IETF takes no position regarding the validity or scope of any intel- 401 lectual property or other rights that might be claimed to pertain to 402 the implementation or use of the technology described in this document 403 or the extent to which any license under such rights might or might not 404 be available; neither does it represent that it has made any effort to 405 identify any such rights. Information on the IETF's procedures with 406 respect to rights in standards-track and standards-related documentation 407 can be found in BCP-11. Copies of claims of rights made available for 408 publication and any assurances of licenses to be made available, or the 409 result of an attempt made to obtain a general license or permission for 410 the use of such proprietary rights by implementors or users of this 411 specification can be obtained from the IETF Secretariat. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary rights 415 which may cover technology that may be required to practice this stan- 416 dard. Please address the information to the IETF Executive Director. 418 12. Full Copyright Statement 420 Copyright (C) The Internet Society (1999). All Rights Reserved. 421 This document and translations of it may be copied and furnished to oth- 422 ers, and derivative works that comment on or otherwise explain it or 423 assist in its implmentation may be prepared, copied, published and dis- 424 tributed, in whole or in part, without restriction of any kind, provided 425 that the above copyright notice and this paragraph are included on all 426 such copies and derivative works. However, this document itself may not 427 be modified in any way, such as by removing the copyright notice or 428 references to the Internet Society or other Internet organizations, 429 except as needed for the purpose of developing Internet standards in 430 which case the procedures for copyrights defined in the Internet Stan- 431 dards process must be followed, or as required to translate it into 432 languages other than = English. The limited permissions granted above 433 are perpetual and will not be revoked by the Internet Society or its 434 successors or assigns. This document and the information contained 435 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 436 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 437 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 438 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRAN- 439 TIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 441 13. Expiration Date 443 This memo is filed as , and expires 444 April 22, 2000.