idnits 2.17.1 draft-ietf-disman-schedule-mib-06.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 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 are 3 instances 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 == Line 1172 has weird spacing: '...for the purpo...' -- 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 (18 November 1998) is 9288 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '16' is defined on line 1132, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2271 (ref. '1') (Obsoleted by RFC 2571) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Obsolete normative reference: RFC 1902 (ref. '5') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '6') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '7') (Obsoleted by RFC 2580) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '9') ** Obsolete normative reference: RFC 1906 (ref. '10') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2272 (ref. '11') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (ref. '12') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 1905 (ref. '13') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2273 (ref. '14') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2275 (ref. '15') (Obsoleted by RFC 2575) ** Obsolete normative reference: RFC 2028 (ref. '16') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Obsolete normative reference: RFC 2233 (ref. '18') (Obsoleted by RFC 2863) Summary: 24 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group David Levi 3 Internet-Draft SNMP Research, Inc. 4 Expires May 1999 Juergen Schoenwaelder 5 TU Braunschweig 6 18 November 1998 8 Definitions of Managed Objects for 9 Scheduling Management Operations 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 29 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Distribution of this document is unlimited. Please send comments to 32 the Distributed Management Working Group, . 34 Copyright Notice 36 Copyright (C) The Internet Society (1998). All Rights Reserved. 38 Abstract 40 This memo defines a portion of the Management Information Base (MIB) 41 for use with network management protocols in the Internet community. 42 In particular, it describes a set of managed objects that are used to 43 schedule management operations periodically or at specified dates and 44 times. 46 Table of Contents 48 1 Introduction ................................................. 3 49 2 The SNMP Management Framework ................................ 3 50 3 Overview ..................................................... 4 51 3.1 Periodic Schedules ......................................... 4 52 3.2 Calendar Schedules ......................................... 5 53 3.3 One-shot Schedules ......................................... 5 54 3.4 Time Transitions ........................................... 5 55 3.5 Actions .................................................... 6 56 4 Definitions .................................................. 7 57 5 Usage Examples ............................................... 20 58 5.1 Starting a script to ping devices every 20 minutes ......... 20 59 5.2 Starting a script at the next Friday the 13th .............. 20 60 5.3 Turning an interface off during weekends ................... 21 61 6 Security Considerations ...................................... 23 62 7 Intellectual Property ........................................ 24 63 8 Acknowledgments .............................................. 24 64 9 References ................................................... 25 65 10 Editors' Addresses .......................................... 27 66 11 Full Copyright Statement .................................... 27 68 1. Introduction 70 This memo defines a portion of the Management Information Base (MIB) 71 for use with network management protocols in the Internet community. 72 In particular, it describes a set of managed objects that are used to 73 schedule management operations periodically or at specified dates and 74 times. 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [19]. 80 2. The SNMP Management Framework 82 The SNMP Management Framework presently consists of five major 83 components: 85 o An overall architecture, described in RFC 2271 [1]. 87 o Mechanisms for describing and naming objects and events for the 88 purpose of management. The first version of this Structure of 89 Management Information (SMI) is called SMIv1 and described in 90 RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, 91 called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 92 1904 [7]. 94 o Message protocols for transferring management information. The 95 first version of the SNMP message protocol is called SNMPv1 and 96 described in RFC 1157 [8]. A second version of the SNMP message 97 protocol, which is not an Internet standards track protocol, is 98 called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. 99 The third version of the message protocol is called SNMPv3 and 100 described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. 102 o Protocol operations for accessing management information. The 103 first set of protocol operations and associated PDU formats is 104 described in RFC 1157 [8]. A second set of protocol operations 105 and associated PDU formats is described in RFC 1905 [13]. 107 o A set of fundamental applications described in RFC 2273 [14] and 108 the view-based access control mechanism described in RFC 2275 109 [15]. 111 Managed objects are accessed via a virtual information store, termed 112 the Management Information Base or MIB. Objects in the MIB are 113 defined using the mechanisms defined in the SMI. 115 This memo specifies a MIB module that is compliant to the SMIv2. A 116 MIB conforming to the SMIv1 can be produced through the appropriate 117 translations. The resulting translated MIB must be semantically 118 equivalent, except where objects or events are omitted because no 119 translation is possible (use of Counter64). Some machine readable 120 information in SMIv2 will be converted into textual descriptions in 121 SMIv1 during the translation process. However, this loss of machine 122 readable information is not considered to change the semantics of the 123 MIB. 125 3. Overview 127 The MIB defined in this memo provides scheduling of actions 128 periodically or at specified dates and times. The actions can be used 129 to realize on-duty / off-duty schedules or to trigger management 130 functions in a distributed management application. 132 Schedules can be enabled or disabled by modifying a control object. 133 This allows pre-configured schedules which are activated or de- 134 activated by some other management functions. 136 The term `scheduler' is used throughout this memo to refer to the 137 entity which implements the scheduling MIB and which invokes the 138 actions at the specified points in time. 140 3.1. Periodic Schedules 142 Periodic schedules are based on fixed time periods between the 143 initiation of scheduled actions. Periodic schedules are defined by 144 specifying the number of seconds between two initiations. The time 145 needed to complete the action is usually not known by the scheduler 146 and does therefore not influence the next scheduling point. 148 Implementations must guarantee that action invocations will not occur 149 before their next scheduled time. However, implementations may be 150 forced to delay invocations in the face of local constraints (e.g., a 151 heavy load on higher-priority tasks). An accumulation of such delays 152 would result in a drift of the scheduling interval with respect to 153 time, and should be avoided. 155 Scheduled actions collecting statistical data should retrieve time 156 stamps from the data source and not rely on the accuracy of the 157 periodic scheduler in order to obtain accurate statistics. 159 3.2. Calendar Schedules 161 Calendar schedules trigger scheduled actions at specified days of the 162 week and days of the month. Calendar schedules are therefore aware of 163 the notion of months, days, weekdays, hours and minutes. 165 It is possible to specify multiple values for each calendar item. 166 This provides a mechanism for defining complex schedules. For 167 example, a schedule could be defined which triggers an action every 168 15 minutes on a given weekday. 170 Months, days and weekdays are specified using the objects schedMonth, 171 schedDay and schedWeekDay of type BITS. Setting multiple bits to one 172 in these objects causes an OR operation. For example, setting the 173 bits monday(1) and friday(5) in schedWeekDay restricts the schedule 174 to Mondays and Fridays. 176 The bit fields for schedMonth, schedDay and schedWeekDay are combined 177 using an AND operation. For example, setting the bits june(5) and 178 july(6) in schedMonth and combining it with the bits monday(1) and 179 friday(5) set in schedWeekDay will result in a schedule which is 180 restricted to every Monday and Friday in the months June and July. 181 Wildcarding of calendar items is achieved by setting all bits to one. 183 It is possible to define calendar schedules that will never trigger 184 an action. For example, one can define a calendar schedule which 185 should trigger an action on February 31st. Schedules like this will 186 simply be ignored by the scheduler. 188 Finally, calendar schedules are always expressed in local time. A 189 scalar, schedLocalTime is provided so that a manager can retrieve the 190 notion of local time and the offset to GMT time. 192 3.3. One-shot Schedules 194 One-shot Schedules are similar to calendar schedules. The difference 195 between a calendar schedule and a one-shot schedule is that a one- 196 shot schedule will automatically disable itself once an action has 197 been invoked. 199 3.4. Time Transitions 201 When a system's notion of time is changed for some reason, 202 implementations of the Schedule MIB must schedule actions 203 differently. One example of a change to a system's notion of time is 204 when a daylight savings time transition occurs. 206 There are two possible situations when a time transition occurs. 207 First, time may be set backwards, in which case particular times will 208 appear to occur twice within the same day. These are called 209 'ambiguous times'. Second, time may be set forwards, in which case 210 particular times will appear to not occur within a day. This are 211 called 'nonexistent times'. 213 When an action is configured in the Schedule MIB to occur at an 214 ambiguous time during a time transition, the action SHALL only be 215 invoked at the first occurence of the ambiguous time. For example, 216 if an action is scheduled to occur at 2:00 am, and a time transition 217 occurs at 3:00 am which sets the clock back to 2:00 am, the action 218 SHALL only be invoked at the first occurence of 2:00 am. 220 When an action is configured in the Schedule MIB to occur at a 221 nonexistent time, the action SHOULD be invoked immediately upon a 222 time transition. If multiple actions are invoked in this way, they 223 SHALL be invoked in the order in which they normally would be invoked 224 had the time transition not occured. For example, if an action (a) is 225 scheduled at 2:05 am and another action (b) at 2:10 am, then both 226 actions SHOULD be invoked at 3:00 am in the order (a),(b) if the time 227 jumps forward from 2:00 am to 3:00 am. 229 3.5. Actions 231 Scheduled actions are modeled by SNMP set operations on local MIB 232 variables. Scheduled actions described in this MIB are further 233 restricted to objects of type INTEGER. This restriction does not 234 limit the usefulness of the MIB. Simple schedules such as on-duty / 235 off-duty schedules for resources that have a status MIB object (e.g. 236 ifAdminStatus) are possible. 238 More complex actions can be realized by triggering a management 239 script which is responsible for performing complex state transitions. 240 A management script can also be used to perform SNMP set operations 241 on remote SNMP engines. 243 4. Definitions 245 DISMAN-SCHEDULE-MIB DEFINITIONS ::= BEGIN 247 IMPORTS 248 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 249 Integer32, Unsigned32, Counter32, experimental 250 FROM SNMPv2-SMI 252 TEXTUAL-CONVENTION, 253 DateAndTime, RowStatus, StorageType, VariablePointer 254 FROM SNMPv2-TC 256 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 257 FROM SNMPv2-CONF 259 SnmpAdminString 260 FROM SNMP-FRAMEWORK-MIB; 262 schedMIB MODULE-IDENTITY 263 LAST-UPDATED "9811171800Z" 264 ORGANIZATION "IETF Distributed Management Working Group" 265 CONTACT-INFO 266 "David B. Levi 267 SNMP Research, Inc. 268 3001 Kimberlin Heights Road 269 Knoxville, TN 37920-9716 270 U.S.A. 271 Tel: +1 423 573 1434 272 E-mail: levi@snmp.com 274 Juergen Schoenwaelder 275 TU Braunschweig 276 Bueltenweg 74/75 277 38106 Braunschweig 278 Germany 279 Tel: +49 531 391-3283 280 E-mail: schoenw@ibr.cs.tu-bs.de" 281 DESCRIPTION 282 "This MIB module defines a MIB which provides mechanisms to 283 schedule SNMP set operations periodically or at specific 284 points in time." 285 -- XXX Replace with real registration number from IANA. Note, the 286 -- XXX IMPORTS must be updated when the real number is assigned. 287 -- ::= { mib-2 XXXX } 288 ::= { experimental 6789 } 290 -- 291 -- The various groups defined within this MIB definition: 292 -- 294 schedObjects OBJECT IDENTIFIER ::= { schedMIB 1 } 295 schedNotifications OBJECT IDENTIFIER ::= { schedMIB 2 } 296 schedConformance OBJECT IDENTIFIER ::= { schedMIB 3 } 298 -- 299 -- Textual Conventions: 300 -- 302 SnmpPduErrorStatus ::= TEXTUAL-CONVENTION 303 STATUS current 304 DESCRIPTION 305 "This TC enumerates the SNMPv1 and SNMPv2 PDU error status 306 codes as defined in RFC 1157 and RFC 1905. It also adds a 307 pseudo error status code `noResponse' which indicates a 308 timeout condition." 309 SYNTAX INTEGER { 310 noResponse(-1), 311 noError(0), 312 tooBig(1), 313 noSuchName(2), 314 badValue(3), 315 readOnly(4), 316 genErr(5), 317 noAccess(6), 318 wrongType(7), 319 wrongLength(8), 320 wrongEncoding(9), 321 wrongValue(10), 322 noCreation(11), 323 inconsistentValue(12), 324 resourceUnavailable(13), 325 commitFailed(14), 326 undoFailed(15), 327 authorizationError(16), 328 notWritable(17), 329 inconsistentName(18) 330 } 332 -- 333 -- Some scalars which provide information about the local time zone. 334 -- 336 schedLocalTime OBJECT-TYPE 337 SYNTAX DateAndTime (SIZE (11)) 338 MAX-ACCESS read-only 339 STATUS current 340 DESCRIPTION 341 "The local time used by the scheduler. Schedules which refer 342 to calendar time will use the local time indicated by this 343 object. An implementation MUST return all 11 bytes of the 344 DateAndTime textual-convention so that a manager may 345 retrieve the offset from GMT time." 346 ::= { schedObjects 1 } 348 -- 349 -- The schedule table which controls the scheduler. 350 -- 352 schedTable OBJECT-TYPE 353 SYNTAX SEQUENCE OF SchedEntry 354 MAX-ACCESS not-accessible 355 STATUS current 356 DESCRIPTION 357 "This table defines scheduled actions triggered by 358 SNMP set operations." 359 ::= { schedObjects 2 } 361 schedEntry OBJECT-TYPE 362 SYNTAX SchedEntry 363 MAX-ACCESS not-accessible 364 STATUS current 365 DESCRIPTION 366 "An entry describing a particular scheduled action." 367 INDEX { schedOwner, schedName } 368 ::= { schedTable 1 } 370 SchedEntry ::= SEQUENCE { 371 schedOwner SnmpAdminString, 372 schedName SnmpAdminString, 373 schedDescr SnmpAdminString, 374 schedInterval Unsigned32, 375 schedWeekDay BITS, 376 schedMonth BITS, 377 schedDay BITS, 378 schedHour BITS, 379 schedMinute BITS, 380 schedContextName SnmpAdminString, 381 schedVariable VariablePointer, 382 schedValue Integer32, 383 schedType INTEGER, 384 schedAdminStatus INTEGER, 385 schedOperStatus INTEGER, 386 schedFailures Counter32, 387 schedLastFailure SnmpPduErrorStatus, 388 schedLastFailed DateAndTime, 389 schedStorageType StorageType, 390 schedRowStatus RowStatus 391 } 393 schedOwner OBJECT-TYPE 394 SYNTAX SnmpAdminString (SIZE(0..32)) 395 MAX-ACCESS not-accessible 396 STATUS current 397 DESCRIPTION 398 "The owner of this scheduling entry. The exact semantics of 399 this string are subject to the security policy defined by 400 the security administrator." 401 ::= { schedEntry 1 } 403 schedName OBJECT-TYPE 404 SYNTAX SnmpAdminString (SIZE(1..32)) 405 MAX-ACCESS not-accessible 406 STATUS current 407 DESCRIPTION 408 "The locally-unique, administratively assigned name for this 409 scheduling entry. This object allows a schedOwner to have 410 multiple entries in the schedTable." 411 ::= { schedEntry 2 } 413 schedDescr OBJECT-TYPE 414 SYNTAX SnmpAdminString 415 MAX-ACCESS read-create 416 STATUS current 417 DESCRIPTION 418 "The human readable description of the purpose of this 419 scheduling entry." 420 DEFVAL { ''H } 421 ::= { schedEntry 3 } 423 schedInterval OBJECT-TYPE 424 SYNTAX Unsigned32 425 UNITS "seconds" 426 MAX-ACCESS read-create 427 STATUS current 428 DESCRIPTION 429 "The number of seconds between two action invocations of 430 a periodic scheduler. Implementations must guarantee 431 that action invocations will not occur before at least 432 schedInterval seconds have passed. 434 The scheduler must ignore all periodic schedules that 435 have a schedInterval value of 0. A periodic schedule 436 with a scheduling interval of 0 seconds will therefore 437 never invoke an action. 439 Implementations may be forced to delay invocations in the 440 face of local constraints. A scheduled management function 441 should therefore not rely on the accuracy provided by the 442 scheduler implementation." 443 DEFVAL { 0 } 444 ::= { schedEntry 4 } 446 schedWeekDay OBJECT-TYPE 447 SYNTAX BITS { 448 sunday(0), 449 monday(1), 450 tuesday(2), 451 wednesday(3), 452 thursday(4), 453 friday(5), 454 saturday(6) 455 } 456 MAX-ACCESS read-create 457 STATUS current 458 DESCRIPTION 459 "The set of weekdays on which the scheduled action should 460 take place. Setting multiple bits will include several 461 weekdays in the set of possible weekdays for this schedule. 462 Setting all bits will cause the scheduler to ignore the 463 weekday." 464 DEFVAL { {} } 465 ::= { schedEntry 5 } 467 schedMonth OBJECT-TYPE 468 SYNTAX BITS { 469 january(0), 470 february(1), 471 march(2), 472 april(3), 473 may(4), 474 june(5), 475 july(6), 476 august(7), 477 september(8), 478 october(9), 479 november(10), 480 december(11) 481 } 482 MAX-ACCESS read-create 483 STATUS current 484 DESCRIPTION 485 "The set of months during which the scheduled action should 486 take place. Setting multiple bits will include several 487 months in the set of possible months for this schedule. 488 Setting all bits will cause the scheduler to ignore the 489 month." 490 DEFVAL { {} } 491 ::= { schedEntry 6 } 493 schedDay OBJECT-TYPE 494 SYNTAX BITS { 495 d1(0), d2(1), d3(2), d4(3), d5(4), 496 d6(5), d7(6), d8(7), d9(8), d10(9), 497 d11(10), d12(11), d13(12), d14(13), d15(14), 498 d16(15), d17(16), d18(17), d19(18), d20(19), 499 d21(20), d22(21), d23(22), d24(23), d25(24), 500 d26(25), d27(26), d28(27), d29(28), d30(29), 501 d31(30), 502 r1(31), r2(32), r3(33), r4(34), r5(35), 503 r6(36), r7(37), r8(38), r9(39), r10(40), 504 r11(41), r12(42), r13(43), r14(44), r15(45), 505 r16(46), r17(47), r18(48), r19(49), r20(50), 506 r21(51), r22(52), r23(53), r24(54), r25(55), 507 r26(56), r27(57), r28(58), r29(59), r30(60), 508 r31(61) 509 } 510 MAX-ACCESS read-create 511 STATUS current 512 DESCRIPTION 513 "The set of days in a month on which a scheduled action 514 should take place. There are two sets of bits one can 515 use to define the day within a month: 517 Enumerations starting with the letter 'd' indicate a 518 day in a month relative to the first day of a month. 519 The first day of the month can therefore be specified 520 by setting the bit d1(0) and d31(30) means the last 521 day of a month with 31 days. 523 Enumerations starting with the letter 'r' indicate a 524 day in a month in reverse order, relative to the last 525 day of a month. The last day in the month can therefore 526 be specified by setting the bit r1(31) and r31(61) means 527 the first day of a month with 31 days. 529 Setting multiple bits will include several days in the set 530 of possible days for this schedule. Setting all bits will 531 cause the scheduler to ignore the day within a month. 532 Setting all bits starting with the letter 'd' or the 533 letter 'r' will also cause the scheduler to ignore the 534 day within a month." 535 DEFVAL { {} } 536 ::= { schedEntry 7 } 538 schedHour OBJECT-TYPE 539 SYNTAX BITS { 540 h0(0), h1(1), h2(2), h3(3), h4(4), 541 h5(5), h6(6), h7(7), h8(8), h9(9), 542 h10(10), h11(11), h12(12), h13(13), h14(14), 543 h15(15), h16(16), h17(17), h18(18), h19(19), 544 h20(20), h21(21), h22(22), h23(23) 545 } 546 MAX-ACCESS read-create 547 STATUS current 548 DESCRIPTION 549 "The set of hours within a day during which the scheduled 550 action should take place." 551 DEFVAL { {} } 552 ::= { schedEntry 8 } 554 schedMinute OBJECT-TYPE 555 SYNTAX BITS { 556 m0(0), m1(1), m2(2), m3(3), m4(4), 557 m5(5), m6(6), m7(7), m8(8), m9(9), 558 m10(10), m11(11), m12(12), m13(13), m14(14), 559 m15(15), m16(16), m17(17), m18(18), m19(19), 560 m20(20), m21(21), m22(22), m23(23), m24(24), 561 m25(25), m26(26), m27(27), m28(28), m29(29), 562 m30(30), m31(31), m32(32), m33(33), m34(34), 563 m35(35), m36(36), m37(37), m38(38), m39(39), 564 m40(40), m41(41), m42(42), m43(43), m44(44), 565 m45(45), m46(46), m47(47), m48(48), m49(49), 566 m50(50), m51(51), m52(52), m53(53), m54(54), 567 m55(55), m56(56), m57(57), m58(58), m59(59) 568 } 569 MAX-ACCESS read-create 570 STATUS current 571 DESCRIPTION 572 "The set of minutes within an hour when the scheduled action 573 should take place." 574 DEFVAL { {} } 575 ::= { schedEntry 9 } 577 schedContextName OBJECT-TYPE 578 SYNTAX SnmpAdminString (SIZE(0..32)) 579 MAX-ACCESS read-create 580 STATUS current 581 DESCRIPTION 582 "The context which contains the local MIB variable pointed 583 to by schedVariable." 584 ::= { schedEntry 10 } 586 schedVariable OBJECT-TYPE 587 SYNTAX VariablePointer 588 MAX-ACCESS read-create 589 STATUS current 590 DESCRIPTION 591 "An object identifier pointing to a local MIB variable 592 which resolves to an ASN.1 primitive type of INTEGER." 593 ::= { schedEntry 11 } 595 schedValue OBJECT-TYPE 596 SYNTAX Integer32 597 MAX-ACCESS read-create 598 STATUS current 599 DESCRIPTION 600 "The value which is written to the MIB object pointed to by 601 schedVariable when the scheduler invokes an action. The 602 implementation shall enforce the use of access control 603 rules when performing the set operation on schedVariable. 604 This is accomplished by calling the isAccessAllowed abstract 605 service interface as defined in RFC 2271." 606 ::= { schedEntry 12 } 608 schedType OBJECT-TYPE 609 SYNTAX INTEGER { 610 periodic(1), 611 calendar(2), 612 oneshot(3) 613 } 614 MAX-ACCESS read-create 615 STATUS current 616 DESCRIPTION 617 "The type of this schedule. The value periodic(1) indicates 618 that this entry specifies a periodic schedule. A periodic 619 schedule is defined by the value of schedInterval. The values 620 of schedWeekDay, schedMonth, schedDay, schedHour and 621 schedMinute are ignored. 623 The value calendar(2) indicates that this entry describes a 624 calendar schedule. A calendar schedule is defined by the 625 values of schedWeekDay, schedMonth, schedDay, schedHour and 626 schedMinute. The value of schedInterval is ignored. A 627 calendar schedule will trigger on all local times that 628 satisfy the bits set in schedWeekDay, schedMonth, schedDay, 629 schedHour and schedMinute. 631 The value oneshot(3) indicates that this entry describes a 632 one-shot schedule. A one-shot schedule is similar to a calendar 633 schedule with the additional feature that it disables itself 634 by changing in the `finished' schedOperStatus once the 635 schedule triggers an action. 637 Changing a schedule's type is equivalent to deleting the 638 old-type schedule and creating a new-type one." 639 DEFVAL { periodic } 640 ::= { schedEntry 13 } 642 schedAdminStatus OBJECT-TYPE 643 SYNTAX INTEGER { 644 enabled(1), 645 disabled(2) 646 } 647 MAX-ACCESS read-create 648 STATUS current 649 DESCRIPTION 650 "The desired state of the schedule." 651 DEFVAL { disabled } 652 ::= { schedEntry 14 } 654 schedOperStatus OBJECT-TYPE 655 SYNTAX INTEGER { 656 enabled(1), 657 disabled(2), 658 finished(3) 659 } 660 MAX-ACCESS read-only 661 STATUS current 662 DESCRIPTION 663 "The current operational state of this schedule. The state 664 enabled(1) indicates this entry is active and that the 665 scheduler will invoke actions at appropriate times. The 666 disabled(2) state indicates that this entry is currently 667 inactive and ignored by the scheduler. The finished(3) 668 state indicates that the schedule has ended. Schedules 669 in the finished(3) state are ignored by the scheduler. 670 A one-shot schedule enters the finished(3) state when it 671 deactivates itself." 672 ::= { schedEntry 15 } 674 schedFailures OBJECT-TYPE 675 SYNTAX Counter32 676 MAX-ACCESS read-only 677 STATUS current 678 DESCRIPTION 679 "This variable counts the number of failures while invoking 680 the scheduled action." 681 ::= { schedEntry 16 } 683 schedLastFailure OBJECT-TYPE 684 SYNTAX SnmpPduErrorStatus 685 MAX-ACCESS read-only 686 STATUS current 687 DESCRIPTION 688 "The most recent error that occured during the invocation of 689 a scheduled action. The value noError(0) is returned 690 if no errors have occurred yet." 691 DEFVAL { noError } 692 ::= { schedEntry 17 } 694 schedLastFailed OBJECT-TYPE 695 SYNTAX DateAndTime 696 MAX-ACCESS read-only 697 STATUS current 698 DESCRIPTION 699 "The date and time when the most recent failure occured. The 700 value '0000000000000000'H is returned if no failure occured 701 since the last re-initialization of the scheduler." 702 DEFVAL { '0000000000000000'H } 703 ::= { schedEntry 18 } 705 schedStorageType OBJECT-TYPE 706 SYNTAX StorageType 707 MAX-ACCESS read-create 708 STATUS current 709 DESCRIPTION 710 "This object defines whether this scheduled action is kept in 711 volatile storage and lost upon reboot or if this row is 712 backed up by non-volatile or permanent storage. 714 Conceptual rows having the value `permanent' must allow 715 write access to the columnar objects schedDescr, 716 schedInterval, schedContextName, schedVariable, schedValue, 717 and schedAdminStatus. If an implementation supports the 718 schedCalendarGroup, write access must be also allowed to 719 the columnar objects schedWeekDay, schedMonth, schedDay, 720 schedHour, schedMinute." 721 DEFVAL { volatile } 722 ::= { schedEntry 19 } 724 schedRowStatus OBJECT-TYPE 725 SYNTAX RowStatus 726 MAX-ACCESS read-create 727 STATUS current 728 DESCRIPTION 729 "The status of this scheduled action. A control that allows 730 entries to be added and removed from this table. 732 The miminum number of objects that need to be set during 733 row creation before a row can be set to `active' are 734 schedContextName, schedVariable and schedValue." 735 ::= { schedEntry 20 } 737 -- 738 -- Notifications that are emitted to indicate failures. The definition 739 -- of schedTraps makes notification registrations reversible (see 740 -- section 8.3 in RFC 1902). 741 -- 743 schedTraps OBJECT IDENTIFIER ::= { schedNotifications 0 } 745 schedActionFailure NOTIFICATION-TYPE 746 OBJECTS { schedLastFailure, schedLastFailed } 747 STATUS current 748 DESCRIPTION 749 "This notification is generated whenever the invocation of a 750 scheduled action fails." 751 ::= { schedTraps 1 } 753 -- conformance information 755 schedCompliances OBJECT IDENTIFIER ::= { schedConformance 1 } 756 schedGroups OBJECT IDENTIFIER ::= { schedConformance 2 } 758 -- compliance statements 760 schedCompliance MODULE-COMPLIANCE 761 STATUS current 762 DESCRIPTION 763 "The compliance statement for SNMP entities which implement 764 the scheduling MIB." 765 MODULE -- this module 766 MANDATORY-GROUPS { 767 schedGroup, schedNotificationsGroup 768 } 769 GROUP schedCalendarGroup 770 DESCRIPTION 771 "The schedCalendarGroup is mandatory only for those 772 implementations that support calendar based schedules." 773 OBJECT schedType 774 DESCRIPTION 775 "The values calendar(2) or oneshot(3) are not valid for 776 implementations that do not implement the 777 schedCalendarGroup. Such an implementation must return 778 inconsistentValue error responses for attempts to set 779 schedAdminStatus to calendar(2) or oneshot(3)." 780 ::= { schedCompliances 1 } 782 schedGroup OBJECT-GROUP 783 OBJECTS { 784 schedDescr, 785 schedInterval, 786 schedContextName, 787 schedVariable, 788 schedValue, 789 schedType, 790 schedAdminStatus, 791 schedOperStatus, 792 schedFailures, 793 schedLastFailure, 794 schedLastFailed, 795 schedStorageType, 796 schedRowStatus 797 } 798 STATUS current 799 DESCRIPTION 800 "A collection of objects providing scheduling capabilities." 801 ::= { schedGroups 1 } 803 schedCalendarGroup OBJECT-GROUP 804 OBJECTS { 805 schedLocalTime, 806 schedWeekDay, 807 schedMonth, 808 schedDay, 809 schedHour, 810 schedMinute 811 } 812 STATUS current 813 DESCRIPTION 814 "A collection of objects providing calendar based schedules." 815 ::= { schedGroups 2 } 817 schedNotificationsGroup NOTIFICATION-GROUP 818 NOTIFICATIONS { 819 schedActionFailure 820 } 821 STATUS current 822 DESCRIPTION 823 "The notifications emitted by the scheduler." 824 ::= { schedGroups 3 } 826 END 828 5. Usage Examples 830 This section presents some examples how the scheduling MIB can be 831 used to schedule scripts with the Script MIB [17] or to realize on- 832 duty/off-duty schedules by modifying status objects of other MIB 833 modules. 835 5.1. Starting a script to ping devices every 20 minutes 837 It is assumed that the schedule entry is owned by schedOwner = "joe" 838 and its name is schedName = "ping". The instance identifier for the 839 scheduling entry is therefore 3.106.111.101.4.112.105.110.103. 841 It is further assumed that the smLaunchTable entry is owned by 842 smLaunchOwner = "joe" and its name is smLaunchName = "ping-devs". The 843 complete object identifier for the smLaunchStart object is therefore 844 smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115. The 845 script lives in the context identified by the string "engine1". 847 The configuration of the scheduler entry which launches the script 848 every 20 minutes would look as follows: 850 schedInterval.3.106.111.101.4.112.105.110.103 = 1200 852 schedValue.3.106.111.101.4.112.105.110.103 = 0 853 schedContextName.3.106.111.101.4.112.105.110.103 = "engine1" 854 schedVariable.3.106.111.101.4.112.105.110.103 = 855 smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115 857 schedType.3.106.111.101.4.112.105.110.103 = periodic(1) 858 schedAdminStatus.3.106.111.101.4.112.105.110.103 = enabled(1) 859 schedStorageType.3.106.111.101.4.112.105.110.103 = nonVolatile(3) 860 schedRowStatus.3.106.111.101.4.112.105.110.103 = active(1) 862 All the remaining columns in the schedTable represent status 863 information and are not shown here. 865 5.2. Starting a script at the next Friday the 13th 867 It is assumed that the schedule entry is owned by schedOwner = "joe" 868 and its name is schedName = "13th". The instance identifier for the 869 scheduling entry is therefore 3.106.111.101.4.49.51.116.104. 871 It is further assumed that the smLaunchTable entry is owned by 872 smLaunchOwner = "joe" and its name is smLaunchName = "ghost". The 873 complete object identifier for the smLaunchStart object is therefore 874 smLaunchStart.3.106.111.101.5.103.104.111.115.116. The script lives 875 in the context identified by the string "engine1". 877 The configuration of the scheduler entry which launches the script on 878 every Friday 13th at midnight would look as follows: 880 schedWeekDay.3.106.111.101.4.49.51.116.104 = { friday } 881 schedMonth.3.106.111.101.4.49.51.116.104 = { 882 january, february, march, april, may, june, 883 july, august, september, october, november, december 884 } 885 schedDay.3.106.111.101.4.49.51.116.104 = { d13 } 886 schedHour.3.106.111.101.4.49.51.116.104 = { h0 } 887 schedMinute.3.106.111.101.4.49.51.116.104 = { m0 } 889 schedValue.3.106.111.101.4.49.51.116.104 = 0 890 schedContextName.3.106.111.101.4.49.51.116.104 = "engine1" 891 schedVariable.3.106.111.101.4.49.51.116.104 = 892 smLaunchStart.3.106.111.101.5.103.104.111.115.116 894 schedType.3.106.111.101.4.49.51.116.104 = oneshot(3) 895 schedAdminStatus.3.106.111.101.4.49.51.116.104 = enabled(2) 896 schedStorageType.3.106.111.101.4.49.51.116.104 = nonVolatile(3) 897 schedRowStatus.3.106.111.101.4.49.51.116.104 = active(1) 899 All the remaining columns in the schedTable represent status 900 information and are not shown here. 902 5.3. Turning an interface off during weekends 904 This example assumes that a network interface should be taken down 905 during weekends. The interface table (ifTable) of the IF-MIB [18] is 906 assumed to exist in the context identified by an empty string and the 907 index of the interface is ifIndex = 6. 909 The scheduling entry which brings the interface down on every Friday 910 evening at 20:30 (8:30 pm) is owned by schedOwner = "bob" and its 911 name is schedName = "if-off". The instance identifier for the 912 scheduling entry is therefore 3.98.111.98.6.105.102.45.111.102.102. 914 schedWeekDay.3.98.111.98.6.105.102.45.111.102.102 = { friday } 915 schedMonth.3.98.111.98.6.105.102.45.111.102.102 = { 916 january, february, march, april, may, june, 917 july, august, september, october, november, december 918 } 919 schedDay.3.98.111.98.6.105.102.45.111.102.102 = { 920 d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, 921 d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, 922 d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31 923 } 924 schedHour.3.98.111.98.6.105.102.45.111.102.102 = { h20 } 925 schedMinute.3.98.111.98.6.105.102.45.111.102.102 = { m30 } 927 schedValue.3.98.111.98.6.105.102.45.111.102.102 = down(2) 928 schedContextName.3.98.111.98.6.105.102.45.111.102.102 = "" 929 schedVariable.3.98.111.98.6.105.102.45.111.102.102 = 930 ifAdminStatus.6 932 schedType.3.98.111.98.6.105.102.45.111.102.102 = calendar(2) 933 schedAdminStatus.3.98.111.98.6.105.102.45.111.102.102 = enabled(1) 934 schedStorageType.3.98.111.98.6.105.102.45.111.102.102 = 935 nonVolatile(3) 936 schedRowStatus.3.98.111.98.6.105.102.45.111.102.102 = active(1) 938 The scheduling entry which brings the interface up on every Monday 939 morning at 5:30 is owned by schedOwner = "bob" and its name is 940 schedName = "if-on". The instance identifier for the scheduling entry 941 is therefore 3.98.111.98.5.105.102.45.111.110. 943 The entry in the schedTable which brings the interface up again on 944 every Monday morning at 5:30 looks as follows: 946 schedWeekDay.3.98.111.98.5.105.102.45.111.110 = { monday } 947 schedMonth.3.98.111.98.5.105.102.45.111.110 = { 948 january, february, march, april, may, june, 949 july, august, september, october, november, december 950 } 951 schedDay.3.98.111.98.5.105.102.45.111.110 = { 952 d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, 953 d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, 954 d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31 955 } 956 schedHour.3.98.111.98.5.105.102.45.111.110 = { h5 } 957 schedMinute.3.98.111.98.5.105.102.45.111.110 = { m30 } 959 schedValue.3.98.111.98.5.105.102.45.111.110 = up(1) 960 schedContextName.3.98.111.98.5.105.102.45.111.110 = "" 961 schedVariable.3.98.111.98.5.105.102.45.111.110 = ifAdminStatus.6 963 schedType.3.98.111.98.5.105.102.45.111.110 = calendar(2) 964 schedAdminStatus.3.98.111.98.5.105.102.45.111.110 = enabled(1) 965 schedStorageType.3.98.111.98.5.105.102.45.111.110 = nonVolatile(3) 966 schedRowStatus.3.98.111.98.5.105.102.45.111.110 = active(1) 968 A similar configuration could be used to control other schedules. For 969 example, one could change the "if-on" and "if-off" schedules to 970 enable and disable the periodic scheduler defined in the first 971 example. 973 6. Security Considerations 975 Scheduled SNMP set operations must use the security credentials that 976 were present when the corresponding row in the scheduling entry was 977 created. An implementation must therefore record and maintain the 978 credentials for every scheduling entry. 980 An implementation must ensure that access control rules are applied 981 when doing the set operation. This is accomplished by calling the 982 isAccessAllowed abstract service interface defined in RFC 2271 [1]: 984 statusInformation = -- success or errorIndication 985 isAccessAllowed( 986 IN securityModel -- Security Model in use 987 IN securityName -- principal who wants to access 988 IN securityLevel -- Level of Security 989 IN viewType -- read, write, or notify view 990 IN contextName -- context containing variableName 991 IN variableName -- OID for the managed object 992 ) 994 The securityModel, securityName and securityLevel parameters are set 995 to the values that were recorded when the scheduling entry was 996 created. The viewType parameter must select the write view and the 997 contextName and variableName parameters are taken from the 998 schedContextName and schedVariableName values of the scheduling 999 entry. 1001 This MIB limits scheduled actions to objects in the local MIB. This 1002 avoids security problems with the delegation of access rights. 1003 However, it might be possible for a user of this MIB to own some 1004 schedules that might trigger far in the future. This can cause 1005 security risks if the security administrator did not properly update 1006 the access control lists when a user is withdrawn from an SNMP 1007 engine. Therefore, entries in the schedTable SHOULD be cleaned up 1008 whenever a user is removed from an SNMP engine. 1010 To facilitate the provisioning of access control by a security 1011 administrator using the View-Based Access Control Model (VACM) 1012 defined in RFC 2275 [15] for tables in which multiple users may need 1013 to independently create or modify entries, the initial index is used 1014 as an "owner index". Such an initial index has a syntax of 1015 SnmpAdminString, and can thus be trivially mapped to a securityName 1016 or groupName as defined in VACM, in accordance with a security 1017 policy. 1019 All entries in related tables belonging to a particular user will 1020 have the same value for this initial index. For a given user's 1021 entries in a particular table, the object identifiers for the 1022 information in these entries will have the same subidentifiers 1023 (except for the "column" subidentifier) up to the end of the encoded 1024 owner index. To configure VACM to permit access to this portion of 1025 the table, one would create vacmViewTreeFamilyTable entries with the 1026 value of vacmViewTreeFamilySubtree including the owner index portion, 1027 and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. 1028 More elaborate configurations are possible. 1030 7. Intellectual Property 1032 The IETF takes no position regarding the validity or scope of any 1033 intellectual property or other rights that might be claimed to 1034 pertain to the implementation or use of the technology described in 1035 this document or the extent to which any license under such rights 1036 might or might not be available; neither does it represent that it 1037 has made any effort to identify any such rights. Information on the 1038 IETF's procedures with respect to rights in standards-track and 1039 standards-related documentation can be found in BCP-11. Copies of 1040 claims of rights made available for publication and any assurances of 1041 licenses to be made available, or the result of an attempt made to 1042 obtain a general license or permission for the use of such 1043 proprietary rights by implementors or users of this specification can 1044 be obtained from the IETF Secretariat. 1046 The IETF invites any interested party to bring to its attention any 1047 copyrights, patents or patent applications, or other proprietary 1048 rights which may cover technology that may be required to practice 1049 this standard. Please address the information to the IETF Executive 1050 Director. 1052 8. Acknowledgments 1054 This document was produced by the IETF Distributed Management 1055 (DISMAN) working group. 1057 9. References 1059 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1060 Describing SNMP Management Frameworks", RFC 2271, Cabletron 1061 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 1062 January 1998 1064 [2] Rose, M., and K. McCloghrie, "Structure and Identification of 1065 Management Information for TCP/IP-based Internets", RFC 1155, 1066 Performance Systems International, Hughes LAN Systems, May 1990 1068 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 1069 Performance Systems International, Hughes LAN Systems, March 1991 1071 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", 1072 RFC 1215, Performance Systems International, March 1991 1074 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1075 of Management Information for Version 2 of the Simple Network 1076 Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco 1077 Systems, Inc., Dover Beach Consulting, Inc., International Network 1078 Services, January 1996. 1080 [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 1081 Conventions for Version 2 of the Simple Network Management Protocol 1082 (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., 1083 Dover Beach Consulting, Inc., International Network Services, 1084 January 1996. 1086 [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 1087 Statements for Version 2 of the Simple Network Management Protocol 1088 (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., 1089 Dover Beach Consulting, Inc., International Network Services, 1090 January 1996. 1092 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1093 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1094 International, Performance Systems International, MIT Laboratory 1095 for Computer Science, May 1990. 1097 [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1098 "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, 1099 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1100 International Network Services, January 1996. 1102 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 1103 Mappings for Version 2 of the Simple Network Management Protocol 1104 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., 1105 Dover Beach Consulting, Inc., International Network Services, 1106 January 1996. 1108 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1109 Processing and Dispatching for the Simple Network Management 1110 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 1111 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 1113 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 1114 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 1115 2274, IBM T. J. Watson Research, January 1998. 1117 [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1118 Operations for Version 2 of the Simple Network Management Protocol 1119 (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., 1120 Dover Beach Consulting, Inc., International Network Services, 1121 January 1996. 1123 [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1124 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco 1125 Systems, January 1998 1127 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1128 Control Model (VACM) for the Simple Network Management Protocol 1129 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 1130 Cisco Systems, Inc., January 1998 1132 [16] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 1133 Standards Process", BCP 11, RFC 2028, October 1996. 1135 [17] Levi, D., and J. Schoenwaelder, "Definitions of Managed Objects for 1136 the Delegation of Management Scripts", Internet-Draft , SNMP Research, Inc., TU Braunschweig, 1138 November 1998. 1140 [18] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB using 1141 SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997. 1143 [19] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1144 Levels", BCP 14, RFC 2119, Harvard University, March 1997. 1146 10. Editors' Addresses 1148 David B. Levi Email: levi@snmp.com 1149 SNMP Research, Inc. Tel: +1 423 573 1434 1150 3001 Kimberlin Heights Road 1151 Knoxville, TN 37920-9716 1152 U.S.A. 1154 Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de 1155 TU Braunschweig Tel: +49 531 391-3283 1156 Bueltenweg 74/75 1157 38106 Braunschweig 1158 Germany 1160 11. Full Copyright Statement 1162 Copyright (C) The Internet Society (1998). All Rights Reserved. 1164 This document and translations of it may be copied and furnished to 1165 others, and derivative works that comment on or otherwise explain it 1166 or assist in its implementation may be prepared, copied, published 1167 and distributed, in whole or in part, without restriction of any 1168 kind, provided that the above copyright notice and this paragraph are 1169 included on all such copies and derivative works. However, this 1170 document itself may not be modified in any way, such as by removing 1171 the copyright notice or references to the Internet Society or other 1172 Internet organizations, except as needed for the purpose of 1173 developing Internet standards in which case the procedures for 1174 copyrights defined in the Internet Standards process must be 1175 followed, or as required to translate it into languages other than 1176 English. 1178 The limited permissions granted above are perpetual and will not be 1179 revoked by the Internet Society or its successors or assigns. 1181 This document and the information contained herein is provided on an 1182 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1183 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1184 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1185 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1186 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.