idnits 2.17.00 (12 Aug 2021) /tmp/idnits51380/draft-aboba-roamops-adif-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 13 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 74 has weird spacing: '...tion be measu...' == Line 533 has weird spacing: '...hanisms for S...' == Line 763 has weird spacing: '...>, and expir...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (19 January 2001) is 7785 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 490, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 501, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 514, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 537, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 540, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 543, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 546, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 549, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 556, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 561, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 566, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 569, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 572, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 575, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 582, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 588, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 594, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 599, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 603, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 606, but no explicit reference was found in the text == Unused Reference: '38' is defined on line 609, but no explicit reference was found in the text == Unused Reference: '39' is defined on line 615, but no explicit reference was found in the text == Unused Reference: '40' is defined on line 621, but no explicit reference was found in the text == Unused Reference: '41' is defined on line 627, but no explicit reference was found in the text == Unused Reference: '42' is defined on line 632, but no explicit reference was found in the text == Unused Reference: '43' is defined on line 637, but no explicit reference was found in the text == Unused Reference: '44' is defined on line 643, but no explicit reference was found in the text == Unused Reference: '45' is defined on line 648, but no explicit reference was found in the text == Unused Reference: '46' is defined on line 652, but no explicit reference was found in the text == Unused Reference: '47' is defined on line 658, but no explicit reference was found in the text == Unused Reference: '48' is defined on line 662, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '11') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1700 (ref. '12') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1521 (ref. '16') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 2401 (ref. '17') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 822 (ref. '26') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2543 (ref. '28') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2279 (ref. '33') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2271 (ref. '34') (Obsoleted by RFC 2571) ** Obsolete normative reference: RFC 1902 (ref. '38') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '39') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '40') (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1906 (ref. '43') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2272 (ref. '44') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (ref. '45') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 1905 (ref. '46') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2273 (ref. '47') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2275 (ref. '48') (Obsoleted by RFC 2575) == Outdated reference: draft-aboba-radius-ipv6 has been published as RFC 3162 Summary: 24 errors (**), 0 flaws (~~), 40 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 Category: Experimental Dave Lidyard 5 Telco Research Corporation 6 19 January 2001 8 The Accounting Data Interchange Format (ADIF) 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. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 1. Copyright Notice 30 Copyright (C) The Internet Society (2001). All Rights Reserved. 32 2. Abstract 34 This document describes an extensible human-readable accounting record 35 format, the Accounting Data Interchange Format (ADIF). Based on MIME, 36 ADIF is designed to compactly represent accounting data from any 37 protocol using attribute/value pairs (AVPs) or variable bindings. 39 ADIF may be used within accounting systems in several ways. In some 40 cases, Accounting Servers will produce ADIF records based on data 41 obtained from accounting protocols. It is also possible for devices to 42 store data in ADIF format and transfer ADIF records to the accounting 43 server, using an accounting or file transfer protocol. The latter 44 approach has the advantage of offloading the Accounting Server from the 45 task of transcribing interim or session records, thus improving 46 scalability. In either scenario, ADIF may be used to transfer a single 47 accounting records, or a batch of accounting records. 49 3. Introduction 51 This document describes an extensible human-readable accounting record 52 format, the Accounting Data Interchange Format (ADIF). Based on MIME, 53 ADIF is designed to compactly represent accounting data from any 54 protocol using attribute/value pairs (AVPs) or variable bindings. 56 ADIF may be used within accounting systems in several ways. In some 57 cases, Accounting Servers will produce ADIF records based on data 58 obtained from accounting protocols. It is also possible for devices to 59 store data in ADIF format and transfer ADIF records to the accounting 60 server, using an accounting or file transfer protocol. The latter 61 approach has the advantage of offloading the Accounting Server from the 62 task of transcribing interim or session records, thus improving 63 scalability. In either scenario, ADIF may be used to transfer a single 64 accounting records, or a batch of accounting records. 66 3.1. Terminology 68 This document uses the following terms: 70 Accounting 71 The collection of resource consumption data for the purposes 72 of capacity and trend analysis, cost allocation, auditing, and 73 billing. Accounting management requires that resource 74 consumption be measured, rated, assigned, and communicated 75 between appropriate parties. 77 Rating The act of determining the price to be charged for use of a 78 resource. 80 Billing The act of preparing an invoice. 82 Archival accounting 83 In archival accounting, the goal is to collect all accounting 84 data, to reconstruct missing entries as best as possible in 85 the event of data loss, and to archive data for a mandated 86 time period. It is "usual and customary" for these systems to 87 be engineered to be very robust against accounting data loss. 88 Legal or financial requirements frequently mandate archival 89 accounting practices, and may often dictate that data be kept 90 confidential, regardless of whether it is to be used for 91 billing purposes or not. 93 Interim accounting 94 An interim accounting packet provides a snapshot of usage 95 during a user's session. This may be useful in the event of a 96 device reboot or other network problem that prevents the 97 reception or generation of a session summary packet or session 98 record. Interim accounting packets can always be summarized 99 without the loss of information. 101 Session record 102 A session record represents a summary of the resource 103 consumption of a user over the entire session. Accounting 104 gateways creating the session record may do so by processing 105 interim accounting events or accounting events from several 106 devices serving the same user. 108 Accounting Protocol 109 A protocol used to convey data for accounting purposes. 111 Accounting server 112 The accounting server receives accounting data from devices 113 and translates it into session records. The accounting server 114 may also take responsibility for the routing of session 115 records to interested parties. 117 4. Accounting record format requirements 119 As detailed in [2], solution of the accounting problem in roaming 120 requires a standardized accounting record format to enable exchange of 121 accounting data between members of a roaming consortium. Since 122 operational roaming services, described in [1], exhibit considerable 123 diversity in their accounting implementations it is desirable that the 124 chosen accounting record format be protocol-independent. Since 125 accounting implementations are continually adding new attributes, 126 extensibility is important. 128 For accounting session records, compactness of representation is a 129 virtue. While compression can decrease the space taken up by a less 130 compact accounting record representation, the computational load of 131 compression and decompression will add to the overhead of accounting 132 processing, and there are situations (such as embedded devices) in which 133 this will be problematic. 135 Session records can be stored within devices where memory or non- 136 volatile storage is at a premium. Thus the compactness of the 137 representation will determine how much data can be stored prior to 138 experiencing data loss. 140 To satisfy legal and regulatory requirements it has become customary to 141 archive session records. Thus, the compactness of the representation 142 will determine how much warehouse space is required to store the tapes 143 or CD-ROMs of the archived data. In addition, where session records are 144 transferred over the wire the compactness of representation will 145 determine bandwidth consumption. For all these reasons, smaller is 146 better. 148 It is also desirable that accounting session records be human readable. 149 Since the processing of accounting data may ultimately result in the 150 transfer of funds, it is important that the software producing and 151 handling session records be correct. Human readable accounting formats 152 are considerably easier to implement and debug than binary formats and 153 thus software based on them is more likely to be free of defects. 155 The current state of the art in accounting data representation is 156 reviewed in [4]. While the SNMP-oriented formats described in [14], 157 [15] are appealing for representation of data collected via SNMP, they 158 are not appealing for use with other protocols since processing the 159 records would require ASN.1 encode and decoding operations that would 160 typically not otherwise be necessary. Also, ASN.1 interchange formats 161 are not human readable and require encoding and decoding of complex 162 binary structures. This makes them complex to work with as 163 computationally demanding as compared with plain-text files. 165 Binary formats such as those used in RADIUS [5]-[9] are relatively 166 simple, but require development of specialized tools that would not be 167 reusable for other protocols. Existing call detail records based on 168 fixed record formats, while being human readable, do not offer the 169 required extensibility. 171 XML-based accounting record formats such as TIPHON [29] are specified by 172 an XML DTD. XML is extensible, protocol-indepedent, and human 173 understandable. However, XML representations are not compact and 174 therefore may require compression prior to storage or transmission over 175 the wire. XML formats are also limited by XML's inability to specify 176 type or other validity checking for information within the tags. This 177 will be improved by the XML Schema [31] efforts, but a stable reference 178 implementation is not yet available. Thus, it appears that existing 179 approaches cannot simultaneously satisfy the requirements for 180 generality, extensibility, compactness and human readability. 182 One of the goals of ADIF is to provide a universal yet simple and easy 183 to understand accounting record format. While an ADIF parser is required 184 to make use of the new format, it is expected that the effort required 185 to create processing tools would be leveragable across multiple 186 protocols and services. 188 ADIF is based on MIME, described in [16]. The use of MIME enables ADIF 189 to represent both printable and non-printable characters as well as to 190 allow representation of attributes of unlimited size. Through the use of 191 attribute numbers and protocol defaults, it has been possible to produce 192 an accounting record format that is simultaneously human readable, 193 general, extensible, and compact. 195 4.1. Requirements language 197 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 198 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 199 described in [10]. 201 5. Definition of the Accounting Data Interchange Format (ADIF) 203 ADIF may be used to represent either a single accounting record or a 204 batch of accounting records of arbitrary size. A batch of ADIF records 205 consists of a header providing basic information about the records in 206 the file, followed by a series of records each separated by a separator. 207 The header includes the ADIF version number (1 for this document), 208 device name/description, and collection start date and time. A default 209 protocol type may be optionally included in the header. 211 Note that it is possible to use ADIF in a real-time accounting 212 environment where individual records are transmitted by the device to 213 the Accounting Server in ADIF format. In such a case it is up to the 214 mechanism to specify whether ADIF headers are included within each 215 record or are agreed to beforehand via some out-of-band mechanism. 217 Each record may consist of one or more lines, and as with MIME, 218 described in [16], lines may be continued by putting a space or tab 219 character on the succeeding line, allowing attributes to be of arbitrary 220 length. Lines beginning with the "#" character are taken as comments 221 and ignored. 223 Accounting records have traditionally been human-readable, so as to 224 allow them to be more easily debugged. ADIF attributes can be expressed 225 either in NVT ASCII (characters 32 through 126) or if non-printable 226 characters are required, in base64. 228 5.1. Attribute and sub-attribute encoding 230 ADIF includes support for encoding of attributes for any protocol 231 utilizing attribute/value pairs or variable bindings. The protocol type 232 is indicated by prepending the protocol keyword as defined by IANA and a 233 "//" to the attribute number, i.e. radius//46. To improve compactness, 234 when a default protocol is indicated in the header, attributes of the 235 default protocol do not need to include the protocol type. For example, 236 if defaultProtocol: radius is indicated in the ADIF header, then 32 may 237 be used instead of radius//32. 239 Protocols such as L2TP [13] include additional fields such as Vendor ID 240 and flags in their Attribute Value Pairs (AVPs). To encode such AVPs, 241 ADIF includes support for attribute numbers expressed in OID form, as 242 well as sub-attributes. Protocols such as COPS, defined in [22] include 243 attribute numbers expressed as a combination of C-Num and C-Type as well 244 as supporting complex objects. 246 Sub-attributes are included as additional fields, separated by a semi- 247 colon, and are of the form = . Sub-attributes used 248 in complex objects are numbered starting from 1; letters are used for 249 well-known sub-attributes. This document includes support for the 250 following well-known sub-attributes: VendorId, VendorType, Mandatory and 251 Hidden, which apply to all protocols. Other sub-attributes may be added 252 as needed. Use of the VendorId and VendorType sub-attribute may be used 253 for expression of vendor-specific attributes, such as those supported in 254 RADIUS. 256 As an example, the L2TP version number attribute (attribute 2) with the 257 Mandatory bit set would be expressed as "l2tp//2: 1; M=1". A COPS In- 258 Interface object (C-Num=3, C-Type=1, including an IPv4 address of 259 204.57.137.2 and an interface index of 1) would be expressed as 260 "cops//3.1: 1=204.57.137.2; 2=1" 262 5.2. OID encoding 264 In order to allow for compact representation of object identifiers, the 265 ADIF header allows the definition of oid-names that can be used in place 266 of an object-identifier sub-tree. For example, the inclusion of a header 267 statement: 269 oid-define: mib-2=1.3.6.1.2.1; 271 would permit the string "mib-2" to substitute for the sub-tree 272 1.3.6.1.2.1 wherever this occurred within the accounting record file. 273 This would allow the OID 1.3.6.1.2.1.2 to be abbreviated as mib-2.2. 275 5.3. ADIF data types 277 In order for to enable unambiguous encoding of protocols within ADIF, 278 and encourage interoperability, it is necessary to define exactly how 279 attributes and varbinds of various data types are represented within 280 ADIF. To achieve this, the ADIF BNF specifies the encoding of the 281 following data types: 283 IPv4Address - A 32-bit IPv4 address. 284 IPv6Address - A 128-bit IPv6 address. 285 Boolean - A single bit, whose value is either TRUE (1) or FALSE (0). 286 Char - An unsigned 8-bit number. 287 Integer16 - A signed 16-bit number. 288 Unsigned16 - An unsigned 16-bit number. 290 Integer32 - A signed 32-bit integer. 291 Unsigned32 - An unsigned 32-bit integer. 292 Integer64 - A signed 64-bit integer. 293 Unsigned64 - An unsigned 64-bit integer. 294 Float32 - A 32-bit IEEE floating point number. 295 Float64 - A 64-bit IEEE floating point number. 296 Float128 - A 128-bit IEEE floating point number. 297 OctetString - 1+ Octets containing binary data (values 0 through 255 decimal). 298 Encoded in ADIF as Base-64. 299 Text - 1+ Octets containing UTF-8 encoded 10646 [33] characters. 300 Time - 32 bit unsigned value, most significant octet first, representing 301 seconds since 00:00:00 UTC, January 1, 1970. 303 5.4. Grammar 305 The following definition uses the ABNF specified in [6]: 307 adif-file = header-spec *SEP 1*( SEP adif-record ) 308 header-spec = required-info SEP [optional-info SEP] 309 required-info = device-spec SEP start-spec SEP 310 optional-info = [version-spec SEP ] [description SEP] [def-protocol SEP] 311 [oid-def-spec SEP ] 312 device-spec = "device:" *SP value 313 description = "description:" *SP value 314 oid-def-spec = "oid-define:" *SP 1*(oid-name "=" oid-num ";") 315 def-protocol = "defaultProtocol:" *SP protocol 316 protocol = 317 version-spec = "version:" *SP number 318 number = 1*Digit ; number MUST be "1" for the 319 ; ADIF format described in this document 320 start-spec = "date:" *SP datetime 321 datetime = date SP time 322 date = Dd SP Mon SP YYYY 323 time = hh ":" mm ":" ss SP zone 324 Dd = 326 Mon = "JAN" / "FEB" / "MAR" / "APR" / "MAY" / "JUN" / 327 "JUL" / "AUG" / "SEP" / "OCT" / "NOV" / "DEC" 328 YYYY = 330 hh = 332 mm = 334 ss = 336 zone = 339 adif-record = 1*(attrval-series SEP) 340 attrval-series = [rdate-spec SEP] 1*(attrval-spec) 341 rdate-spec = "rdate:" *SP datetime 342 ; date at which accounting data was received 343 attrval-spec = attr ( (std-encoding / base-64-encoding) [sub-attr-encoding]) 344 comment = ("#" *safe) 345 std-encoding = (":" *SP value ) 346 base-64-encoding = ("::" *SP base64-value ) 347 base64-value = 348 sub-attr-encoding = *(";" sub-attr "=" ) 349 sub-attr = "M" / "H" / "VID" / "VT" / Digit 350 ; Mandatory, Hidden, Vendor ID, Vendor Type 351 ; well known sub-attributes or digit 352 attr = [protocol "//"] attribute-number 353 attribute-number = number / oid 354 oid = [ oid-name "." ] oid-num 355 oid-name = Alpha *(ldh-str) 356 oid-num = *(number "." ) number 357 value = IPv4Address / IPv6Address / Boolean / Char / 358 Integer16 / Unsigned16 / Unsigned24 / Integer32 / Unsigned32 / 359 Integer64 / Unsigned64 / Float32 / Float64 / 360 Float128 / Time / Text 361 ; Octet-String values encoded in Base-64 362 value = 1*safe-initval *safe 363 safe = 371 LF = 372 ldh-str = *( Alpha / Digit / "-" ) let-dig 373 let-dig = Alpha / Digit 374 Alpha = %x41-5A / %x61-7A ; A-Z / a-z 375 Digit = %x30-39 ;0-9 377 6. Profiles 379 In order to enable ADIF to be used for communicating accounting 380 information within a protocol, it is necessary to define an ADIF profile 381 for that protocol. The ADIF profile specifies additional well known 382 sub-attributes to be used with the protocol, as well as the data types 383 to be used for each variable. 385 This section defines the ADIF profile for RADIUS [5]-[9]. 387 6.1. RADIUS profile 389 6.1.1. Sub-attribute support 391 6.1.2. Data types 393 Below is the mapping between RADIUS data types defined in [5]-][9] and 394 the corresponding ADIF types: 396 RADIUS type ADIF type 397 ----------- ---------- 398 Address [5] IPv4Address 399 IPv6Address [49] IPv6Address 400 Tag [8] Char 401 Prefix [49] Char 402 Integer [5] Unsigned32 403 Salt [8] Unsigned16 404 String [5] Octet-String 405 Text [5] Text 406 Time [5] Time 407 Integer24 [8] Unsigned24 409 6.1.3. RADIUS example 411 Example 1: An ADIF file encoding RADIUS accounting data 413 version: 1 414 device: server3 415 description: Accounting Server 3 416 date: 02 Mar 1999 12:19:01 -0500 417 defaultProtocol: radius 419 rdate: 02 Mar 1999 12:20:17 -0500 420 #NAS-IP-Address 421 4: 204.45.34.12 422 #NAS-Port 423 5: 12 424 #NAS-Port-Type 425 61: 2 426 #User-Name 427 1: fred@bigco.com 428 #Acct-Status-Type 429 40: 2 430 #Acct-Delay-Time 431 41: 14 432 #Acct-Input-Octets 433 42: 234732 434 #Acct-Output-Octets 435 43: 15439 436 #Acct-Session-Id 437 44: 185 438 #Acct-Authentic 439 45: 1 440 #Acct-Session-Time 441 46: 1238 442 #Acct-Input-Packets 443 47: 153 444 #Acct-Output-Packets 445 48: 148 446 #Acct-Terminate-Cause 447 49: 11 448 #Acct-Multi-Session-Id 449 50: 73 450 #Acct-Link-Count 451 51: 2 453 Example 2: An ADIF file encoding RADIUS data with a vendor-specific 454 attribute 456 version: 1 457 device: server3 458 description: Accounting Server 3 459 date: 02 Mar 1998 12:19:01 -0500 460 defaultProtocol: radius 462 rdate: 02 Mar 1998 12:25:23 -0500 463 4: 204.45.34.12 464 5: 12 465 61: 2 466 1: fred@bigco.com 467 #Vendor-Specific 468 26: 2; VID=301; VT=22 469 40: 2 470 41: 14 471 42: 234732 472 43: 15439 473 44: 185 474 45: 1 475 46: 1238 476 47: 153 477 48: 148 478 49: 11 479 50: 73 480 51: 2 482 7. References 484 [1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roaming 485 Implementations", RFC 2194, September 1997. 487 [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming 488 Protocols", RFC 2477, January 1999. 490 [3] Aboba, B., Arkko, J., Harrington, D., "Introduction to Accounting 491 Management", RFC 2975, October 2000. 493 [4] Brownlee, N., Blount, A., "Accounting Attributes and Record 494 Formats", RFC 2924, September 2000. 496 [5] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote 497 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 499 [6] Rigney C., "RADIUS Accounting", RFC 2866, June 2000. 501 [7] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting Modifications 502 for Tunnel Protocol Support", RFC 2867, June 2000. 504 [8] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 505 Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", RFC 506 2868, June 2000. 508 [9] Rigney, C., Willats, W. and Calhoun, P., "RADIUS Extensions", RFC 509 2869, June 2000. 511 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement 512 Levels", BCP 14, RFC 2119, March 1997. 514 [11] Crocker, D., and P. Overrell, "Augmented BNF for Syntax 515 Specifications: ABNF", RFC 2234, November 1997. 517 [12] Reynolds, J., Postel, J., "Assigned Numbers," RFC 1700, October 518 1994. 520 [13] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and 521 Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August 522 1999. 524 [14] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Accounting 525 Information for ATM Networks", RFC 2512, February 1999. 527 [15] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Managed 528 Objects for Controlling the Collection and Storage of Accounting 529 Information for Connection-Oriented Networks", RFC 2513, February 530 1999. 532 [16] Borenstein, N., Freed, N. "MIME (Multipurpose Internet Mail 533 Extensions) Part One: Mechanisms for Specifying and Describing 534 the Format of Internet Message Bodies", RFC 1521, Bellcore, 535 Innosoft, December 1993. 537 [17] Atkinson, R., Kent, S., "Security Architecture for the Internet 538 Protocol", RFC 2401, November 1998. 540 [18] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting 541 Background", RFC 1272, November 1991. 543 [19] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow Measurement: 544 Architecture", RFC 2722, October 1999. 546 [20] Brownlee, N., "Traffic Flow Measurement: Meter MIB", Measurement: 547 Architecture", RFC 2720, October 1999. 549 [21] Handelman, S., Brownlee, N., Ruth, G. and S. Stibler, "New 550 Attributes for Traffic Flow Measurement", RFC 2724, October 1999. 552 [22] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. 553 Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, 554 January 2000. 556 [23] Information processing systems - Open Systems Interconnection - 557 Specification of Abstract Syntax Notation One (ASN.1), 558 International Organization for Standardization, International 559 Standard 8824, December 1987. 561 [24] Information processing systems - Open Systems Interconnection - 562 Specification of Basic Encoding Rules for Abstract Notation One 563 (ASN.1), International Organization for Standardization, 564 International Standard 8825, December 1987. 566 [25] "Data elements and interchange formats -- Information interchange 567 -- Representation of dates and times", ISO 8601:1988. 569 [26] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT 570 MESSAGES", STD 11, RFC 822, August 1982. 572 [27] "Specification of TMN applications at the Q3 interface: Call detail 573 recording", ITU-T Recommendation Q.825, 1998. 575 [28] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: 576 Session Initiation Protocol", RFC 2543, March 1999. 578 [29] "Telecommunications and Internet Protocol Harmonization Over 579 Networks (TIPHON); Inter-domain pricing, authorization, and usage 580 exchange", TS 101 321 V1.4.2, December 1998. 582 [30] Bray, T., J. Paoli, and C. Sperberg-McQueen, "Extensible Markup 583 Language (XML) 1.0", W3C Recommendation, February 1998. 585 [31] "XML Schema Part 2: Datatypes", W3C Working Draft 07 April 2000, 586 April 2000. 588 [32] "XML Schema Part 1: Structures", W3C Working Draft 7 April 2000, 589 April 2000. 591 [33] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 592 2279, January 1998. 594 [34] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 595 Describing SNMP Management Frameworks", RFC 2271, Cabletron 596 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 597 January 1998. 599 [35] Rose, M., and K. McCloghrie, "Structure and Identification of 600 Management Information for TCP/IP-based Internets", RFC 1155, 601 Performance Systems International, Hughes LAN Systems, May 1990. 603 [36] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 604 Performance Systems International, Hughes LAN Systems, March 1991. 606 [37] M. Rose, "A Convention for Defining Traps for use with the SNMP", 607 RFC 1215, Performance Systems International, March 1991. 609 [38] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 610 of Management Information for Version 2 of the Simple Network 611 Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco 612 Systems, Inc., Dover Beach Consulting, Inc., International Network 613 Services, January 1996. 615 [39] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 616 Conventions for Version 2 of the Simple Network Management Protocol 617 (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., 618 Dover Beach Consulting, Inc., International Network Services, 619 January 1996. 621 [40] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 622 Statements for Version 2 of the Simple Network Management Protocol 623 (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., 624 Dover Beach Consulting, Inc., International Network Services, 625 January 1996. 627 [41] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 628 Management Protocol", RFC 1157, SNMP Research, Performance Systems 629 International, Performance Systems International, MIT Laboratory 630 for Computer Science, May 1990. 632 [42] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 633 "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, 634 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 635 International Network Services, January 1996. 637 [43] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 638 Mappings for Version 2 of the Simple Network Management Protocol 639 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., 640 Dover Beach Consulting, Inc., International Network Services, 641 January 1996. 643 [44] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 644 Processing and Dispatching for the Simple Network Management 645 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 646 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 648 [45] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 649 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 650 2274, IBM T. J. Watson Research, January 1998. 652 [46] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 653 Operations for Version 2 of the Simple Network Management Protocol 654 (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., 655 Dover Beach Consulting, Inc., International Network Services, 656 January 1996. 658 [47] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 659 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco 660 Systems, January 1998 662 [48] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 663 Control Model (VACM) for the Simple Network Management Protocol 664 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 665 Cisco Systems, Inc., January 1998 667 [49] Aboba, B., Zorn, G., Mitton, D., "RADIUS and IPv6", Internet draft 668 (work in progress), draft-aboba-radius-ipv6-03.txt, November 2000 670 8. Security Considerations 672 Since accounting data may include sensitive information, it may be 673 desirable for this information to be kept confidential during 674 transmission. Several mechanisms may be used to accomplish this, 675 including IPSEC, described in [12]. 677 9. IANA Considerations 679 This draft creates two new name spaces that will need to be administered 680 by IANA, namely the ADIF protocol name and attribute number spaces. In 681 order to avoid creating any new administrative procedures, 682 administration of the ADIF protocol name space will piggy-back on the 683 allocation of IP protocol and UDP/TCP port numbers. Administration of 684 the ADIF attribute number space will piggy-back on administration of the 685 attribute numbers or object identifiers for the protocol in question. 687 ADIF protocol names are required to be unique, and are created 688 coincident with allocation of an IP protocol number or UDP/TCP port 689 number. In applying for a protocol number or UDP/TCP port, a unique 690 keyword is assigned to the protocol, and this keyword is used as the 691 ADIF protocol name. 693 Those wishing to use an ADIF protocol name should first acquire the 694 rights to use the corresponding protocol or port number. Using an ADIF 695 protocol name without first obtaining rights to a protocol or port 696 number creates the possibility of conflict and therefore is to be 697 discouraged. 699 Similarly, ADIF attribute numbers are allocated coincident with IANA 700 allocation of attribute numbers or object identifiers for a given 701 protocol. By default, the data types used with ADIF correspond to the 702 data types of the attributes or variable bindings defined within the 703 protocol specification. 705 Assuming that no new sub-attribute types need to be defined, and there 706 is no ambiguity in the data types to be used for representation of the 707 attributes or variable-bindings, then no specification is required for 708 use of ADIF with a given protocol. However, if new sub-attributes are 709 required, new data types need to be defined, or the mapping between the 710 protocol data types and corresponding ADIF types is unclear, then a 711 specification is required. In addition to addressing the outstanding 712 issues, the specification will typically include one or more examples of 713 ADIF use with that protocol. 715 10. Acknowledgments 717 Thanks to Glen Zorn of Cisco Systems, Jari Arkko of Ericsson, David 718 Franscone and Pat Calhoun of Sun Microsystems, Thomas Narten of IBM, and 719 Ryan Moats of AT&T for useful discussions of this problem space. 721 11. Authors' Addresses 723 Bernard Aboba 724 Microsoft Corporation 725 One Microsoft Way 726 Redmond, WA 98052 728 Phone: 425-936-6605 729 EMail: bernarda@microsoft.com 731 Dave Lidyard 732 Telco Research Corporation 733 616 Marriott Drive 734 Nashville, TN 37214 736 Phone: 615-231-6110 737 EMail: dave@telcores.com 739 12. Full Copyright Statement 741 Copyright (C) The Internet Society (2001). All Rights Reserved. 742 This document and translations of it may be copied and furnished to 743 others, and derivative works that comment on or otherwise explain it or 744 assist in its implementation may be prepared, copied, published and 745 distributed, in whole or in part, without restriction of any kind, 746 provided that the above copyright notice and this paragraph are included 747 on all such copies and derivative works. However, this document itself 748 may not be modified in any way, such as by removing the copyright notice 749 or references to the Internet Society or other Internet organizations, 750 except as needed for the purpose of developing Internet standards in 751 which case the procedures for copyrights defined in the Internet 752 Standards process must be followed, or as required to translate it into 753 languages other than English. The limited permissions granted above are 754 perpetual and will not be revoked by the Internet Society or its 755 successors or assigns. This document and the information contained 756 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 757 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 758 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 759 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 760 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 761 13. Expiration Date 763 This memo is filed as , and expires 764 September 1, 2001.