idnits 2.17.1 draft-ietf-policy-conditions-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 8 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([3], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 461 has weird spacing: '...ecified inter...' == Line 502 has weird spacing: '...ich the polic...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-policy-core-schema-01 -- No information found for draft-ietf-ipsec-doi - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Authors: 2 INTERNET DRAFT R. Rajan, S. Kamat 3 IBM 4 P. Bhattacharya 5 Cisco 6 26/February/1999 8 Networking Policy Condition Information Model 9 draft-ietf-policy-conditions-00.txt 11 Status of Memo 13 This document is an Internet-Draft and is in full 14 conformance with all the provisions of Section 10 of RFC2026 15 except for the right to produce derivative works. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet- Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be 32 accessed at http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (1999). All Rights Reserved. 38 Abstract 40 This document defines an information model for 41 networking policy conditions as part of the general 42 information model for representing networking policy 43 defined in draft-ietf-policy-core-schema-02.txt. The 44 information model described in this document is focussed 45 on the structural class networkingPolicyCondition 46 that extends the class policyCondition described 47 draft-ietf-policy-core-schema-02.txt. Five auxiliary 48 classes are defined to describe conditions that refer to 49 (1) the communicating hosts, (2) the communicating users 50 (3) application data (4) routing information at the device 51 enforcing the policy and (5) layer 2 or data link layer 52 information of the device. This document is based on the 53 QoS and IPSec schema first described in [3] and [4]. 55 1. Introduction 57 This document extends the Policy Framework Core Information 58 Model Class Hierarchy (PFCIM)[1] which presents a schema for 59 representing networking policies. The schema contains five core 60 classes: policyGroup, policyRule, policyCondtion, policyAction, and 61 policyValidityPeriodCondition. The classes comprising the PFCIM 62 are intended to serve as an extensible class hierarchy (through 63 specialization) for defining policy objects that enable application 64 developers, network administrators, and policy administrators to 65 represent policies of different types. Please refer to [1] for 66 details on the classes and their relationships to one another. 67 Policy conditions are meant to represent criteria that administrators 68 use in enforcing control over behavior of devices or users in a 69 network. This document is NOT concerned with all possible conditions 70 that may arise with respect to computing and communication devices. 71 It is particularly targeted at the needs of controlling resource 72 usage and securing communication between users in an IP network. 73 As mandated by the policy working group, the ability to represent 74 policy requirements of integrated services with RSVP, differentiated 75 services and IPSec are the first targets of this effort. 77 In keeping with the focus of this effort, we identify 5 78 conditional categories that are commonly used by administrators 79 in controlling access to network resources and services. These 80 are host, user, application and routing and layer 2 or data 81 link layer information. We extend the class policyCondition to 82 the subclass networkingPolicyCondition, and define 5 auxiliary 83 classes: hostConditionAuxClass, userConditionAuxClass, 84 applicationConditionAuxClass, routeConditionAuxClass and 85 layer2ConditionAuxclass. The auxiliary classes may be attached to 86 networkingPolicyCondition in order to create fully formed conditional 87 statements that are appropriately structured for the purpose at hand. 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119, reference 92 [5]. 94 2. Extending policyCondition 96 2.1. The Class Hierarchy 98 As defined in [1] the class policyCondition inherits from the 99 class top. We extend the class policyCondition to the subclass 100 netwokingPolicyCondition. The class netwokingPolicyCondition has 5 101 auxiliary classes: hostConditionAuxClass, userConditionAuxClass, 102 applicationConditionAuxClass, routeConditionAuxClass and 103 layer2ConditionAuxclass. 105 top 106 | 107 | 108 |----policyCondition 109 | | 110 | networkingPolicyCondition ~~~~~ 111 | |(auxiliary classes) 112 |-----------------hostConditionAuxClass 113 |---------------- userConditionAuxClass 114 |-----------------applicationConditionAuxClass 115 |-----------------routeConditionAuxClass 116 |-----------------layer2ConditionAuxClass 118 2.2. Class Definitions 120 The class definition of policyCondition, repeated from [1] is as 121 follows: 123 NAME policyCondition 124 DESCRIPTION A class representing a condition to be evaluated 125 in conjunction with a policy rule. 126 DERIVED FROM top 127 TYPE structural 128 AUXILIARY CLASSES none 129 POSSIBLE SUPERIORS policyRule 130 OID 131 MUST cn 132 PolicyConditionName 133 MAY 135 The class policyCondition is specialized to networkingPolicyCondition 136 for extensibility. The class definition is as follows: 138 NAME networkingPolicyCondition 139 DESCRIPTION A class representing a networking condition to be 140 evaluated in conjunction with a policy rule. 141 DERIVED FROM policyCondition 142 TYPE structural 143 AUXILIARY CLASSES hostConditionAuxClass 144 userConditionAuxClass 145 applicationConditionAuxClass 146 routeConditionAuxClass 147 layer2ConditionAuxClass 148 POSSIBLE SUPERIORS policyRule 149 OID 150 MUST 151 MAY 153 The following auxiliary classes are used to append attributes to the 154 class networkingPolicyCondition. 156 NAME hostConditionAuxClass 157 DESCRIPTION An auxiliary class representing a condition to be 158 evaluated in conjunction with a policy rule. The 159 condition is based on the communicating end hosts. 160 DERIVED FROM top 161 TYPE auxiliary 162 AUXILIARY CLASSES none 163 POSSIBLE SUPERIORS networkingPolicyCondition 164 OID 165 MUST 166 MAY sourceIPAddressRange 167 destinationIPAddressRange 168 sourceHostID 169 destinationHostID 171 NAME userConditionAuxClass 172 DESCRIPTION An auxiliary class representing a condition to be 173 evaluated in conjunction with a policy rule. The 174 condition is based on the communicating users. 175 DERIVED FROM top 176 TYPE auxiliary 177 AUXILIARY CLASSES none 178 POSSIBLE SUPERIORS networkingPolicyCondition 179 OID 180 MUST 181 MAY senderID 182 receiverID 184 NAME applicationConditionAuxClass 185 DESCRIPTION An auxiliary class representing a condition to be 186 evaluated in conjunction with a policy rule. The 187 condition is based on the nature of traffic, the 188 transport layer in use and the application. 189 DERIVED FROM top 190 TYPE auxiliary 191 AUXILIARY CLASSES none 192 POSSIBLE SUPERIORS networkingPolicyCondition 193 OID 194 MUST 195 MAY applicationName 196 sourcePortRange, 197 destinationPortRange, 198 protocolNumberRange, 199 receivedTOSByteCheck 201 NAME routeConditionAuxClass 202 DESCRIPTION An auxiliary class representing a condition to be 203 evaluated in conjunction with a policy rule. The 204 condition is based on the routing of the packet 205 through a device e.g. incoming and outgoing 206 interfaces. 207 DERIVED FROM top 208 TYPE auxiliary 209 AUXILIARY CLASSES none 210 POSSIBLE SUPERIORS networkingPolicyCondition 211 OID 212 MUST 213 MAY interface 215 NAME layer2ConditionAuxClass 216 DESCRIPTION An auxiliary class representing a condition to be 217 evaluated in conjunction with a policy rule. The 218 condition is based on the nature of traffic, the 219 transport layer in use and the application 220 generating data. 221 DERIVED FROM top 222 TYPE auxiliary 223 AUXILIARY CLASSES none 224 POSSIBLE SUPERIORS networkingPolicyCondition 225 OID 226 MUST 227 MAY sourceMACAddress 228 destinationMACAddress 229 802.1QVLANId 230 SNAPHeaderValue 231 etherTypeValue 232 DSAP 233 SSAP 234 encapsulationType 235 encapsualtionValue 237 2.3. Rationale behind the class structure 239 There are two design choices that we need to justify in the manner 240 of extending policyCondition. First, the decision to choose 241 particular condition categories and the second the choice of class 242 structures, especially the use of auxiliary classes. The three 243 categories - users, hosts and applications - are very natural to 244 administrative decision making. The need to define policies in terms 245 of a dynamic category such as routing requires some explanation, 246 however. Consider, for instance, a corporation that has its 247 campuses connected by a leased line infrastructure with a backup 248 connection over the internet. When the primary network is down, it 249 is prudent policy to require that inter-campus traffic be encrypted. 250 There are many ways to enforce this, for instance instruct access 251 routers to encrypt traffic based on the destination as well as the 252 outgoing interface. Similar examples may be considered for QoS as 253 well, where a high grade reservation is made over a primary ISP 254 backbone, with a lower grade backup reservation triggered by routing 255 changes. A number of different class hierarchies are feasible 256 even when we have determined the categories we wish to represent, 257 and their attributes. For instance, one choice would have been to 258 associate all the attributes of users, applications, hosts, etc, 259 to the class policyCondition. Why subclass at all? The answer 260 is extensibility. Suppose the same information model is used to 261 represent policy conditions for DHCP. While we would like to have 262 host attributes to express this condition, layer 2 attributes may 263 be totally irrelevant. The subclass networkingPolicyCondition 264 allows us to group all the conditions required for the purpose of 265 expressing networking policy without requiring that all extensions 266 have the same condition attributes. Now the design choice that 267 comes directly from the above is to associate all attributes we 268 want - those of users, hosts, applications, etc - all the class 269 networkingPolicyCondition (as optional attributes, say). Will this 270 not have the same result as the structure presented above? The issue 271 again is extensibility. If one vendor desires to extend the category 272 application, a second only wants to represent users in greater 273 depth, and a third wants to do both, then they dont have to extend 274 networkingPolicyCondition in slightly different ways. Further, 275 the auxiliary classes hostPolicyAuxClass, etc, may be associated 276 with other subclasses of policyCondition, DHCPpolicyCondition for 277 instance, in a selective manner. Finally, the advantage of auxiliary 278 classes is that they allow us to mix and match attributes creating 279 fewer objects, when compared to subclasses. 281 3. Attributes of HostConditionAuxClass 283 NAME sourceIPAddressRange 284 DESC Source IP addresses to which the policy applies 285 SYNTAX IA5String 286 EQUALITY caseExactIA5Match 287 MULTI-VALUED 288 FORMAT sourceIPAddressRange may be described in any of the 289 following formats. 290 1 The string ``1'' 291 Indicates policy applies to locally generated packets. 293 2-- 294 Three dash (-) seperated strings. The IP-v4 295 address is in dotted decimal format. The 296 CIDRPrefixLength is the number of unmasked leading 297 bits. A packet matches the condition if the 298 unmasked bits on the packet are identical to the 299 unmasked bits on the condition. 301 3-- 302 IP-v4 addresses in dotted decimal format. The 303 second address must be no smaller than the first. 304 The first denotes the start of the range, and the 305 second denotes the end of the range. A packet 306 matches the condition if its source address is no 307 smaller than the first IP address in the 308 condition, and no larger than the second. 310 4-- 311 IP-v6 addresses in any of the formats supported in 312 RFC 2373. The second address must be no smaller 313 than the first. The first denotes the start of the 314 range, and the second denotes the end of the 315 range. A packet matches the condition if its 316 source address is no smaller than the first 317 address in the condition, and no larger than the 318 second. 320 DEFAULT Defaults to the entire address range, i.e., every 321 packet matches the source address range condition. 322 EXAMPLES 2-83.23.23.1-24 323 A packet with source address 83.23.23.5 matches. 324 A packet with source address 83.23.24.1 does not. 326 3-83.23.23.0-83.28.28.0 327 A packet with source address 83.23.23.5 matches. 328 A packet with source address 83.29.24.1 does not. 330 NAME destinationIPAddressRange 331 DESC destination IP addresses to which policy applies 332 SYNTAX IA5String 333 EQUALITY caseExactIA5Match 334 MULTI-VALUED 335 FORMAT Identical to that of sourceIPAddressRange above. 336 The value of ``1''indicates a locally destined 337 packet. 338 DEFAULT Defaults to the entire address range, i.e., every 339 packet matches the destination address range 340 condition. 342 NAME sourceHostID 343 DESC Source Host Identifier 344 SYNTAX IA5String 345 EQUALITY caseExact1A5Match 346 MULTI-VALUED 347 FORMAT Two strings, colon (`:) seperated, the first 348 describing the ID type and the second the ID 349 value. The following IdTypes and their 350 corresponding values are as defined in [2]. 351 Host-FQDN: 352 X500-DN: 353 X500-GN: 354 Key-Id: 355 DEFAULT Any ID is considered valid. 357 NAME destinationHostID 358 DESC Destination Host Identifier 359 SYNTAX IA5String 360 EQUALITY caseExact1A5Match 361 MULTI-VALUED 362 DEFAULT Any ID is considered valid. 363 FORMAT Same as SourceHostID. 365 4. Attributes of UserConditionAuxClass 367 NAME senderID 368 DESC Source User Identifier 369 SYNTAX IA5String 370 EQUALITY caseExact1A5Match 371 MULTI-VALUED 372 FORMAT Two strings colon (:) seperated, the first 373 describing the ID type and the second the ID 374 value. The following ID Types and their 375 corresponding values are as defined in [2]. 376 User-FQDN: 377 X500-DN: 378 X500-GN: 379 Key-Id: 380 DEFAULT Any ID is considered valid. 382 NAME receiverID 383 DESC Destination User Identifier 384 SYNTAX IA5String 385 EQUALITY caseExact1A5Match 386 MULTI-VALUED 387 DEFAULT Any ID is considered valid. 388 FORMAT Same as SourceHostID. 390 5. Attributes of ApplicationConditionAuxClass 392 NAME sourcePortRange 393 DESC Source Ports to which policy applies 394 SYNTAX IA5String 395 EQUALITY caseExactIA5Match 396 MULTI-VALUED 397 FORMAT String consisting of two colon separated positive 398 integers, the second no smaller than the first, or 399 one positive integer. 400 DEFAULT Defaults to the entire port range 0 to 65535, i.e. 401 every packet matches the destination address range 402 condition. 403 EXAMPLE 8000:8080 (ports 8000 to 8080), 404 8000 (only port 8000) 406 NAME destinationPortRange 407 DESC Destination Ports to which policy applies 408 SYNTAX IA5String 409 EQUALITY caseExactIA5Match 410 MULTI-VALUED 411 FORMAT String consisting of two colon separated positive 412 integers, the second no smaller than the first, or 413 one positive integer. 414 DEFAULT Defaults to the entire port range 0 to 65535, i.e. 415 every packet matches the source address range 416 condition. 418 NAME protocolNumberRange 419 DESC Protocol numbers to which policy applies 420 SYNTAX INTEGER 421 EQUALITY integerMatch 422 MULTI-VALUED 423 FORMAT String consisting of two colon separated positive 424 integers, the second no smaller than the first, or 425 one positive integer. 426 DEFAULT Defaults to the entire protocol range 0 to 255, 427 i.e., every packet matches the ip protocol range 428 condition. 429 EXAMPLE 50:51 (protocol 50 to 51), 430 50 (only protocol 50) 432 NAME receivedTOSByteCheck 433 DESC A condition attribute used to select traffic based 434 on the contents of the TOS byte of the received 435 packet's IP header 436 SYNTAX IA5String 437 EQUALITY caseExactIA5Match 438 MULTI-VALUED 439 FORMAT String of the form xxxxxxxx:xxxxxxxx, where each 440 of the x's is either 0 or 1. 441 SEMANTICS Each of the substrings is treated as specifying an 442 8-bit field. The left substring is termed Mask and 443 the right substring Match. The TOS byte of the 444 received packet's IP header is ANDed with Mask and 445 the result is compared against Match. The 446 combination of Mask and Match allows definition of 447 TOS byte based conditions where certain bits in 448 the TOS byte may be ignored for the purpose of 449 comparison. Note that is superior to 450 in that TOS bit positions corresponding to 451 a Mask bit of 0 are ignored irrespective of the 452 corresponding bit. 453 EXAMPLE An incoming packet with TOS byte 11001010 matches 454 the condition specified by a value of 455 00111100:00001000 for receivedTOSByte. 457 6. Attributes of RouteConditionAuxClass 459 NAME interface 460 DESC An attribute that limits the scope of the policy 461 to packets on specified interface(s) and the 462 direction(s) of traffic on these. 463 SYNTAX IA5String 464 EQUALITY caseExactIA5Match 465 MULTI-VALUED 466 FORMAT Three colon separated strings. The left-most 467 string is a numeral denoting the type of the 468 specification, followed by the incoming and 469 outgoing interface identifiers. Currently defined 470 type/value formats are 471 1-- 472 2-- 473 3-- 475 The IP addresses are in dotted decimal notation. 476 The interface IDs are integers unique to the host 477 device. The first address string specifies a 478 restriction of the rule to traffic inbound on the 479 interface, and the rightmost string specifies a 480 corresponding restriction of the rule to traffic 481 outbound from that interface. An unspecified 482 interface(s) defaults to all interfaces on the 483 device that this rule applies to. 484 DEFAULTS Defaults to traffic inbound on all interfaces, 485 outbound on all interfaces. 487 EXAMPLE 1-9.3.1.52-9.2.1.54 488 (Applies to traffic inbound on 9.3.1.52 489 and outbound on 9.3.1.54) 491 1-9.3.1.32- 492 (Applies to traffic inbound on 9.3.1.52 outbound 493 on any interface) 495 1- -3 496 (Applies to traffic outbound on interface 3 and 497 inbound on any interface) 499 7. Attributes of Layer2ConditionAuxClass 501 NAME sourceMACAddress 502 DESC The sourceMACAddress(es) to which the policy 503 applies. 504 EQUALITY CaseIgnoreIA5String 505 SYNTAX IA5String 506 MULTI-VALUED 507 FORMAT The IEEE Canonical representation of the MAC 508 address. 509 Default Entire range of values 511 NAME destinationMACAddress 512 DESC The destination MAC Address(es) to which the 513 policy applies. 514 EQUALITY CaseIgnoreIA5String 515 SYNTAX IA5String 516 MULTI-VALUED 517 FORMAT Same as sourceMACAddress 518 Default Entire range of values 520 NAME 802.1QVLANID 521 DESC The VLAN identified by the value in the 802.1Q 522 VLAN tag. 523 EQUALITY IntegerMAtch 524 SYNTAX Integer 525 MULTI-VALUED 526 FORMAT The VLAN id in the 802.1Q defined header. 527 Default Entire range of values 529 NAME SNAPHeaderValue 530 DESC The value contained in the SNAP header that 531 identifies the protocol contained in the frame. 532 EQUALITY caseIgnoreIA5Match 533 SYNTAX IA5String 534 MULTI-VALUED 535 FORMAT A string representing the hexadecimal value that 536 would appear in the SNAP header to identify the 537 protocol. 539 Default Entire range of values 541 NAME ethertypeValue 542 DESC The value contained in the ethertype portion of 543 the frame header identifying the protocol 544 contained in the frame. 545 EQUALITY caseIgnoreIA5Match 546 SYNTAX IA5String 547 MULTI-VALUED 548 FORMAT A string representing the hexadecimal value that 549 would appear in the ethertype header to identify 550 the protocol. 552 NAME DSAP 553 DESC The value contained in the destination SAP of 554 the frame that can be used to identify the frame 555 e.g. a DSAP value of 0x04 identifies SNA frames. 556 EQUALITY caseIgnoreIA5Match 557 SYNTAX IA5String 558 MULTI-VALUED 559 FORMAT A string representing the hexadecimal value that 560 would appear in the DSAP header to identify the 561 protocol. 563 NAME SSAP 564 DESC The value contained in the source SAP of the frame 565 that can be used to identify the frame 566 e.g a SSAP value of 0x04 identifies SNA frames. 567 EQUALITY caseIgnoreIA5Match 568 SYNTAX IA5String 569 MULTI-VALUED 570 FORMAT A string representing the hexadecimal value that 571 would appear in the SSAP header to identify the 572 protocol. 574 8. Security Considerations 576 There are two potential security considerations, both of which may 577 be addressed through standards compliant mechanisms. The first 578 is the unauthorized access to read or change policy rules and 579 related objects in the directory repository. The schema in this 580 document SHOULD be used in conjunction with an LDAP access control 581 mechanisms. The second exposure for violation of security lies in 582 the communication between policy decision point and the directory 583 repository. Such communication SHOULD be secured, with both ends 584 mutually authenticated using SSL/TLS or IPSec. 586 Acknowledgments 588 We would like to acknowledge Debasish Biswas for his original 589 suggestion to use auxiliary classes in this context. We would like 590 to also thank Jean Christophe Martin, Michael See and Skip Booth for 591 many useful suggestions. 593 References 595 [1] J. Strassner and E. Ellesson, Policy Framework Core Information 596 Model", draft-ietf-policy-core-schema-01.txt, February 1999. 598 [2] D. Piper, ``The Internet IP Security Domain Of Interpretation 599 for ISAKMP'', draft-ietf-ipsec-doi-07 601 [3] Bhattacharya, P., and R. Adams, W. Dixon, R. Pereira, R. Rajan, 602 "An LDAP Schema for Configuration and Administration of IPSec 603 based Virtual Private Networks (VPNs)", Internet-Draft work in 604 progress, October 1998 606 [4] Rajan, R., and J. C. Martin, S. Kamat, M. See, R. Chaudhury, 607 D. Verma, G. Powers, R. Yavatkar, "Schema for Differentiated 608 Services and Integrated Services in Networks", Internet-Draft 609 work in progress, October 1998 611 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 612 Levels", BCP 14, RFC 2119, March 1997. 614 AUTHOR'S ADDRESS 616 Raju Rajan IBM Research 30 Saw Mill River Road Hawthorne, NY 10532 617 email: raju@watson.ibm.com 619 Full Copyright Statement 621 Copyright (C) The Internet Society (1997). All Rights Reserved. 623 This document and translations of it may be copied and furnished to 624 others, and derivative works that comment on or otherwise explain it 625 or assist in its implementation may be prepared, copied, published 626 and distributed, in whole or in part, without restriction of any 627 kind, provided that the above copyright notice and this paragraph 628 are included on all such copies and derivative works. However, 629 this document itself may not be modified in any way, such as by 630 removing the copyright notice or references to the Internet Society 631 or other Internet organizations, except as needed for the purpose 632 of developing Internet standards in which case the procedures 633 for copyrights defined in the Internet Standards process must be 634 followed, or as required to translate it into languages other than 635 English. The limited permissions granted above are perpetual and 636 will not be revoked by the Internet Society or its successors or 637 assigns. 639 This document and the information contained herein is provided on an 640 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 641 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 642 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 643 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 644 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.