idnits 2.17.1 draft-ietf-adslmib-hc-tc-03.txt: 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (December 2002) is 7801 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) == Missing Reference: 'RFC2622' is mentioned on line 119, but not defined == Unused Reference: 'RFC2662' is defined on line 436, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1905 (Obsoleted by RFC 3416) -- Obsolete informational reference (is this intentional?): RFC 1906 (Obsoleted by RFC 3417) -- Obsolete informational reference (is this intentional?): RFC 2493 (Obsoleted by RFC 3593) -- Obsolete informational reference (is this intentional?): RFC 2495 (Obsoleted by RFC 3895) -- Obsolete informational reference (is this intentional?): RFC 2496 (Obsoleted by RFC 3896) -- Obsolete informational reference (is this intentional?): RFC 2558 (Obsoleted by RFC 3592) -- Obsolete informational reference (is this intentional?): RFC 2570 (Obsoleted by RFC 3410) -- Obsolete informational reference (is this intentional?): RFC 2571 (Obsoleted by RFC 3411) -- Obsolete informational reference (is this intentional?): RFC 2572 (Obsoleted by RFC 3412) -- Obsolete informational reference (is this intentional?): RFC 2573 (Obsoleted by RFC 3413) -- Obsolete informational reference (is this intentional?): RFC 2574 (Obsoleted by RFC 3414) -- Obsolete informational reference (is this intentional?): RFC 2575 (Obsoleted by RFC 3415) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Ray 2 Category: Internet Draft PESA Switching Systems 3 R. Abbi 4 Alcatel 5 December 2002 7 High Capacity Textual Conventions for MIB Modules Using 8 Performance History Based on 15 Minute Intervals 9 draft-ietf-adslmib-hc-tc-03.txt 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at: 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at: 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2002). All Rights Reserved. 34 Abstract 36 This document presents a set of Textual Conventions for MIB modules 37 which extends the conventions presented in RFC2493 to 64 bit 38 resolution using the conventions presented in RFC2856. 40 Table of Contents 42 1. The SNMP Management Framework ................................... 2 43 2. Overview ........................................................ 3 44 3. Definitions ..................................................... 4 45 References ...................................................... 8 46 Security Considerations ......................................... 10 47 IANA Considerations ............................................. 10 48 Acknowledgements ................................................ 10 49 Intellectual Property Notice .................................... 11 50 Authors' Addresses .............................................. 11 51 Full Copyright Statement ........................................ 11 53 1. The SNMP Management Framework 55 The SNMP Management Framework presently consists of five major 56 components: 58 o An overall architecture, described in RFC 2571 [RFC2571]. 60 o Mechanisms for describing and naming objects and events for the 61 purpose of management. The first version of this Structure of 62 Management Information (SMI) is called SMIv1 and described in STD 63 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 64 [RFC1215]. The second version, called SMIv2, is described in STD 65 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, 66 RFC 2580 [RFC2580]. 68 o Message protocols for transferring management information. The 69 first version of the SNMP message protocol is called SNMPv1 and 70 described in STD 15, RFC 1157 [RFC1157]. A second version of the 71 SNMP message protocol, which is not an Internet standards track 72 protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] 73 and RFC 1906 [RFC1906]. The third version of the message 74 protocol is called SNMPv3 and described in RFC 1906 [RFC1906], 75 RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 77 o Protocol operations for accessing management information. The 78 first set of protocol operations and associated PDU formats is 79 described in STD 15, RFC 1157 [RFC1157]. A second set of 80 protocol operations and associated PDU formats is described in 81 RFC 1905 [RFC1905]. 83 o A set of fundamental applications described in RFC 2573 [RFC2573] 84 and the view-based access control mechanism described in RFC 2575 85 [RFC2575]. 87 A more detailed introduction to the current SNMP Management Framework 88 can be found in RFC 2570 [RFC2570]. 90 Managed objects are accessed via a virtual information store, termed 91 the Management Information Base or MIB. Objects in the MIB are 92 defined using the mechanisms defined in the SMI. 94 This memo specifies a MIB module that is compliant to the SMIv2. The 95 textual conventions defined in this MIB module cannot be translated 96 to SMIv1 since the Counter64 type does not exist in SMIv1. 98 2. Overview 100 In cases where a manager must obtain performance history data about 101 the behavior of equipment it manages several strategies can be 102 followed in the design of a MIB that represents the managed 103 equipment, including: 105 0 The agent counts events on a continuous basis and, 106 whenever desired, the manager obtains the value of the event 107 counter and adjusts its understanding of the history of events 108 at the agent. 110 0 The agent allocates events to 'buckets' where each bucket 111 represents an interval of time. 113 Telecommunications equipment often makes use of the latter strategy. 114 For such equipment the standard practice is that history data is 115 maintained by the agent in terms of 15-minute intervals [T1.231]. 117 MIB modules for collecting performance history based on 15-minute 118 intervals have been defined for the DS1/E1 [RFC2495], DS3/E3 119 [RFC2496], SONET/SDH [RFC2558], and ADSL [RFC2622] interface types. 120 These MIB modules use a common set of textual conventions defined in 121 [RFC2493]. Those textual conventions are based on the Gauge32 122 data type. 124 A need has arisen in connection with recent work on a VDSL MIB 125 [VDSL-MIB] to define 64-bit versions of the textual conventions 126 in [RFC2493]. Ideally, these high-capacity textual conventions would 127 be based on a Gauge64 or Unsigned64 data type, but unfortunately no 128 such types exist in SMIv2. The next best choice would be to base 129 them on the CounterBasedGauge64 textual convention presented in 130 [RFC2856], but that is not possible either since SMIv2 allows only 131 base types to be used textual conventions. Therefore the textual 132 conventions presented in this memo are based directly on the 133 Counter64 type, like those in [RFC2856]. They are subject to the 134 following limitations: 136 - The MAX-ACCESS of objects defined using these textual conventions 137 must be read-only, because the MAX-ACCESS of the underlying 138 Counter64 type is read-only. 140 - No sub-range can be specified in object definitions using these 141 textual conventions, because sub-ranges are not allowed on 142 Counter64 objects. 144 - No DEFVAL clause can be specified in object definitions using 145 these textual conventions, because DEFVALs are not allowed on 146 Counter64 objects. 148 - Objects defined using these textual conventions cannot be used 149 in an INDEX clause, because there is no INDEX clause mapping 150 defined for objects of type Counter64. 152 3. Definitions 154 HC-PerfHist-TC-MIB DEFINITIONS ::= BEGIN 156 IMPORTS 157 MODULE-IDENTITY, 158 Counter64, 159 Unsigned32, 160 mib-2 FROM SNMPv2-SMI 161 TEXTUAL-CONVENTION FROM SNMPv2-TC; 163 hcPerfHistTCMIB MODULE-IDENTITY 164 LAST-UPDATED "200212300000Z" -- December 30, 2002 165 ORGANIZATION "ADSLMIB Working Group" 166 CONTACT-INFO "WG-email: adslmib@ietf.org 167 Info: https://www1.ietf.org/mailman/listinfo/adslmib 169 Chair: Mike Sneed 170 Sand Channel Systems 171 Postal: P.O. Box 37324 172 Raleigh NC 27627-7324 173 Email: sneedmike@hotmail.com 174 Phone: +1 206 600 7022 176 Co-editor: Bob Ray 177 PESA Switching Systems, Inc. 178 Postal: 330-A Wynn Drive 179 Huntsville, AL 35805 USA 180 Email: rray@pesa.com 181 Phone: +1 256 726 9200 ext. 142 183 Co-editor: Rajesh Abbi 184 Alcatel USA 185 Postal: 2912 Wake Forest Road 186 Raleigh, NC 27609-7860 USA 187 Email: Rajesh.Abbi@alcatel.com 188 Phone: +1 919 850 6194 189 " 190 DESCRIPTION 191 "This MIB Module provides Textual Conventions to be 192 used by systems supporting 15 minute based performance 193 history counts that require high-capacity counts." 195 REVISION "200206160000Z" -- June 16, 2002 196 DESCRIPTION "Corrected addresses and references." 198 REVISION "200209230000Z" -- September 23, 2002 199 DESCRIPTION "Added HCPerfValidIntervals, HCPerfInvalidIntervals, 200 HCPerfTimeElapsed, and HCPerfIntervalThreshold." 202 REVISION "200212300000Z" -- December 30, 2002 203 DESCRIPTION "Updated contact info for chair." 205 ::= { mib-2 xxx } -- to be assigned by IANA 207 -- The Textual Conventions defined below are organized 208 -- alphabetically 209 -- Use of these TCs assumes the following: 210 -- 0 The agent supports 15 minute based history 211 -- counters. 212 -- 0 The agent is capable of keeping a history of 96 213 -- intervals of 15 minute performance data. 214 -- 0 The agent may optionally support performance 215 -- data aggregating the history intervals. 216 -- 0 The agent will keep separate tables for the 217 -- current interval, the history intervals, and 218 -- the total aggregates. 219 -- 0 The agent will keep the following objects. 220 -- If performance data is kept for multiple instances 221 -- of a measured entity, then 222 -- these objects are applied to each instance of 223 -- the measured entity (e.g., interfaces). 225 HCPerfValidIntervals ::= TEXTUAL-CONVENTION 226 STATUS current 227 DESCRIPTION 228 "The number of previous near end intervals for which 229 data was collected. The value will be 96 unless the 230 measurement was (re-)started within the last 900 minutes, 231 in which case the value will be the number of complete 15 232 minute intervals for which the agent has at least some 233 data. In certain cases (e.g., in the case where the agent 234 is a proxy) it is possible that some intervals are 235 unavailable. In this case, this interval is the maximum 236 interval number for which data is available." 237 SYNTAX INTEGER (0..96) 239 HCPerfInvalidIntervals ::= TEXTUAL-CONVENTION 240 STATUS current 241 DESCRIPTION 242 "The number of previous intervals for which no data is 243 available. This object will typically be zero except in 244 cases where the data for some intervals are not available 245 (e.g., in proxy situations)." 246 SYNTAX INTEGER (0..96) 248 HCPerfTimeElapsed ::= TEXTUAL-CONVENTION 249 STATUS current 250 DESCRIPTION 251 "The number of seconds that have elapsed since the beginning 252 of the current measurement period. If, for some reason, such 253 as an adjustment in the system's time-of-day clock or the 254 addition of a leap second, the current interval exceeds the 255 maximum value, the agent will return the maximum value. 257 For 15 minute intervals, the range is limited to (0..899). 258 For 24 hour intervals, the range is limited to (0..86399)." 259 SYNTAX Unsigned32 (0..86399) 261 HCPerfIntervalThreshold ::= TEXTUAL-CONVENTION 262 STATUS current 263 DESCRIPTION 264 "This convention defines a range of values that may be set 265 in a fault threshold alarm control. As the number of 266 seconds in a 15-minute interval numbers at most 900, objects 267 of this type may have a range of 0...900, where the value of 268 0 disables the alarm." 269 SYNTAX Unsigned32 (0..900) 271 HCPerfCurrentCount ::= TEXTUAL-CONVENTION 272 STATUS current 273 DESCRIPTION 274 "A counter associated with a performance measurement in a 275 current 15 minute measurement interval. The value of this 276 counter starts from zero and is increased when associated 277 events occur, until the end of the 15 minute interval. 278 At that time the value of the counter is stored in the 279 first 15 minute history interval, and the CurrentCount is 280 restarted at zero. In the case where the agent has no valid 281 data available for the current interval the corresponding 282 object instance is not available and upon a retrieval 283 request a corresponding error message shall be returned to 284 indicate that this instance does not exist. 286 This count represents a a non-negative integer, which 287 may increase or decrease, but shall never exceed 2^64-1 288 (18446744073709551615 decimal), nor fall below 0. The 289 The value of a HCPerfCurrentCount object assumes its 290 maximum value whenever the underlying count exceeds 291 2^64-1. If the underlying count subsequently decreases 292 below 2^64-1 (due, e.g., to a retroactive adjustment as a 293 result of entering or exiting unavailable time), then the 294 HCPerfCurrentCount object also decreases. 296 Note that this TC is not strictly supported in SMIv2, 297 because the 'always increasing' and 'counter wrap' 298 semantics associated with the Counter64 base type are not 299 preserved. It is possible that management applications 300 which rely solely upon the (Counter64) ASN.1 tag to 301 determine object semantics will mistakenly operate upon 302 objects of this type as they would for Counter64 objects. 304 This textual convention represents a limited and short-term 305 solution, and may be deprecated as a long term solution is 306 defined and deployed to replace it." 307 SYNTAX Counter64 309 HCPerfIntervalCount ::= TEXTUAL-CONVENTION 310 STATUS current 311 DESCRIPTION 312 "A counter associated with a performance measurement in 313 a previous 15 minute measurement interval. In the case 314 where the agent has no valid data available for a 315 particular interval the corresponding object instance is 316 not available and upon a retrieval request a corresponding 317 error message shall be returned to indicate that this 318 instance does not exist. 320 In a system supporting a history of n intervals with 321 IntervalCount(1) and IntervalCount(n) the most and least 322 recent intervals respectively, the following applies at 323 the end of a 15 minute interval: 325 - discard the value of IntervalCount(n) 326 - the value of IntervalCount(i) becomes that 327 of IntervalCount(i-1) for n >= i > 1 328 - the value of IntervalCount(1) becomes that 329 of CurrentCount 330 - the TotalCount, if supported, is adjusted. 332 This count represents a a non-negative integer, which 333 may increase or decrease, but shall never exceed 2^64-1 334 (18446744073709551615 decimal), nor fall below 0. The 335 The value of a HCPerfIntervalCount object assumes its 336 maximum value whenever the underlying count exceeds 337 2^64-1. If the underlying count subsequently decreases 338 below 2^64-1 (due, e.g., to a retroactive adjustment as a 339 result of entering or exiting unavailable time), then the 340 HCPerfIntervalCount object also decreases. 342 Note that this TC is not strictly supported in SMIv2, 343 because the 'always increasing' and 'counter wrap' 344 semantics associated with the Counter64 base type are not 345 preserved. It is possible that management applications 346 which rely solely upon the (Counter64) ASN.1 tag to 347 determine object semantics will mistakenly operate upon 348 objects of this type as they would for Counter64 objects. 350 This textual convention represents a limited and short-term 351 solution, and may be deprecated as a long term solution is 352 defined and deployed to replace it." 353 SYNTAX Counter64 355 HCPerfTotalCount ::= TEXTUAL-CONVENTION 356 STATUS current 357 DESCRIPTION 358 "A counter associated with a performance measurements 359 aggregating the previous valid 15 minute measurement 360 intervals. Intervals for which no valid data was 361 available are not counted. 363 This count represents a a non-negative integer, which 364 may increase or decrease, but shall never exceed 2^64-1 365 (18446744073709551615 decimal), nor fall below 0. The 366 The value of a HCPerfTotalCount object assumes its 367 maximum value whenever the underlying count exceeds 368 2^64-1. If the underlying count subsequently decreases 369 below 2^64-1 (due, e.g., to a retroactive adjustment as a 370 result of entering or exiting unavailable time), then the 371 HCPerfTotalCount object also decreases. 373 Note that this TC is not strictly supported in SMIv2, 374 because the 'always increasing' and 'counter wrap' 375 semantics associated with the Counter64 base type are not 376 preserved. It is possible that management applications 377 which rely solely upon the (Counter64) ASN.1 tag to 378 determine object semantics will mistakenly operate upon 379 objects of this type as they would for Counter64 objects. 381 This textual convention represents a limited and short-term 382 solution, and may be deprecated as a long term solution is 383 defined and deployed to replace it." 384 SYNTAX Counter64 385 END 387 Informative References 389 [T1.231] American National Standard for Telecommunications - 390 Digital Hierarchy - Layer 1 In-Service Digital 391 Transmission Performance Monitoring, ANSI T1.231-1997, 392 September 1997. 394 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification 395 of Management Information for TCP/IP-based Internets", 396 STD 16, RFC 1155, May 1990. 398 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, 399 "Simple Network Management Protocol", STD 15, RFC 1157, 400 May 1990. 402 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", 403 STD 16, RFC 1212, March 1991. 405 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 406 the SNMP", RFC 1215, March 1991. 408 [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 409 "Introduction to Community-based SNMPv2", RFC 1901, 410 January 1996. 412 [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 413 "Protocol Operations for Version 2 of the Simple Network 414 Management Protocol (SNMPv2)", RFC 1905, January 1996. 416 [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 417 "Transport Mappings for Version 2 of the Simple Network 418 Management Protocol (SNMPv2)", RFC 1906, January 1996. 420 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 421 3", BCP 9, RFC 2026, October 1996. 423 [RFC2493] Tesink, K., "Textual Conventions for MIB Modules Using 424 Performance History Based on 15 Minute Intervals", RFC 425 2493, January 1999. 427 [RFC2495] Fowler, D., "Definitions of Managed Objects for the DS1, 428 E1, DS2 and E2 Interface Types", RFC 2495, January 1999. 430 [RFC2496] Fowler, D., "Definitions of Managed Objects for the 431 DS3/E3 Interface Type", RFC 2496, January 1999. 433 [RFC2558] Tesink, K., "Definitions of Managed Objects for the 434 SONET/SDH Interface Type", RFC 2558, March 1999. 436 [RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects 437 for the ADSL Lines", RFC 2662, August 1999. 439 [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, 440 "Introduction to Version 3 of the Internet-standard 441 Network Management Framework", RFC 2570, April 1999. 443 [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An 444 Architecture for Describing SNMP Management Frameworks", 445 RFC 2571, April 1999. 447 [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, 448 "Message Processing and Dispatching for the Simple 449 Network Management Protocol (SNMP)", RFC 2572, April 450 1999. 452 [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 453 Applications", RFC 2573, April 1999. 455 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model 456 (USM) for version 3 of the Simple Network Management 457 Protocol (SNMPv3)", RFC 2574, April 1999. 459 [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 460 Access Control Model (VACM) for the Simple Network 461 Management Protocol (SNMP)", RFC 2575, April 1999. 463 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 464 Rose, M. and S. Waldbusser, "Structure of Management 465 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 466 1999. 468 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 469 Rose, M. and S. Waldbusser, "Textual Conventions for 470 SMIv2", STD 58, RFC 2579, April 1999. 472 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 473 Rose, M. and S. Waldbusser, "Conformance Statements for 474 SMIv2", STD 58, RFC 2580, April 1999. 476 [RFC2856] Bierman, A., McCloghrie, K. and R. Presuhn, "Textual 477 Conventions for Additional High Capacity Data Types", 478 RFC2856, June 2000. 480 [VDSL-MIB] Ray, B. and R. Abbi, work in progress. 482 Security Considerations 484 This module does not define any management objects. Instead, it 485 defines a set of textual conventions which may be used by other MIB 486 modules to define management objects. 488 Meaningful security considerations can only be written in the modules 489 that define management objects. 491 IANA Considerations 493 Prior to publication of this memo as an RFC, IANA is requested to 494 make a suitable OBJECT IDENTIFIER assignment. 496 Acknowledgements 498 This document borrows tremendously from [RFC2493] and [RFC2856]. 500 As such, any credit for the text found within should be fully 501 attributed to the authors of those documents. 503 Intellectual Property Notice 505 The IETF takes no position regarding the validity or scope of any 506 intellectual property or other rights that might be claimed to 507 pertain to the implementation or use of the technology described in 508 this document or the extent to which any license under such rights 509 might or might not be available; neither does it represent that it 510 has made any effort to identify any such rights. Information on the 511 IETF's procedures with respect to rights in standards-track and 512 standards-related documentation can be found in BCP-11. Copies of 513 claims of rights made available for publication and any assurances of 514 licenses to be made available, or the result of an attempt made to 515 obtain a general license or permission for the use of such 516 proprietary rights by implementors or users of this specification can 517 be obtained from the IETF Secretariat. 519 The IETF invites any interested party to bring to its attention any 520 copyrights, patents or patent applications, or other proprietary 521 rights which may cover technology that may be required to practice 522 this standard. Please address the information to the IETF Executive 523 Director. 525 Authors' Addresses 527 Bob Ray 528 PESA Switching Systems, Inc. 529 330-A Wynn Drive 530 Huntsville, AL 35805 USA 532 Phone: +1 256 726 9200 ext. 142 533 Fax: +1 256 726 9271 534 EMail: rray@pesa.com 536 Rajesh Abbi 537 Alcatel USA 538 2912 Wake Forest Road 539 Raleigh, NC 27609-7860 USA 541 Phone: +1 919 850 6194 542 EMail: Rajesh.Abbi@alcatel.com 544 Full Copyright Statement 546 Copyright (C) The Internet Society (2002). All Rights Reserved. 547 This document and translations of it may be copied and furnished to 548 others, and derivative works that comment on or otherwise explain it 549 or assist in its implementation may be prepared, copied, published 550 and distributed, in whole or in part, without restriction of any 551 kind, provided that the above copyright notice and this paragraph are 552 included on all such copies and derivative works. However, this 553 document itself may not be modified in any way, such as by removing 554 the copyright notice or references to the Internet Society or other 555 Internet organizations, except as needed for the purpose of 556 developing Internet standards in which case the procedures for 557 copyrights defined in the Internet Standards process must be 558 followed, or as required to translate it into languages other than 559 English. 561 The limited permissions granted above are perpetual and will not be 562 revoked by the Internet Society or its successors or assigns. 564 This document and the information contained herein is provided on an 565 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 566 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 567 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 568 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 569 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.