idnits 2.17.1 draft-ietf-adslmib-hc-tc-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 -- 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 (March 2002) is 8075 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 118, but not defined == Unused Reference: 'RFC2662' is defined on line 432, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2493 (Obsoleted by RFC 3593) ** Obsolete normative reference: RFC 2495 (Obsoleted by RFC 3895) ** Obsolete normative reference: RFC 2496 (Obsoleted by RFC 3896) ** Obsolete normative reference: RFC 2558 (Obsoleted by RFC 3592) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) -- Possible downref: Non-RFC (?) normative reference: ref. 'VDSL-MIB' Summary: 20 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT R. Abbi 2 Expires October 1, 2002 Alcatel 4 B. Ray 5 March 2002 7 High Capacity Textual Conventions for MIB Modules Using 8 Performance History Based on 15 Minute Intervals 9 draft-ietf-adslmib-hc-tc-00.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 4 Acknowledgements .............................................. 8 46 5 References .................................................... 8 47 6 Security Considerations ....................................... 10 48 7 Author's Address .............................................. 10 49 8 Intellectual Property ......................................... 10 50 9 Full Copyright Statement ...................................... 11 52 1. The SNMP Management Framework 54 The SNMP Management Framework presently consists of five major 55 components: 57 o An overall architecture, described in RFC 2571 [RFC2571]. 59 o Mechanisms for describing and naming objects and events for the 60 purpose of management. The first version of this Structure of 61 Management Information (SMI) is called SMIv1 and described in STD 62 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 63 [RFC1215]. The second version, called SMIv2, is described in STD 64 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, 65 RFC 2580 [RFC2580]. 67 o Message protocols for transferring management information. The 68 first version of the SNMP message protocol is called SNMPv1 and 69 described in STD 15, RFC 1157 [RFC1157]. A second version of the 70 SNMP message protocol, which is not an Internet standards track 71 protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] 72 and RFC 1906 [RFC1906]. The third version of the message 73 protocol is called SNMPv3 and described in RFC 1906 [RFC1906], 74 RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 76 o Protocol operations for accessing management information. The 77 first set of protocol operations and associated PDU formats is 78 described in STD 15, RFC 1157 [RFC1157]. A second set of 79 protocol operations and associated PDU formats is described in 80 RFC 1905 [RFC1905]. 82 o A set of fundamental applications described in RFC 2573 [RFC2573] 83 and the view-based access control mechanism described in RFC 2575 84 [RFC2575]. 86 A more detailed introduction to the current SNMP Management Framework 87 can be found in RFC 2570 [RFC2570]. 89 Managed objects are accessed via a virtual information store, termed 90 the Management Information Base or MIB. Objects in the MIB are 91 defined using the mechanisms defined in the SMI. 93 This memo specifies a MIB module that is compliant to the SMIv2. The 94 textual conventions defined in this MIB module cannot be translated 95 to SMIv1 since the Counter64 type does not exist in SMIv1. 97 2. Overview 99 In cases where a manager must obtain performance history data about 100 the behavior of equipment it manages several strategies can be 101 followed in the design of a MIB that represents the managed 102 equipment, including: 104 0 The agent counts events on a continuous basis and, 105 whenever desired, the manager obtains the value of the event 106 counter and adjusts its understanding of the history of events 107 at the agent. 109 0 The agent allocates events to 'buckets' where each bucket 110 represents an interval of time. 112 Telecommunications equipment often makes use of the latter strategy. 113 For such equipment the standard practice is that history data is 114 maintained by the agent in terms of 15-minute intervals [T1.231]. 116 MIB modules for collecting performance history based on 15-minute 117 intervals have been defined for the DS1/E1 [RFC2495], DS3/E3 118 [RFC2496], SONET/SDH [RFC2558], and ADSL [RFC2622] interface types. 119 These MIB modules use a common set of textual conventions defined in 120 [RFC2493]. Those textual conventions are based on the Gauge32 121 data type. 123 A need has arisen in connection with recent work on a VDSL MIB 124 [VDSL-MIB] to define 64-bit versions of the textual conventions 125 in [RFC2493]. Ideally, these high-capacity textual conventions would 126 be based on a Gauge64 or Unsigned64 data type, but unfortunately no 127 such types exist in SMIv2. The next best choice would be to base 128 them on the CounterBasedGauge64 textual convention presented in 129 [RFC2856], but that is not possible either since SMIv2 allows only 130 base types to be used textual conventions. Therefore the textual 131 conventions presented in this memo are based directly on the 132 Counter64 type, like those in [RFC2856]. They are subject to the 133 following limitations: 135 - The MAX-ACCESS of objects defined using these textual conventions 136 must be read-only, because the MAX-ACCESS of the underlying 137 Counter64 type is read-only. 139 - No sub-range can be specified in object definitions using these 140 textual conventions, because sub-ranges are not allowed on 141 Counter64 objects. 143 - No DEFVAL clause can be specified in object definitions using 144 these textual conventions, because DEFVALs are not allowed on 145 Counter64 objects. 147 - Objects defined using these textual conventions cannot be used 148 in an INDEX clause, because there is no INDEX clause mapping 149 defined for objects of type Counter64. 151 3. Definitions 153 HC-PerfHist-TC-MIB DEFINITIONS ::= BEGIN 155 IMPORTS 156 MODULE-IDENTITY, 157 Counter64, 158 mib-2 FROM SNMPv2-SMI 159 TEXTUAL-CONVENTION FROM SNMPv2-TC; 161 hcPerfHistTCMIB MODULE-IDENTITY 162 LAST-UPDATED "200203310000Z" -- March 31, 2002 163 ORGANIZATION "ADSLMIB Working Group" 164 CONTACT-INFO "WG-email: adslmib@ietf.org 165 Info: https://www1.ietf.org/mailman/listinfo/adslmib 167 Chair: Mike Sneed 168 Inovia Telecoms 169 Postal: 1017 Main Campus Drive 170 Raleigh NC 27606 USA 171 Email: Mike.Sneed@go.ecitele.com 172 Phone: +1 919 513 1435 174 Co-editor: Rajesh Abbi 175 Alcatel USA 176 Postal: 2912 Wake Forest Road 177 Raleigh, NC 27609-7860 USA 178 Email: Rajesh.Abbi@usa.alcatel.com 179 Phone: +1 919 850 6194 181 Co-editor: Bob Ray 182 Email: bob_ray_99@yahoo.com 183 " 184 DESCRIPTION 185 "This MIB Module provides Textual Conventions to be 186 used by systems supporting 15 minute based performance 187 history counts that require high-capacity counts." 188 ::= { mib-2 xxx } -- to be assigned by IANA 190 -- The Textual Conventions defined below are organized 191 -- alphabetically 193 -- Use of these TCs assumes the following: 194 -- 0 The agent supports 15 minute based history 195 -- counters. 196 -- 0 The agent is capable of keeping a history of n 197 -- intervals of 15 minute performance data. The 198 -- value of n is defined by the specific MIB 199 -- module but shall be 0 < n =< 96. 201 -- 0 The agent may optionally support performance 202 -- data aggregating the history intervals. 203 -- 0 The agent will keep separate tables for the 204 -- current interval, the history intervals, and 205 -- the total aggregates. 206 -- 0 The agent will keep the following objects. 207 -- If performance data is kept for multiple instances 208 -- of a measured entity, then 209 -- these objects are applied to each instance of 210 -- the measured entity (e.g., interfaces). 212 -- xyzTimeElapsed OBJECT-TYPE 213 -- SYNTAX INTEGER (0..899) 214 -- MAX-ACCESS read-only 215 -- STATUS current 216 -- DESCRIPTION 217 -- "The number of seconds that have elapsed since 218 -- the beginning of the current measurement period. 219 -- If, for some reason, such as an adjustment in the 220 -- system's time-of-day clock, the current interval 221 -- exceeds the maximum value, the agent will return 222 -- the maximum value." 223 -- ::= { xxx } 225 -- xyzValidIntervals OBJECT-TYPE 226 -- SYNTAX INTEGER (0..) 227 -- MAX-ACCESS read-only 228 -- STATUS current 229 -- DESCRIPTION 230 -- "The number of previous near end intervals 231 -- for which data was collected. 232 -- [ The overall constraint on is 1 =< n =< 96; ] 233 -- [ Define any additional constraints on here. ] 234 -- The value will be unless the measurement was 235 -- (re-)started within the last (*15) minutes, in which 236 -- case the value will be the number of complete 15 237 -- minute intervals for which the agent has at least 238 -- some data. In certain cases (e.g., in the case 239 -- where the agent is a proxy) it is possible that some 240 -- intervals are unavailable. In this case, this 241 -- interval is the maximum interval number for 242 -- which data is available." 243 -- ::= { xxx } 245 -- xyzInvalidIntervals OBJECT-TYPE 246 -- SYNTAX INTEGER (0..) 247 -- MAX-ACCESS read-only 248 -- STATUS current 249 -- DESCRIPTION 250 -- "The number of intervals in the range from 251 -- 0 to xyzValidIntervals for which no 252 -- data is available. This object will typically 253 -- be zero except in cases where the data for some 254 -- intervals are not available (e.g., in proxy 255 -- situations)." 256 -- ::= { xxx } 258 -- See the notes in [RFC2493] for additional information 259 -- concerning the above objects. 261 HCPerfCurrentCount ::= TEXTUAL-CONVENTION 262 STATUS current 263 DESCRIPTION 264 "A counter associated with a performance measurement in a 265 current 15 minute measurement interval. The value of this 266 counter starts from zero and is increased when associated 267 events occur, until the end of the 15 minute interval. 268 At that time the value of the counter is stored in the 269 first 15 minute history interval, and the CurrentCount is 270 restarted at zero. In the case where the agent has no valid 271 data available for the current interval the corresponding 272 object instance is not available and upon a retrieval 273 request a corresponding error message shall be returned to 274 indicate that this instance does not exist. 276 This count represents a a non-negative integer, which 277 may increase or decrease, but shall never exceed 2^64-1 278 (18446744073709551615 decimal), nor fall below 0. The 279 The value of a HCPerfCurrentCount object assumes its 280 maximum value whenever the underlying count exceeds 281 2^64-1. If the underlying count subsequently decreases 282 below 2^64-1 (due, e.g., to a retroactive adjustment as a 283 result of entering or exiting unavailable time), then the 284 HCPerfCurrentCount object also decreases. 286 Note that this TC is not strictly supported in SMIv2, 287 because the 'always increasing' and 'counter wrap' 288 semantics associated with the Counter64 base type are not 289 preserved. It is possible that management applications 290 which rely solely upon the (Counter64) ASN.1 tag to 291 determine object semantics will mistakenly operate upon 292 objects of this type as they would for Counter64 objects. 294 This textual convention represents a limited and short-term 295 solution, and may be deprecated as a long term solution is 296 defined and deployed to replace it." 297 SYNTAX Counter64 299 HCPerfIntervalCount ::= TEXTUAL-CONVENTION 300 STATUS current 301 DESCRIPTION 302 "A counter associated with a performance measurement in 303 a previous 15 minute measurement interval. In the case 304 where the agent has no valid data available for a 305 particular interval the corresponding object instance is 306 not available and upon a retrieval request a corresponding 307 error message shall be returned to indicate that this 308 instance does not exist. 310 In a system supporting a history of n intervals with 311 IntervalCount(1) and IntervalCount(n) the most and least 312 recent intervals respectively, the following applies at 313 the end of a 15 minute interval: 315 - discard the value of IntervalCount(n) 316 - the value of IntervalCount(i) becomes that 317 of IntervalCount(i-1) for n >= i > 1 318 - the value of IntervalCount(1) becomes that 319 of CurrentCount 320 - the TotalCount, if supported, is adjusted. 322 This count represents a a non-negative integer, which 323 may increase or decrease, but shall never exceed 2^64-1 324 (18446744073709551615 decimal), nor fall below 0. The 325 The value of a HCPerfIntervalCount object assumes its 326 maximum value whenever the underlying count exceeds 327 2^64-1. If the underlying count subsequently decreases 328 below 2^64-1 (due, e.g., to a retroactive adjustment as a 329 result of entering or exiting unavailable time), then the 330 HCPerfIntervalCount object also decreases. 332 Note that this TC is not strictly supported in SMIv2, 333 because the 'always increasing' and 'counter wrap' 334 semantics associated with the Counter64 base type are not 335 preserved. It is possible that management applications 336 which rely solely upon the (Counter64) ASN.1 tag to 337 determine object semantics will mistakenly operate upon 338 objects of this type as they would for Counter64 objects. 340 This textual convention represents a limited and short-term 341 solution, and may be deprecated as a long term solution is 342 defined and deployed to replace it." 343 SYNTAX Counter64 345 HCPerfTotalCount ::= TEXTUAL-CONVENTION 346 STATUS current 347 DESCRIPTION 348 "A counter associated with a performance measurements 349 aggregating the previous valid 15 minute measurement 350 intervals. Intervals for which no valid data was 351 available are not counted. 353 This count represents a a non-negative integer, which 354 may increase or decrease, but shall never exceed 2^64-1 355 (18446744073709551615 decimal), nor fall below 0. The 356 The value of a HCPerfTotalCount object assumes its 357 maximum value whenever the underlying count exceeds 358 2^64-1. If the underlying count subsequently decreases 359 below 2^64-1 (due, e.g., to a retroactive adjustment as a 360 result of entering or exiting unavailable time), then the 361 HCPerfTotalCount object also decreases. 363 Note that this TC is not strictly supported in SMIv2, 364 because the 'always increasing' and 'counter wrap' 365 semantics associated with the Counter64 base type are not 366 preserved. It is possible that management applications 367 which rely solely upon the (Counter64) ASN.1 tag to 368 determine object semantics will mistakenly operate upon 369 objects of this type as they would for Counter64 objects. 371 This textual convention represents a limited and short-term 372 solution, and may be deprecated as a long term solution is 373 defined and deployed to replace it." 374 SYNTAX Counter64 375 END 377 4. Acknowledgements 379 This document borrows tremendously from [RFC2493] and [RFC2856]. 380 As such, any credit for the text found within should be fully 381 attributed to the authors of those documents. 383 5. References 385 [T1.231] American National Standard for Telecommunications - 386 Digital Hierarchy - Layer 1 In-Service Digital 387 Transmission Performance Monitoring, ANSI T1.231-1997, 388 September 1997. 390 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification 391 of Management Information for TCP/IP-based Internets", 392 STD 16, RFC 1155, May 1990. 394 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, 395 "Simple Network Management Protocol", STD 15, RFC 1157, 396 May 1990. 398 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", 399 STD 16, RFC 1212, March 1991. 401 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 402 the SNMP", RFC 1215, March 1991. 404 [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 405 "Introduction to Community-based SNMPv2", RFC 1901, 406 January 1996. 408 [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 409 "Protocol Operations for Version 2 of the Simple Network 410 Management Protocol (SNMPv2)", RFC 1905, January 1996. 412 [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 413 "Transport Mappings for Version 2 of the Simple Network 414 Management Protocol (SNMPv2)", RFC 1906, January 1996. 416 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 417 3", BCP 9, RFC 2026, October 1996. 419 [RFC2493] Tesink, K., "Textual Conventions for MIB Modules Using 420 Performance History Based on 15 Minute Intervals", RFC 421 2493, January 1999. 423 [RFC2495] Fowler, D., "Definitions of Managed Objects for the DS1, 424 E1, DS2 and E2 Interface Types", RFC 2495, January 1999. 426 [RFC2496] Fowler, D., "Definitions of Managed Objects for the 427 DS3/E3 Interface Type", RFC 2496, January 1999. 429 [RFC2558] Tesink, K., "Definitions of Managed Objects for the 430 SONET/SDH Interface Type", RFC 2558, March 1999. 432 [RFC2662] Bathrick, G., and F. Ly, "Definitions of Managed Objects 433 for the ADSL Lines", RFC 2662, August 1999. 435 [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, 436 "Introduction to Version 3 of the Internet-standard 437 Network Management Framework", RFC 2570, April 1999. 439 [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An 440 Architecture for Describing SNMP Management Frameworks", 441 RFC 2571, April 1999. 443 [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, 444 "Message Processing and Dispatching for the Simple 445 Network Management Protocol (SNMP)", RFC 2572, April 446 1999. 448 [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 449 Applications", RFC 2573, April 1999. 451 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model 452 (USM) for version 3 of the Simple Network Management 453 Protocol (SNMPv3)", RFC 2574, April 1999. 455 [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 456 Access Control Model (VACM) for the Simple Network 457 Management Protocol (SNMP)", RFC 2575, April 1999. 459 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 460 Rose, M. and S. Waldbusser, "Structure of Management 461 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 462 1999. 464 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 465 Rose, M. and S. Waldbusser, "Textual Conventions for 466 SMIv2", STD 58, RFC 2579, April 1999. 468 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 469 Rose, M. and S. Waldbusser, "Conformance Statements for 470 SMIv2", STD 58, RFC 2580, April 1999. 472 [RFC2856] Bierman, A., McCloghrie, K., Presuhn, R., "Textual 473 Conventions for Additional High Capacity Data Types", 474 RFC2856, June 2000. 476 [VDSL-MIB] Abbi, R., Ray, B., work in progress. 478 6. Security Considerations 480 This module does not define any management objects. Instead, it 481 defines a set of textual conventions which may be used by other MIB 482 modules to define management objects. 484 Meaningful security considerations can only be written in the modules 485 that define management objects. 487 7. Author's Address 489 Rajesh Abbi 490 Alcatel USA 491 2912 Wake Forest Road 492 Raleigh, NC 27609-7860 USA 493 EMail: Rajesh.Abbi@usa.alcatel.com 494 Phone: +1 919 850 6194 496 Bob Ray 497 EMail: bob_ray_99@yahoo.com 499 8. Intellectual Property 501 The IETF takes no position regarding the validity or scope of any 502 intellectual property or other rights that might be claimed to 503 pertain to the implementation or use of the technology described in 504 this document or the extent to which any license under such rights 505 might or might not be available; neither does it represent that it 506 has made any effort to identify any such rights. Information on the 507 IETF's procedures with respect to rights in standards-track and 508 standards-related documentation can be found in BCP-11. Copies of 509 claims of rights made available for publication and any assurances of 510 licenses to be made available, or the result of an attempt made to 511 obtain a general license or permission for the use of such 512 proprietary rights by implementors or users of this specification can 513 be obtained from the IETF Secretariat. 515 The IETF invites any interested party to bring to its attention any 516 copyrights, patents or patent applications, or other proprietary 517 rights which may cover technology that may be required to practice 518 this standard. Please address the information to the IETF Executive 519 Director. 521 9. Full Copyright Statement 523 Copyright (C) The Internet Society (2002). All Rights Reserved. 525 This document and translations of it may be copied and furnished to 526 others, and derivative works that comment on or otherwise explain it 527 or assist in its implementation may be prepared, copied, published 528 and distributed, in whole or in part, without restriction of any 529 kind, provided that the above copyright notice and this paragraph are 530 included on all such copies and derivative works. However, this 531 document itself may not be modified in any way, such as by removing 532 the copyright notice or references to the Internet Society or other 533 Internet organizations, except as needed for the purpose of 534 developing Internet standards in which case the procedures for 535 copyrights defined in the Internet Standards process must be 536 followed, or as required to translate it into languages other than 537 English. 539 The limited permissions granted above are perpetual and will not be 540 revoked by the Internet Society or its successors or assigns. 542 This document and the information contained herein is provided on an 543 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 544 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 545 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 546 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 547 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.