idnits 2.17.1 draft-ietf-simple-data-req-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 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 260: '... REQ 1: It MUST be possible for ...' RFC 2119 keyword, line 263: '... REQ 2: It MUST be possible for ...' RFC 2119 keyword, line 266: '... example), it MUST be possible to i...' RFC 2119 keyword, line 269: '... REQ 3: It SHOULD be possible fo...' RFC 2119 keyword, line 273: '... REQ 4: It MUST be possible to a...' (73 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (October 9, 2002) is 7868 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIMPLE WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 M. Isomaki 6 Nokia 7 draft-ietf-simple-data-req-00.txt 8 October 9, 2002 9 Expires: April 2003 11 Requirements for Manipulation of Data Elements in SIMPLE Systems 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other 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 To view the list Internet-Draft Shadow Directories, see 32 http://www.ietf.org/shadow.html. 34 Abstract 36 In an instant messaging and presence application, it is frequently 37 necessary for the user to configure a number of pieces of 38 information. Users will need to manipulate their presentity list, 39 adding and removing presentities, and manipulate their authorization 40 lists, which specify the set of users that can subscribe to their 41 presence. In this document, we provide a framework and requirements 42 for such data manipulations. 44 Table of Contents 46 1 Introduction ........................................ 3 47 2 Terminology ......................................... 3 48 3 Framework ........................................... 4 49 4 Presentity Collection Manipulation Requirements ..... 7 50 5 Authorization Policy Manipulation ................... 9 51 5.1 Acceptance Policy Requirements ...................... 9 52 5.2 Notification Requirements ........................... 11 53 5.3 Content Requirements ................................ 12 54 5.4 General Requirements ................................ 12 55 6 Possible Solutions .................................. 13 56 7 Security Considerations ............................. 13 57 8 Acknowledgements .................................... 14 58 9 Authors Addresses ................................... 14 59 10 Normative References ................................ 15 60 11 Informative References .............................. 15 62 1 Introduction 64 Consumer-based instant messaging and presence applications typically 65 provide a rich set of features. In addition to being able to 66 subscribe to, and get notified of, changes in presence, users can 67 also configure the operation of the application. 69 Most systems allow the user to add or remove users from their "buddy 70 list", which we refer to here as a presentity collection. The 71 presentity collection is the set of presentities [1] that a user is 72 subscribed to. This list is frequently stored on the server, allowing 73 the user to generate a single subscription to the entire list. The 74 server then "fans out" that subscription too all the presentities on 75 the list. Subscription to presentity collections is supported through 76 the presence collection event package defined for SIMPLE [2]. 77 However, no automated means is currently defined to create these 78 lists, add users to them, remove users from them, or query for the 79 set of users on the list. 81 Similarly, most systems support user-defined authorization policies. 82 A user can specify which watchers are (or are not) allowed to 83 subscribe to their presence, and furthermore, what aspects of their 84 presence a watcher is able to see. While SIMPLE [3] systems can 85 support such authorization policies, besides human-driven techniques, 86 such as web or voice response, there is no automated way to specify 87 these policies. 89 In this document, we propose a framework and a set of requirements 90 for manipulation of presentity collections and authorization 91 policies. 93 2 Terminology 95 This document uses the following terminology: 97 Presentity Collection: A presentity collection is a set of 98 presentities, each of which is identified by a URI. The 99 collection itself is identified by a URI (for example, 100 sip:myfriends@example.com). Using the presence list package 101 [2], a watcher can subscribe to the presentity collection 102 and learn about the presence state of all the presentities 103 in the set. 105 Presence Authorization Policy: Presence authorization policy 106 refers to the set of directives given to a presence agent 107 on what subscriptions to accept, when to generate 108 notifications for a subscription, and what information 109 should be placed in those notifications. 111 Acceptance Policy: The component of presence authorization 112 policy that determines whether or not to accept a 113 subscription from a watcher. 115 Notification Policy: The component of presence authorization 116 policy that determines when a notification should be sent 117 to a watcher. 119 Content Policy: The component of presence authorization that 120 determines the content of the information provided to a 121 watcher in a notification. 123 SIMPLE Data Elements: SIMPLE data elements are user specified 124 data that determine the behavior of a presence agent. This 125 includes presentity collections and presence authorization 126 policy. 128 Data Manipulation Client: A data manipulation client is a 129 protocol agent that reads, writes, and receives 130 notifications of changes in SIMPLE data elements. 132 Data Manipulation Server: A data manipulation server is a 133 protocol agent that receives reads, writes, and sends 134 notifications of changes in SIMPLE data elements. The 135 server is responsible for the storage of the SIMPLE data 136 elements. 138 3 Framework 140 The framework for the the usage and manipulation of SIMPLE data 141 elements is shown in Figure 1. 143 The data manipulation client (just referred to as the client) uses 144 some protocol, whose requirements are specified here, to interact 145 with the data manipulation server. Those interactions include 146 requests to read a SIMPLE data element, write one, or receive 147 notifications in changes to one. The data manipulation server (just 148 referred to as the server) mananges a persistent store of the SIMPLE 149 data elements, and interacts with the client. 151 When a Presence Agent (PA) receives a SIP SUBSCRIBE request [3], it 152 may require access to SIMPLE data elements in order to process the 153 request. For example, if the subscription is for a presentity 154 collection, the PA will need to determine that this is the case, and 155 secondly, "expand" the collection, obtaining the list of URIs for 156 that collection. 158 SUBSCRIBE +--------+ 159 --------------->| | Read 160 | PA |<--+ //----\\ 161 <---------------| | | || || 162 NOTIFY +--------+ +--- \\----//| 163 | | 164 | Storage| 165 | | 166 +--------+ | | 167 | Server |------> | | 168 | | Write \ / 169 | | \------/ 170 +--------+ 171 ^ | 172 | | 173 | | BL/Auth 174 | | Manipulations 175 | | 176 | | 177 | V 178 +--------+ 179 | Client | 180 | | 181 | | 182 +--------+ 184 Figure 1: Framework for Data Manipulation 186 If the SUBSCRIBE request is for a presentity, the PA will need to 187 obtain the presence authorization policy of that presentity in order 188 to process the SUBSCRIBE request. 190 In both cases, the PA requires only read access to the data. As a 191 result, it obtains it directly from the data store, rather than 192 interacting with the server. This, of course, is just a model of the 193 system; a real implementation might involve interaction with the 194 server before reading the data. 196 Between the presentity collection and presence authorization policy, 197 the presence authorization policy is a far more complicated piece of 198 data. The authorization policy can be reasonably split into three 199 separate pieces. The first, which we call the acceptance policy, 200 determines whether or not to grant a subscription to the subscriber. 201 This policy results in a binary decision. The second piece, which we 202 call the notification policy, determines when that particular 203 subscriber should receive notifications. For example, a subscriber 204 might only be permitted to see when I log in or log out of IM, but 205 not receive notifications when my phone goes on hook. This is closely 206 related to the third piece, which we call the content policy. This 207 policy specifies the content of the information present in a 208 notification that is sent to a subscriber. 210 Generally, there are two aspects to each of these policy components. 211 One is the logic that guides the policy, and the other is the data 212 (such as lists of users) accessed by that logic. As an example, the 213 logic of the acceptance policy might dictate that a watcher is 214 checked against an explicit deny list, and if present, their 215 subscription is denied. If they are not on the deny list, they are 216 checked against an explicit allow list, and if present, their 217 subscription is accepted. If they are on neither list, they are 218 marked as pending. This logic makes use of two lists, which represent 219 the data. 221 In this model, the logic can be represented by a script, similar to 222 the operation of a Call Processing Language (CPL) [4] script. The 223 primitives of the scripting language would allow for access to the 224 lists that represent the data. For example, a CPL-like script 225 representing the policy example of the previous paragraph might look 226 like: 228 229 230 231 232 233 234 235 236 237 238 239 240 242 243 244 245 246 247 249 The deny and allow lists are, in this example, represented by SIP 250 URIs. The script itself can also be represented by a URI. In order to 251 activate a policy, a particular script is bound to the authorization 252 function that executes at the PA. 254 4 Presentity Collection Manipulation Requirements 256 The following are the set of requirements for the protocol between 257 the client and the server for the purposes of manipulation presentity 258 collections. 260 REQ 1: It MUST be possible for the client to create a presentity 261 collection and associate it with a URI. 263 REQ 2: It MUST be possible for the user to specify the URI for 264 the presentity collection when one is created. If the name 265 cannot be allocated (because it already exists, for 266 example), it MUST be possible to inform the client of the 267 failure, and the reason for it. 269 REQ 3: It SHOULD be possible for the server to provide the 270 client a URI for the list when one is created, in the case 271 where the client does not provide it. 273 REQ 4: It MUST be possible to add an entry to the presentity 274 collection. Each entry MUST consist of at least a URI, and 275 MAY include a display name. It MUST be possible for the 276 entry to be any URI that is meaningful in the context of a 277 presentity collection. Examples would include a SIP URI or 278 pres URI [5]. 280 REQ 5: It MUST be possible for a presentity collection to 281 contain entries which are themselves presentity 282 collections. 284 REQ 6: It MUST be possible to remove an entry from the 285 presentity collection, by providing the URI for the 286 specific entry to be removed. If the entry does not exist, 287 it MUST be possible for the server to inform the client of 288 this fact. 290 REQ 7: It SHOULD be possible to clear all entries from a 291 presentity collection. 293 REQ 8: It MUST be possible to delete a presentity collection. In 294 this context, deleted means that the name of the presentity 295 collection is no longer defined, so that subscriptions to 296 the list would fail. 298 REQ 9: It MUST be possible to query for the set of URIs in a 299 particular presentity collection, by providing the URI for 300 the presentity collection. 302 REQ 10: It MUST be possible for the presentity collection to be 303 associated with a list of authorized users. Those 304 authorized users are the only ones permitted to manipulate 305 the presentity collection. 307 REQ 11: It MUST be possible for a client to store a cached copy 308 of the list. This implies that it MUST be possible for the 309 server to notify the client of a change in the list. It 310 MUST be possible for the client to manipulate the local 311 cached copy even when there is no connectivity to the 312 server. It MUST be possible to synchronize the cached copy 313 with the master copy on the server, when connectivity is 314 re-established. 316 This particular requirement is crucial for wireless 317 systems, where a copy of the list resides ont he handset. 318 Without this requirement, a user would not be able to view 319 the list, or add a user to it, when they go out of 320 coverage. 322 REQ 12: It MUST be possible for there to be multiple clients 323 with cached copies of the list. 325 REQ 13: Manipulations of the presentity collection MUST exhibit 326 the ACID property; that is, they MUST be atomic, be 327 consistent, durable, and operate independently. 329 REQ 14: It MAY be possible for the client to batch multiple 330 operations (add a presentity, remove a presentity) into a 331 single request that is processed atomically. 333 REQ 15: It MUST be possible for the server to authenticate the 334 client. 336 REQ 16: It MUST be possible for the client to authenticate the 337 server. 339 REQ 17: It MUST be possible for message integrity to be insured 340 between the client and the server. 342 REQ 18: It MUST be possible for privacy to be insured between 343 the client and server. As a motivating example, an 344 eavesdropper on the protocol could ascertain the set of 345 people in my presentity collection, resulting in divulging 346 private information. 348 REQ 19: It MUST be possible for the protocol to operate through 349 an intermediary, such as a proxy. 351 REQ 20: It MUST be possible to modify an entry in the presentity 352 collection. 354 5 Authorization Policy Manipulation 356 The following are the set of requirements for the protocol between 357 the client and the server for the purposes of manipulating presence 358 authorization policy. The requirements are divided between acceptance 359 policy, notification policy, and content policy. 361 5.1 Acceptance Policy Requirements 363 REQ 1: It MUST be possible for the acceptance policy to support 364 rejection of the subscription if the watcher is present on 365 a specified list of "blocked watchers". When a list is 366 checked in this fashion, its referred to as a blocked list. 367 This is effectively a requirement on the scripting 368 language. 370 REQ 2: It MUST be possible for the acceptance policy to support 371 rejection of the subscription if the watcher is not present 372 on a specified list of "allowed watchers". When a list is 373 checked in this fashion, its referred to as an allowed 374 list. 376 REQ 3: It MUST be possible for the acceptance policy to check 377 multiple blocked and allowed lists. 379 REQ 4: It MUST be possible for the acceptance policy to support 380 rejection of the subscription based on filter information 381 provided in the subscription. 383 REQ 4.1: It MUST be possible for the policy to be based on the 384 status types (for example, the basic status type as defined 385 in PIDF [6] requested in the filter. 387 REQ 4.2: It MUST be possible for the policy to be based on the 388 status values requested in the filter. 390 REQ 4.3: It MUST be possible for the policy to be based on 391 whether the subscriber has requested, using the filter, to 392 receive contact addresses. 394 REQ 5: It SHOULD be possible for the policy to be based on the 395 time of day. 397 REQ 6: It SHOULD be possible for the policy to be based on the 398 means by which the authenticated identity of the watcher 399 was determined. 401 REQ 7: It MUST be possible for the user to manipulate any lists 402 that are checked by by the authorization policy (for 403 example, the allowed and denied lists). 405 REQ 7.1: It MUST be possible for the user to add URIs to the 406 lists. 408 REQ 7.2: It MUST be possible for the user to remove URIs from 409 the lists. 411 REQ 7.3: It MUST be possible for the user to modify URIs in the 412 lists. 414 REQ 7.4: It MUST be possible for the user to obtain the contents 415 of a list. 417 REQ 7.5: It MUST be possible for the user to create new lists. 419 REQ 7.6: It MUST be possible for the user to delete lists. 421 REQ 7.7: It MUST be possible for the user to clear all URIs on a 422 list. 424 REQ 7.8: It MUST be possible for the user to assign a URI that 425 identifies the list. 427 REQ 7.9: It MUST be possible for the server to assign a URI that 428 identifies a list created by the user. 430 REQ 8: It MUST be possible to bind a script defining the logic 431 for processing to a particular authorization function. 433 REQ 9: It MUST be possible for the client to determine the set 434 of supported scripting languages. 436 REQ 10: It MUST be possible for the server to reject the script 437 because it is malformed, too complex, or not acceptable for 438 some other reason. 440 REQ 11: It MUST be possible for the client to fetch the current 441 script. 443 REQ 12: It MUST be possible for the client to indicate what 444 script languages it supports when it fetches the script. In 445 this way, a server could conceivably translate it to a 446 format supported by the client. 448 REQ 13: When a list referenced by script is deleted, the user 449 MUST either be alerted or prevented from doing so. 451 5.2 Notification Requirements 453 REQ 1: It MUST be possible for the user to specify that 454 notifications are to be sent only when the value of a 455 particular status type changes. 457 REQ 2: It MUST be possible for the user to specify that the 458 notifications are to be sent only when a particular status 459 type changes to a specified value or set of values. 461 REQ 3: It MUST be possible for the user to specify that the 462 notifications are to be sent only when a particular status 463 type changes from a specified value to a specified value 464 (i.e., from open to closed). 466 REQ 4: It MUST be possible for the user to specify that the 467 notifications are to be sent no more frequently than a 468 specified minimum rate. 470 REQ 5: It MUST be possible for the user to specify that the 471 notifications are to be sent only when the value of the 472 contact address changes. 474 OPEN ISSUE: Does this even make sense? 476 REQ 6: It SHOULD be possible for the user to specify that the 477 notifications are not to be sent on changes in the state of 478 the subscription (as opposed to the state of the 479 presentity). 481 REQ 7: It SHOULD be possible for the user to specify that the 482 notifications are to be sent based on the filter policy 483 present in the SUBSCRIBE request. In that case, the overall 484 filter policy would be the composition of the requested 485 filter and the filters explicitly specified by the 486 presentity. 488 5.3 Content Requirements 490 REQ 1: It MUST be possible for the user to specify that the 491 notification should or should not contain a contact 492 address. 494 REQ 2: It MUST be possible for the user to specify that the 495 notification should contain only specific status types 496 (such as basic). 498 REQ 3: The user MUST be able to specify the specific values of a 499 specific status type that the notification should or should 500 not contain. Values not permitted must be omitted from the 501 status in notifications. If all status is omitted, the 502 tuple must be omitted as well. As an example, a user can 503 specify that the notification should include tuples with 504 OPEN status, but suppress those with only CLOSED status. 506 REQ 4: The user MUST be able to specify that the notification 507 should only contain information for particular tuples. 509 OPEN ISSUE: Its not clear how to meaningfully identify 510 the tuples. 512 REQ 5: It SHOULD be possible for the user to specify that the 513 notifications are to be sent based on the filter policy 514 present in the SUBSCRIBE request. In that case, the overall 515 filter policy would be the composition of the requested 516 filter and the filters explicitly specified by the 517 presentity. 519 5.4 General Requirements 521 These requirements apply to all of the three components of the 522 authorization policy. 524 REQ 1: It SHOULD be possible for a client to store a cached copy 525 of the policies and any related data (the lists, for 526 example). This implies that it MUST be possible for the 527 server to notify the client of a change in these data. It 528 MUST be possible for the client to manipulate the local 529 cached copy even when there is no connectivity to the 530 server. It MUST be possible to synchronize the cached copy 531 with the master copy on the server, when connectivity is 532 re-established. 534 REQ 2: It MUST be possible for there to be multiple clients with 535 cached copies of the data. 537 REQ 3: Manipulations of the data MUST exhibit the ACID property; 538 that is, they MUST be atomic, be consistent, durable, and 539 operate independently. 541 REQ 4: It MAY be possible for the client to batch multiple 542 operations (add a user to a list, change the script) into a 543 single request that is processed atomically. 545 REQ 5: It MUST be possible for the server to authenticate the 546 client. 548 REQ 6: It MUST be possible for the client to authenticate the 549 server. 551 REQ 7: It MUST be possible for message integrity to be insured 552 between the client and the server. 554 REQ 8: It MUST be possible for privacy to be insured between the 555 client and server. As a motivating example, an eavesdropper 556 on the protocol could ascertain the set of people in my 557 allowed list collection, resulting in divulging private 558 information. 560 REQ 9: It MUST be possible for the protocol to operate through 561 an intermediary, such as a proxy. 563 6 Possible Solutions 565 This document is primarily a requirements document, and does not aim 566 to provide a protocol for meeting the requirements defined here. 567 However, there are several protocols already in existence which 568 appear close to meeting the requirements described. One of these is 569 ACAP [7]. Since the protocol is primarily a client-server RPC type of 570 operation, it seems like HTTP and SOAP might also serve as a basis, 571 with a suitably defined set of WSDL. SIP could operate alongside 572 SOAP, to provide the notification aspects of the requirements. SNMP 573 is another possibility for the protocol. 575 7 Security Considerations 576 There are many security considerations associated with the protocol 577 whose requirements are defined here. 579 The protocol is used to manipulate data that has a signficiant impact 580 on the operation of a service provided to a user. In particular, if 581 the data is manipulated by an attacker, the attacker can: 583 o convey information to subscribers that the presentity wishes 584 to keep private; 586 o launch denial of service attacks by flooding a subscriber with 587 more presence information than they expected; 589 o deny service to subscribers or to presentities. 591 To prevent these attacks, the protocol has to ensure than only 592 authorized users can manipulate the data. Requirements for 593 authentication and authorization are defined above. 595 Information conveyed in the protocol represents sensitive data. It 596 can include the content of presentity collections and lists of 597 blocked users, both of which reveal personal preferences of a user 598 that they do not wish to convey. As a result, it is necessary that 599 the client authenticate the server, to be sure it is passing this 600 information to a trusted entity. It is also necessary for the 601 protocol to provide encryption services, so that eavesdroppers cannot 602 inspect the data as it passes by. 604 8 Acknowledgements 606 The authors would like to thank Paul Kyzivat for his input. 608 9 Authors Addresses 610 Jonathan Rosenberg 611 dynamicsoft 612 72 Eagle Rock Avenue 613 First Floor 614 East Hanover, NJ 07936 615 email: jdrosen@dynamicsoft.com 617 Markus Isomaki 618 Nokia 619 Nokia House 620 Keilalahti, Espoo 621 Finland 622 email: markus.isomaki@nokia.com 624 10 Normative References 626 11 Informative References 628 [1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and 629 instant messaging," RFC 2778, Internet Engineering Task Force, Feb. 630 2000. 632 [2] J. Rosenberg and B. Campbell, "A SIP event package for list 633 presence," Internet Draft, Internet Engineering Task Force, June 634 2002. Work in progress. 636 [3] J. Rosenberg, "Session initiation protocol (SIP) extensions for 637 presence," Internet Draft, Internet Engineering Task Force, May 2002. 638 Work in progress. 640 [4] J. Lennox and H. Schulzrinne, "Call processing language framework 641 and requirements," RFC 2824, Internet Engineering Task Force, May 642 2000. 644 [5] D. Crocker et al. , "Common presence and instant messaging 645 (CPIM)," Internet Draft, Internet Engineering Task Force, Aug. 2002. 646 Work in progress. 648 [6] H. Sugano, S. Fujimoto, et al. , "Common presence and instant 649 messaging (CPIM)presence information data format," Internet Draft, 650 Internet Engineering Task Force, May 2002. Work in progress. 652 [7] C. Newman and J. G. Myers, "ACAP -- application configuration 653 access protocol," RFC 2244, Internet Engineering Task Force, Nov. 654 1997. 656 Full Copyright Statement 658 Copyright (c) The Internet Society (2002). All Rights Reserved. 660 This document and translations of it may be copied and furnished to 661 others, and derivative works that comment on or otherwise explain it 662 or assist in its implementation may be prepared, copied, published 663 and distributed, in whole or in part, without restriction of any 664 kind, provided that the above copyright notice and this paragraph are 665 included on all such copies and derivative works. However, this 666 document itself may not be modified in any way, such as by removing 667 the copyright notice or references to the Internet Society or other 668 Internet organizations, except as needed for the purpose of 669 developing Internet standards in which case the procedures for 670 copyrights defined in the Internet Standards process must be 671 followed, or as required to translate it into languages other than 672 English. 674 The limited permissions granted above are perpetual and will not be 675 revoked by the Internet Society or its successors or assigns. 677 This document and the information contained herein is provided on an 678 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 679 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 680 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 681 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 682 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.