idnits 2.17.1 draft-ietf-manet-timetlv-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 646. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 26, 2008) is 5690 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: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) T. Clausen 3 Internet-Draft LIX, Ecole Polytechnique, France 4 Intended status: Standards Track C. Dearlove 5 Expires: March 30, 2009 BAE Systems Advanced Technology 6 Centre 7 September 26, 2008 9 Representing multi-value time in MANETs 10 draft-ietf-manet-timetlv-08 12 Status of This Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 30, 2009. 37 Abstract 39 This document describes a general and flexible TLV (type-length-value 40 structure) for representing time-values, such as an interval or a 41 duration, using the generalized MANET packet/message format. It 42 defines two message and two address block TLVs for representing 43 validity and interval times for MANET routing protocols. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Motivation and Rationale . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 51 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 52 5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 6 53 6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 7 54 6.1. Single-value Time TLVs . . . . . . . . . . . . . . . . . . 8 55 6.2. Multi-value Time TLVs . . . . . . . . . . . . . . . . . . 9 56 7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 57 7.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 58 7.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 59 8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 10 60 8.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 61 8.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 11 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 9.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 11 64 9.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 12 65 9.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 12 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 69 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 The generalized packet/message format [packetbb] specifies a 75 signaling format which MANET routing protocols can employ for 76 exchanging protocol information. This format presents the ability to 77 express and associate attributes to packets, messages or addresses, 78 by way of a general TLV (type-length-value) mechanism. 80 This document specifies a general Time TLV structure, which can be 81 used by any MANET routing protocol that needs to express either 82 single time-values or a set of time-values with each time-value 83 associated with a range of hop counts, as provided by the message 84 header of [packetbb]. This allows a receiving node to determine a 85 single time-value if either it knows its hop count from the 86 originator node, or the Time TLV specifies a single time-value. 88 A time-value is, in this context, not an "absolute point in time", 89 but rather an interval or a duration. An instance of a Time TLV can, 90 therefore, express an interval or a duration such as "10 seconds". 92 This document also specifies two message TLV types, which use the TLV 93 structure proposed. These TLV types are INTERVAL_TIME and 94 VALIDITY_TIME, specifying respectively the maximum time before 95 another message of the same type as this message from the same 96 originator should be received, and the duration for which the 97 information in this message is valid after receipt. Note that, if 98 both are present, then the latter will usually be greater than the 99 former in order to allow for possible message loss. 101 This document also specifies two address block TLV types, which use 102 the TLV structure proposed. These TLV types are INTERVAL_TIME and 103 VALIDITY_TIME, defined equivalently to the two message TLVs with the 104 same names. 106 1.1. Motivation and Rationale 108 The Time TLV structure, specified in this document, is intended to be 109 used as a component in a MANET routing protocol, e.g. to indicate the 110 expected spacing between successive transmissions of a given message 111 type, by including a Time TLV in transmitted messages. 113 Some MANET routing protocols may employ very short spacing for some 114 messages and very long spacing for others, or may change the message 115 transmission rate according to observed behavior. For example, if a 116 network is observed at some point in time to exhibit a highly dynamic 117 topology, a very short (sub-second) message spacing could be 118 appropriate, whereas if the network later is observed to stabilize, 119 multi-hour message spacing may become appropriate. Different MANET 120 routing protocols and different deployments of MANET routing 121 protocols may have different granularity requirement and bounds on 122 shortest and longest spacing between successive message 123 transmissions. 125 In addition, MANET routing protocol deployments typically use 126 bandwidth limited wireless network interfaces, and therefore prefer 127 to trade off computational complexity for a saving in the number of 128 bits transmitted. This is practical in this case, because the 129 intended usages of Time TLVs, including the specified examples of 130 message interval time and information validity time, do not require 131 high precision values of time. 133 The Time TLV structure, specified in this document, caters to these 134 characteristics by: 136 o encoding time-values, such as an interval or a duration, in an 8 137 bit field; while 139 o allowing these time-values to range from "very small" (e.g. 1/1024 140 second) to "very long" (e.g. 45 days); and 142 o allowing a MANET routing protocol, or a deployment, to parametrize 143 this (e.g. to attain finer granularity at the expense of a lower 144 upper bound) through a single parameter, C. 146 The parameter C must be the same for all MANET routers in the same 147 deployment. 149 The TLV mechanism as specified in [packetbb] allows associating a 150 "value" to either a packet, a message or to addresses. The data 151 structure for doing so - the TLV - is identical in each of the three 152 cases, however the TLV's position in a received packet allows 153 determining if that TLV is a "packet TLV" (it appears in the packet 154 header, before any messages), a "message TLV" (it appears in the TLV 155 block immediately following a message header) or an "address block 156 TLV" (it appears in the TLV block immediately following an address 157 block). 159 While TLVs may be structurally identical, that which they express may 160 be different. This is determined from the kind (packet, message or 161 address block) and type of the TLV. For example one TLV might 162 associate a lifetime to an address, another a content sequence number 163 to a message, and another a cryptographic signature to a packet. For 164 this reason, [packetbb] specifies separate registries for packet, 165 message and address block TLV types, and does not specify any 166 structure in the TLV value field. 168 The TLVs defined in this document express, essentially, that "this 169 information will be refreshed within X seconds" and that "this 170 information is valid for X seconds after being received", each 171 allowing the "X seconds" to be specified as a function of the number 172 of hops from the originator of the information. This document 173 specifies a general format allowing expressing and encoding this as 174 the value field of a TLV. This representation uses a compact (8 bit) 175 representation of time, as message size is an issue in many MANETs, 176 and the offered precision and range is appropriate for MANET routing 177 protocols. 179 A TLV of this format may be used for packets, messages or addresses. 180 For example, a proactive MANET routing protocol periodically 181 reporting link state information could include a TLV of this format 182 as a message TLV. This may indicate a different periodicity in 183 different scopes (possibly frequently up to a few hops, less 184 frequently beyond that) because some messages may be sent with 185 limited scope, as specified in [packetbb]. A reactive MANET routing 186 protocol could include a TLV of this format as an address block TLV 187 for reporting the lifetime of routes to individual addresses. 189 In addition to defining the general format as outlined above, this 190 document requests IANA assignments for INTERVAL_TIME and 191 VALIDITY_TIME TLVs. These IANA assignments are requested in this 192 document in order to avoid interdependencies between otherwise 193 unrelated MANET protocols and in order to not exhaust the TLV type 194 spaces by having different protocols request types for essentially 195 identical data structures. Only message and address block TLVs are 196 requested, as these are those for which a need has been demonstrated. 198 2. Terminology 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 202 "OPTIONAL" in this document are to be interpreted as described in 203 [RFC2119]. 205 Additionally, this document uses terminology from [packetbb], and 206 introduces the following terminology: 208 hop count - the number of hops from the message originator to the 209 message recipient. This is defined to equal the 210 field in the element defined in [packetbb], if 211 present, after it is incremented on reception. If the field is not present, or in a packet TLV, then hop count is 213 defined to equal 255. 215 time-value - a time, measured in seconds. 217 time-code - an 8 bit field, representing a time-value. 219 3. Applicability Statement 221 The TLV structure described in this document is applicable whenever a 222 single time-value, or a time-value that varies with the number of 223 hops from the originator of a message, is required in a protocol 224 using the generalized MANET packet/message format [packetbb]. 226 Examples of time-values that may be included in a protocol message 227 are: 229 o The maximum time interval until the next message of the same type 230 is to be generated by the message's originator node. 232 o The validity time of the information with which the time-value is 233 associated. 235 Either of these may vary with the hop count between the originating 236 and receiving nodes, e.g. if messages of the same type are sent with 237 different hop limits as defined in [packetbb]. 239 Parts of this document have been generalized from material in the 240 proactive MANET routing protocol OLSR (The Optimized Link State 241 Routing Protocol) [RFC3626]. 243 4. Protocol Overview and Functioning 245 This document does not specify a protocol nor does it mandate 246 specific node or protocol behavior. Rather, it outlines mechanisms 247 for encoding time-values using the TLV mechanism of [packetbb]. 249 5. Representing Time 251 This document specifies a TLV structure in which time-values are each 252 represented in an 8 bit time-code, one or more of which may be used 253 in a TLV's field. Of these 8 bits, the least significant 3 254 bits represent the mantissa (a), and the most significant 5 bits 255 represent the exponent (b), so that: 257 o time-value = (1 + a/8) * 2^b * C 259 o time-code = 8 * b + a 261 All nodes in the MANET MUST use the same value of the constant C, 262 which will be specified in seconds, hence so will be all time-values. 264 C MUST be greater than 0 seconds. Note that ascending values of the 265 time-code represent ascending time-values, time-values may thus be 266 compared by comparison of time-codes. 268 An algorithm for computing the time-code representing the smallest 269 representable time-value not less than the time-value t is: 271 1. find the largest integer b such that t/C >= 2^b; 273 2. set a = 8 * (t / (C * 2^b) - 1), rounded up to the nearest 274 integer; 276 3. if a == 8 then set b = b + 1 and set a = 0; 278 4. if 0 <= a <= 7, and 0 <= b <= 31, then the required time-value 279 can be represented by the time-code 8 * b + a, otherwise it can 280 not. 282 The minimum time-value that can be represented in this manner is C. 283 The maximum time-value that can be represented in this manner is 15 * 284 2^28 * C, or about 4.0 * 10^9 * C. If, for example, C = 1/1024 285 second, then this is about 45 days. 287 A protocol using this time representation MUST define the value of C. 288 A protocol using this specification MAY specify that the all bits 289 zero time-value (0) represents a time-value of zero and/or that the 290 all bits one time-value (255) represents an indefinitely large time- 291 value. 293 6. General Time TLV Structure 295 The following data structure allows the representation of a single 296 time-value, or of a default time-value plus pairs of (time-values, 297 hop counts) for when hop count dependent time-values are required. 298 The time-values are represented as time-codes as defined in 299 Section 5. This data structure is specified, using the 300 regular expression syntax of [packetbb], by: 302 = ()* 304 where: 306 is an 8 bit unsigned integer field containing a time- 307 code as defined in Section 5. 309 is an 8 bit unsigned integer field specifying a hop 310 count from the message originator. 312 A structure thus consists of an odd number of octets; 313 with a repetition factor of n for the (time, hop count) pairs in the 314 regular expression syntax, it contains 2n+1 octets. On reception, n 315 is determined from the length. 317 A field may be thus represented by: 319 ... ... 321 , ... , if present, MUST be a strictly increasing sequence, 322 with < 255. Then, at the receiving node's hop count from the 323 originator node, the time-value indicated is that represented by the 324 time-code: 326 o , if n > 0 and hop count <= ; 328 o , if n > 1 and < hop count <= for some i such 329 that 1 <= i < n; 331 o otherwise, i.e. if n == 0 or hop count > . 333 If included in a message without a field in its 334 message header, or in a packet TLV, then the form of this data 335 structure with a single time-code in (i.e. n == 0) SHOULD 336 be used. 338 6.1. Single-value Time TLVs 340 The purpose of a single value Time TLV is to allow a single time- 341 value to be determined by a node receiving an entity containing the 342 Time TLV, based on its hop count from the entity's originator. The 343 Time TLV may contain information that allows that time-value to be a 344 function of the hop count, and thus different receiving nodes may 345 determine different time-values. 347 A single-value Time TLV may be a packet TLVs, a message TLV or an 348 address block TLV. 350 A Time TLV which has the tismultivalue flag cleared ('0') in its 351 field, as defined in [packetbb], contains a single , as defined above, in its field. For such a Time TLV: 354 o The field in the TLV MUST contain the value 2n+1, with n 355 being the number of (time-value, hop count) pairs in the Time TLV. 357 o The number of (time-value, hop count) pairs MUST be identified by 358 inspecting the field in the TLV. The number of such 359 pairs, n, is: 361 * n = ( - 1) / 2 363 This MUST be an integer value. 365 6.2. Multi-value Time TLVs 367 The purpose of a multi-value Time TLV is to associate a set of structures to an identically sized set of addresses, as 369 described in [packetbb]. For each of these structures, a 370 single time-value can be determined by a node receiving an entity 371 containing the Time TLV, based on its hop count from the entity's 372 originator. The Time TLV may contain information that allows that 373 time-value to be a function of the hop count, and thus different 374 receiving nodes may determine different time-values. 376 Multi-value Time TLVs MUST be address block TLVs. A multi-value Time 377 TLV MUST NOT be a packet or message TLV. 379 A Time TLV which has the tismultivalue flag set ('1') in its field, as defined in [packetbb], contains a sequence of structures, as defined above, in its field. For such a 382 Time TLV: 384 o The field in the TLV MUST contain the value m * (2n+1), 385 with n being the number of (time-value, hop count) pairs in the 386 Time TLV, and m being number-values as defined in [packetbb]. 388 o The number of structures included in the field 389 is equal to number-values as defined in [packetbb]. 391 o The number of (time-value, hop count) pairs in each 392 structure MUST be the same, and MUST be identified by inspecting 393 the field in the TLV and using number-values as defined 394 in [packetbb]. The number of such pairs in each 395 structure, n, is: 397 * n = (( / number-values) - 1) / 2 399 This MUST be an integer value. The lists of hop count values MAY 400 be different. 402 7. Message TLVs 404 Two message TLVs are defined, for signaling message interval 405 (INTERVAL_TIME) and message validity time (VALIDITY_TIME). 407 7.1. INTERVAL_TIME TLV 409 An INTERVAL_TIME TLV is a message TLV that defines the maximum time 410 before another message of the same type as this message from the same 411 originator should be received. This interval time MAY be specified 412 to depend on the hop count from the originator. (This is appropriate 413 if messages are sent with different hop limits, so that receiving 414 nodes at greater hop counts have an increased interval time.) 416 A message MUST NOT include more than one INTERVAL_TIME TLV. 418 An INTERVAL_TIME TLV is an example of a Time TLV specified as in 419 Section 5. 421 7.2. VALIDITY_TIME TLV 423 A VALIDITY_TIME TLV is a message TLV that defines the validity time 424 of the information carried in the message in which the TLV is 425 contained. After this time the receiving node MUST consider the 426 message content to no longer be valid (unless repeated in a later 427 message). The validity time of a message MAY be specified to depend 428 on the hop count from its originator. (This is appropriate if 429 messages are sent with different hop limits, so that receiving nodes 430 at greater hop counts receive information less frequently and must 431 treat is as valid for longer.) 433 A message MUST NOT include more than one VALIDITY_TIME TLV. 435 A VALIDITY_TIME TLV is an example of a Time TLV specified as in 436 Section 5. 438 8. Address Block TLVs 440 Two address block TLVs are defined, for signaling address 441 advertisement interval (INTERVAL_TIME) and address validity time 442 (VALIDITY_TIME). 444 8.1. INTERVAL_TIME TLV 446 An INTERVAL_TIME TLV is an address block TLV that defines the maximum 447 time before this address from the same originator should be received 448 again. This interval time MAY be specified to depend on the hop 449 count from the originator. (This is appropriate if addresses are 450 contained in messages sent with different hop limits, so that 451 receiving nodes at greater hop counts have an increased interval 452 time.) 454 A protocol using this TLV and the similarly named message TLV MUST 455 specify how to interpret the case when both are present (typically 456 that the former over-rides the latter for those addresses which are 457 covered by the former). 459 An INTERVAL_TIME TLV is an example of a Time TLV specified as in 460 Section 5. 462 8.2. VALIDITY_TIME TLV 464 A VALIDITY_TIME TLV is an address block TLV that defines the validity 465 time of the addresses to which the TLV is associated. After this 466 time the receiving node MUST consider the addresses to no longer be 467 valid (unless these are repeated in a later message). The validity 468 time of an address MAY be specified to depend on the hop count from 469 its originator. (This is appropriate if addresses are contained in 470 messages sent with different hop limits, so that receiving nodes at 471 greater hop counts receive information less frequently and must treat 472 is as valid for longer.) 474 A protocol using this TLV and the similarly named message TLV MUST 475 specify how to interpret the case when both are present (typically 476 that the former over-rides the latter for those addresses which are 477 covered by the former). 479 A VALIDITY_TIME TLV is an example of a Time TLV specified as in 480 Section 5. 482 9. IANA Considerations 484 This specification defines two message TLV types, which must be 485 allocated from the "Assigned Message TLV Types" repository of 486 [packetbb] as specified in Table 1 and two address block TLV types, 487 which must be allocated from the "Assigned Address Block TLV Types" 488 repository of [packetbb] as specified in Table 2. 490 IANA is requested to assign the same numerical value to the message 491 TLV and address block TLV types with the same name. 493 9.1. Expert Review: Evaluation Guidelines 495 For the registries for TLV type extensions where an Expert Review is 496 required, the designated expert SHOULD take the same general 497 recommendations into consideration as are specified by [packetbb]. 499 9.2. Message TLV Types 501 +---------------+------+-----------+--------------------------------+ 502 | Name | Type | Type | Description | 503 | | | Extension | | 504 +---------------+------+-----------+--------------------------------+ 505 | INTERVAL_TIME | TBD1 | 0 | The maximum time before | 506 | | | | another message of the same | 507 | | | | type as this message from the | 508 | | | | same originator should be | 509 | | | | received | 510 | | | 1-223 | Expert Review | 511 | | | 224-255 | Experimental Use | 512 | VALIDITY_TIME | TBD2 | 0 | The time from receipt of the | 513 | | | | message during which the | 514 | | | | information contained in the | 515 | | | | message is to be considered | 516 | | | | valid | 517 | | | 1-223 | Expert Review | 518 | | | 224-255 | Experimental Use | 519 +---------------+------+-----------+--------------------------------+ 521 Table 1 523 9.3. Address Block TLV Types 525 +---------------+------+-----------+--------------------------------+ 526 | Name | Type | Type | Description | 527 | | | extension | | 528 +---------------+------+-----------+--------------------------------+ 529 | INTERVAL_TIME | TBD1 | 0 | The maximum time before | 530 | | | | another message of the same | 531 | | | | type as this message from the | 532 | | | | same originator and containing | 533 | | | | this address should be | 534 | | | | received | 535 | | | 1-223 | Expert Review | 536 | | | 224-255 | Experimental Use | 537 | VALIDITY_TIME | TBD2 | 0 | The time from receipt of the | 538 | | | | address during which the | 539 | | | | information regarding this | 540 | | | | address is to be considered | 541 | | | | valid | 542 | | | 1-223 | Expert Review | 543 | | | 224-255 | Experimental Use | 544 +---------------+------+-----------+--------------------------------+ 546 Table 2 548 10. Security Considerations 550 This document specifies how to add data structures (TLVs) which 551 provide timing information to packets and messages specified using 552 [packetbb]. In particular, information validity durations and 553 reporting intervals may be added. 555 The general security threats that apply are those general to 556 [packetbb] and described therein, problems of integrity and 557 confidentiality. With regard to the former, modification of a time 558 TLV can cause information to have an invalid validity time, or 559 expected interval time. This may cause incorrect protocol 560 performance. Modification or addition of timed information can add 561 to a protocol's workload (especially if a short validity time is 562 specified) and storage requirements (especially if a long validity 563 time is specified). 565 To counter these threats, the security suggestions in [packetbb], for 566 the use of authentication and encryption, are appropriate. 568 11. References 570 11.1. Normative References 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", RFC 2119, BCP 14, March 1997. 575 [packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 576 "Generalized MANET Packet/Message Format", 577 draft-ietf-manet-packetbb-16.txt (work in progress), 578 September 2008. 580 11.2. Informative References 582 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 583 Routing Protocol", RFC 3626, October 2003. 585 Appendix A. Acknowledgements 587 The authors would like to thank Brian Adamson and Justin Dean (both 588 NRL) and Ian Chakeres (Motorola) for their contributions, and Alan 589 Cullen (BAE Systems) and Jari Arkko (Ericsson, Finland) for their 590 careful reviews of this specification. 592 Authors' Addresses 594 Thomas Heide Clausen 595 LIX, Ecole Polytechnique, France 597 Phone: +33 6 6058 9349 598 EMail: T.Clausen@computer.org 599 URI: http://www.ThomasClausen.org/ 601 Christopher Dearlove 602 BAE Systems Advanced Technology Centre 604 Phone: +44 1245 242194 605 EMail: chris.dearlove@baesystems.com 606 URI: http://www.baesystems.com/ 608 Full Copyright Statement 610 Copyright (C) The IETF Trust (2008). 612 This document is subject to the rights, licenses and restrictions 613 contained in BCP 78, and except as set forth therein, the authors 614 retain all their rights. 616 This document and the information contained herein are provided on an 617 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 618 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 619 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 620 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 621 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 622 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 624 Intellectual Property 626 The IETF takes no position regarding the validity or scope of any 627 Intellectual Property Rights or other rights that might be claimed to 628 pertain to the implementation or use of the technology described in 629 this document or the extent to which any license under such rights 630 might or might not be available; nor does it represent that it has 631 made any independent effort to identify any such rights. Information 632 on the procedures with respect to rights in RFC documents can be 633 found in BCP 78 and BCP 79. 635 Copies of IPR disclosures made to the IETF Secretariat and any 636 assurances of licenses to be made available, or the result of an 637 attempt made to obtain a general license or permission for the use of 638 such proprietary rights by implementers or users of this 639 specification can be obtained from the IETF on-line IPR repository at 640 http://www.ietf.org/ipr. 642 The IETF invites any interested party to bring to its attention any 643 copyrights, patents or patent applications, or other proprietary 644 rights that may cover technology that may be required to implement 645 this standard. Please address the information to the IETF at 646 ietf-ipr@ietf.org.