idnits 2.17.1 draft-ietf-opes-end-comm-01.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: ---------------------------------------------------------------------------- == 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 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 117: '...lements of an "OPES Domain" MUST be in...' RFC 2119 keyword, line 125: '...ity in an OPES system MUST be directly...' RFC 2119 keyword, line 138: '... An OPES domain MUST not be an OPES s...' RFC 2119 keyword, line 146: '...umer application MUST be able to reciv...' RFC 2119 keyword, line 211: '...tion means that OPES tracing SHOULD be...' (29 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 282 has weird spacing: '...ing and enfor...' == Line 324 has weird spacing: '...be able to tr...' == Line 356 has weird spacing: '...ication to th...' == Line 358 has weird spacing: '...e trace ident...' == Line 361 has weird spacing: '...ication of th...' == (6 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An OPES domain MUST not be an OPES sub-system. An OPES domain MUST require external resources to provide services. An OPES domain is a part of an OPES system belonging to a given operator. OPES domains have no incidence on the structure of an OPES system, but they may influence its organization for different reasons such as security, payment, quality of service, delivery parameters among others. -- 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 12, 2003) is 7504 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: '1' is defined on line 522, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 529, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 533, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 536, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 539, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 543, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 557, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 562, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 566, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '2') ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational draft: draft-ietf-opes-protocol-reqs (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-05) exists of draft-ietf-opes-iab-01 ** Downref: Normative reference to an Informational draft: draft-ietf-opes-iab (ref. '9') Summary: 6 errors (**), 0 flaws (~~), 19 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Barbir 3 Internet-Draft Nortel Networks 4 Expires: March 12, 2004 September 12, 2003 6 OPES processor and end points communications 7 draft-ietf-opes-end-comm-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on March 12, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This memo documents tracing requirements for Open Pluggable Edge 38 Services (OPES). 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 43 2. OPES Domain and OPES System . . . . . . . . . . . . . . . . 4 44 3. OPES Tracing . . . . . . . . . . . . . . . . . . . . . . . . 6 45 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . 6 46 3.2 Requirements for Information Related to Traceable 47 Entities? . . . . . . . . . . . . . . . . . . . . . . . . . 7 48 4. Requirements for OPES processors . . . . . . . . . . . . . . 8 49 5. Requirements for callout servers . . . . . . . . . . . . . . 9 50 6. Privacy considerations . . . . . . . . . . . . . . . . . . . 10 51 6.1 Tracing and Trust Domains . . . . . . . . . . . . . . . . . 10 52 7. How to Support Tracing . . . . . . . . . . . . . . . . . . . 11 53 7.1 Tracing and OPES System Granularity . . . . . . . . . . . . 11 54 7.2 Requirements for In-Band Tracing . . . . . . . . . . . . . . 12 55 7.2.1 Tracing Information Granularity and Persistence levels 56 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 57 7.3 Protocol Binding . . . . . . . . . . . . . . . . . . . . . . 13 58 7.4 Tracing scenarios and examples . . . . . . . . . . . . . . . 13 59 8. Optional Notification . . . . . . . . . . . . . . . . . . . 14 60 9. IANA considerations . . . . . . . . . . . . . . . . . . . . 16 61 10. Security Considerations . . . . . . . . . . . . . . . . . . 17 62 Normative References . . . . . . . . . . . . . . . . . . . . 18 63 Informative References . . . . . . . . . . . . . . . . . . . 19 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 65 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 66 Intellectual Property and Copyright Statements . . . . . . . 21 68 1. Introduction 70 The Open Pluggable Edge Services (OPES) architecture [8] enables 71 cooperative application services (OPES services) between a data 72 provider, a data consumer, and zero or more OPES processors. The 73 application services under consideration analyze and possibly 74 transform application-level messages exchanged between the data 75 provider and the data consumer. 77 The execution of such services is governed by a set of rules 78 installed on the OPES processor. The rules enforcement can trigger 79 the execution of service applications local to the OPES processor. 80 Alternatively, the OPES processor can distribute the responsibility 81 of service execution by communicating and collaborating with one or 82 more remote callout servers. As described in [8], an OPES processor 83 communicates with and invokes services on a callout server by using a 84 callout protocol. 86 The work specify the requirements for providing tracing functionality 87 for the OPES architecture [8]. This document specifies tracing 88 mechanisms that the OPES architecture could provide that enable data 89 provider application to detect inappropriate clinet centric actions 90 by OPES entities. The work focus on developing tracing requirements 91 that can be used to fulfil the notification and Non-Blocking 92 requirements [2]. 94 In the OPES architecture document [8], there is a requirement of 95 relaying tracing information in-band. This work investigates this 96 possibility and discusses possible methods that could be used to 97 detect faulty OPES processors or callout servers by end points in an 98 OPES flow. 100 The document is organized as follows: Section 2 defines OPES Domain 101 and OPES System. Section 3 discusses entities that are traceable in 102 an OPES Flow. Sections 4 and 5 discuss tracing requirements for OPES 103 systems and callout servers. Section 6 focus on Tracing and Trust 104 Domains. Section 7 discusses how to support tracing and provides uses 105 cases. Section 8 examines Optional Notofication. Section 9 looks 106 into IANA considerations. Section 10 examines security 107 considerations. 109 2. OPES Domain and OPES System 111 This sections clarifies the terms OPES system and OPES Domain [8]. 112 These terms are needed in order to define what is traceable in an 113 OPES Flow [8]. 115 An OPES domain describes the collection of OPES entities that a 116 single provider operates. OPES domains can be based on trust or other 117 operational boundaries. All elements of an "OPES Domain" MUST be in 118 the same trust domain. This would be independent of any specific OPES 119 flow. 121 An OPES system consists of a limited set of OPES entities, parts of a 122 single or of multiple OPES operators domains, organized by (or on 123 behalf) of either a data provider application or a data consumer 124 application to perform authorized services on a given application 125 message. Each OPES entity in an OPES system MUST be directly 126 addressable on IP level by a data consumer application. 128 An OPES system can be formed in a recursive manner. An OPES system 129 can start with either a data provider application or a data consumer 130 application (for a given message). The OPES system then includes any 131 OPES entity trusted by (accepting authority from) an entity that is 132 already in the OPES system. The trust and authority delegation is 133 viewed in the context of the given application message. 135 As implied by the above definition, some OPES entities in the system 136 may not participate in the processing of a given message. 138 An OPES domain MUST not be an OPES sub-system. An OPES domain MUST 139 require external resources to provide services. An OPES domain is a 140 part of an OPES system belonging to a given operator. OPES domains 141 have no incidence on the structure of an OPES system, but they may 142 influence its organization for different reasons such as security, 143 payment, quality of service, delivery parameters among others. 145 In Figure 1 an OPES Flow is shown that traverses across various OPES 146 Domains. A data consumer application MUST be able to recive tracing 147 information on per message basis that enable it to determine the set 148 of transformations that were perfomed on the data for a particular 149 OPES Flow. The formation of an OPES flow can be static or dynamic, 150 meaning that the determination of which OPES Domains will participate 151 in a given OPES Flow (per message basis) can be a function of 152 business arrangements. 154 +------------------------------------------+ 155 | Data Consumer Application | 156 +------------------------------------------+ 157 ^ 158 | 159 +-------------------------------------------+ 160 | OPES System | O | 161 | | | 162 | +-------------------------+ | P | 163 | | OPES Domain | | | 164 | | +---------------+ | | E | 165 | | | OPES Entity | | | | 166 | | +---------------+ | | S | 167 | | . | | | 168 | | . | | | 169 | | +---------------+ | | F | 170 | | |Callout Server | | | | 171 | | +---------------+ | | L | 172 | | | | | 173 | +-------------------------+ | O | 174 | . | | 175 | . | W | 176 | +-------------------------+ | | 177 | | OPES Domain | | | 178 | | +---------------+ | | | 179 | | | OPES Entity | | | | 180 | | +---------------+ | | | 181 | | . | | | 182 | | . | | | 183 | | +---------------+ | | | 184 | | | OPES Entity | | | | 185 | | +---------------+ | | | 186 | +-------------------------+ | | 187 | v | 188 | +-----------------------------------+ | 189 | | Data Provider Application | | 190 | +-----------------------------------+ | 191 | | 192 +-------------------------------------------+ 194 Figure 1: OPES System 196 3. OPES Tracing 198 Before discussing what is traceable in an OPES flow, it is beneficial 199 to define what tracing means. Tracing is defined as the inclusion of 200 necessary information within a message in an OPES flow that could be 201 used to identify the set of transformations or adpatations that have 202 been performed on its content in an OPES System before its delivery 203 to an end point (the data consumer application). 205 o OPES trace: application message information about OPES entities in 206 an OPES System that adapted that message. 208 o OPES tracing: the process of including, manipulating, and 209 interpreting an OPES trace in an OPES System. 211 To emphasize, the above definition means that OPES tracing SHOULD be 212 performed on per message basis. Trace format is dependent on the 213 application protocol that is being adapted by OPES. Data consumer 214 application can use OPES trace to infer the actions that have been 215 performed by the OPES system. The architecture document requires [8] 216 that tracing be supported in-band. 218 In an OPES System the task of providing tracing information, must 219 take into account the following considerations: 221 o Providers may be hesitant to reveal information about their 222 internal network infrastructure. 224 o Within a service provider network, OPES processors may be 225 configured to use non-routable, private IP addresses. 227 o A Data consumer applications would prefer to have a single point 228 of contact regarding the trace information. 230 o TBD 232 3.1 What is traceable in an OPES Flow? 234 This section focuses on identifying the traceable entities in an OPES 235 Flow. Tracing information MUST be able to provide a data consumer 236 application with useful information without tracing the exact OPES 237 Processor or callout servers that adapted the data. It is up to the 238 OPES service provider to have maintained appropriate internal 239 detailed traces to find the answer to the data consumer applications 240 inquiry. 242 At the implementation level, for a given trace, an OPES entity 243 involved in handling the corresponding application message is 244 "traceable" or "traced" if information about it appears in that 245 trace. OPES entities have different levels of traceability 246 requirements. Specifically, 248 o An OPES system MUST add its entry to the trace. 250 o An OPES processor SHOULD add its entry to the trace. 252 o An OPES service SHOULD add its entry to the trace. 254 o An OPES entity MAY manage trace information from entities that are 255 under its control. For example, an OPES processor may add or 256 remove callout service entries in order to manage the size of a 257 trace. Other considerations include: 259 * The OPES processor may have a fixed configuration that enable 260 it to respond to tracing inquires. 262 * The OPES processor may insert a summary of the services that it 263 controls. The summary can be used to respond to tracing 264 inquiries. 266 * The OPES processor may package tracing information related to 267 the entities that it control based on the policy of a given 268 OPES System. 270 From an OPES context, a good tracing approach is similar to a trouble 271 ticket ready for submission to a known address. The trace in itself 272 is not necessarily a detailed description of what has happened. It is 273 the resposibility of the operator to resolve the problems. 275 3.2 Requirements for Information Related to Traceable Entities? 277 The requirements for information as related to entities that are 278 terceable in an OPES flow are: 280 o The privacy policy at the time it dealt with the message 282 o Identification of the party responsible for setting and enforcing 283 that policy 285 o Information pointing to a technical contact 287 o Information that identifies, to the technical contact, the OPES 288 processors involved in processing the messag 290 o TBD 292 4. Requirements for OPES processors 294 In order to facilitate compliance, the concept of an "OPES system" 295 being traceable, requires that each OPES processor MUST support 296 tracing. Policy can be set that defines which domain has 297 authorization to turn on tracing and its granularity. An OPES 298 provider can have its private policy for trace information, but it 299 MUST support tracing mechanisms and it MUST reveal it's policy. 301 The requirements for OPES processors that are applicatble to tracing 302 are: 304 o Each OPES processor MUST belong to a single OPES Domain. 306 o Each OPES processor MUST have a Unique Identity in that Domain. 308 o Each OPES processor MUST support tracing, policy can be used to 309 turn tracing on and.to determine granuality. 311 o TBD 313 5. Requirements for callout servers 315 If it is the task of an OPES processor to add trace records to 316 application messages, then callout servers that uses the OCP protocol 317 are not affected by tracing requirements. In order for an OCP 318 protocol to be tracing neutral, the OPES server SHOULD be able to 319 meet the following requirements: 321 o Callout services adapt payload regardless of the application 322 protocol in use and leave header adjustment to OPES processor. 324 o OPES processor SHOULD be able to trace it's own invocation and 325 service(s) execution since they understand the application 326 protocol. 328 o Callout servers MAY be able to add their own OPES trace records 329 to application level messages. 331 o TBD 333 6. Privacy considerations 335 6.1 Tracing and Trust Domains 337 A trust domain may include several OPES systems and entities. Within 338 a trust domain, there MUST be at least support for one trace entry 339 per system. Entities outside of that system may or may not see any 340 traces, depending on domain policies or configuration. For example, 341 if an OPES system is on the content provider "side", end-users are 342 not guaranteed any traces. If an OPES system is working inside 343 end-user domain, the origin server is not guaranteed any traces 344 related to user requests. 346 7. How to Support Tracing 348 In order to support tracing, the following aspects must be addressed: 350 o There MUST be a System Identifier that identify a domain that is 351 employing an OPES system. 353 o An OPES processor MUST be able to be uniquely identified (MUST 354 have an Identifier) within a system. 356 o An OPES processor MUST add its identification to the trace. 358 o An OPES processor SHOULD add to the trace identification of every 359 callout service that received the application message. 361 o An OPES processor MUST add to the trace identification of the 362 "system/entity" it belongs to. "System" ID MUST make it possible 363 to access "system" privacy policy. 365 o An OPES processor MAY group the above information for sequential 366 trace entries having the same "system/entity" ID. In other words, 367 trace entries produced within the same "system/entity" MAY be 368 merged/aggregated into a single less detailed trace entry. 370 o An OPES processor MAY delegate trace management to a callout 371 service within the same "system/entity". 373 TBD 375 7.1 Tracing and OPES System Granularity 377 There are two distinct uses of traces. First, is to SHOULD enable the 378 "end (content producer or consumer) to detect OPES processor presence 379 within end's trust domain. Such "end" should be able to see a trace 380 entry, but does not need to be able to interpret it beyond 381 identification of the trust domain(s). 383 Second, the domain administrator SHOULD be able to take a trace entry 384 (possibly supplied by an "end? as an opaque string) and interpret it. 385 The administrator must be able to identify OPES processor(s) involved 386 and may be able to identify applied adaptation services along with 387 other message-specific information. That information SHOULD help to 388 explain what OPES agent(s) were involved and what they did. It may be 389 impractical to provide all the required information in all cases. 390 This document view a trace record as a hint, as opposed to an 391 exhaustive audit. 393 Since the administrators of various trust domains can have various 394 ways of looking into tracing, they MAY require the choice of freedom 395 in what to put in trace records and how to format them. Trace records 396 should be easy to extend beyond basic OPES requirements. Trace 397 management algorithms should treat trace records as opaque data to 398 the extent possible. 400 It is not expected that entities in one trust domain to be able to 401 get all OPES-related feedback from entities in other trust domains. 402 For example, if an end-user suspects that a served is corrupted by a 403 callout service, there is no guarantee that the use will be able to 404 identify that service, contact its owner, or debug it _unless_ the 405 service is within my trust domain. This is no different from the 406 current situation where it is impossible, in general, to know the 407 contact person for an application on an origin server that generates 408 corrupted HTML; and even if the person is known, one should not 409 expect that person to respond to end-user queries. 411 7.2 Requirements for In-Band Tracing 413 The OPES architecture [8] states that traces must be in-band. The 414 support of this design specification is dependent on the specifics of 415 the message application level protocol that is being used in an OPES 416 flow. In-band tracing limits the type of application protocols that 417 OPES can support. The details of what a trace record can convey is 418 also dependent on the choice of the application level protocol. 420 For these reasons, the work will document requirements for 421 application protocols that need to support OPES traces. However, the 422 architecture does not prevent implementers of developing out-of-band 423 protocols and techniques to address the above limitation. 425 7.2.1 Tracing Information Granularity and Persistence levels 426 Requirements 428 In order to be able to trace entities that have acted on an 429 application message in an OPES flow, there may be requirements to 430 keep information that is related to the following: 432 o Message-related informatio: All data that describes specific 433 actions performed on the message SHOULD be provided with that 434 message, as there is no other way to find message level details 435 later. 437 o Session related information: Session level data MUST be preserved 438 for the duration of the session. OPES processor is responsible for 439 inserting notifications if session-level information changes. 441 o End-point related data: What profile is activated? Where to get 442 profile details? Where to set preferences? 444 o TBD 446 7.3 Protocol Binding 448 How tracing is added is application protocol-specific and will be 449 documented in separate drafts. This work documents what tracing 450 information is required and some common tracing elements. 452 7.4 Tracing scenarios and examples 454 TBD 456 8. Optional Notification 458 This section examines IAB [2] considerations (3.1) and (3.2) 459 regarding notification in an OPES architecture. 461 Notification propagates in opposite direction of tracing and cannot 462 be attached to application messages that it notifies about. 463 Notification can be done out-band and may require the development of 464 a new protocol. The direction of data flow for tracing and 465 notification are depicted in Figure 2. 467 Notification 468 +----------------------------------------------- 469 | | 470 | V 471 +---------------+ +-------+ +---------------+ 472 | | | | | Data Provider | 473 | Data Consumer | Tracing | OPES |<----->| Application | 474 | Application |<-----------| | +---------------+ 475 +---------------+ +-------+ 476 ^ 477 |OCP 478 | 479 V 480 +---------+ 481 | Callout | 482 | Server | 483 +---------+ 485 Figure 2: Notification Flow 487 In [9] it was argued that Notification is an expensive approach for 488 providing tracing information. However, the current work does not 489 prevent an OPES System from publishing policy and specifications that 490 allow Optional Notification. For example, an OPES System can adopt a 491 mechanism that uses a flag that would allow a data consumer and a 492 data provider application to signal to each other that they are 493 interested to receive an explicit notification if an OPES service is 494 applied to a specific message. The value of this optional flag/field 495 can be a URI that identifies notification method plus parameters. If 496 a processor understands the method, it would be able to further 497 decode the field and send a notification. The specification of the 498 field name and format for an application protocol can be stated in 499 the associated binding document. The details of the notification 500 protocol is beyond the scope of this Working Group. 502 For example, the following HTTP header: 504 o OPES-Notify: URI *(pname=pvalue) 506 Or, 508 o My-OPES-Notify: foo=bar q=0.5 510 can be used. 512 9. IANA considerations 514 TBD 516 10. Security Considerations 518 TBD 520 Normative References 522 [1] McHenry, S., et. al, "OPES Scenarios and Use Cases", 523 Internet-Draft TBD, May 2002. 525 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 526 Considerations for Open Pluggable Edge Services", RFC 3238, 527 January 2002. 529 [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 530 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 531 HTTP/1.1", RFC 2616, June 1999. 533 [4] OPES working group, "OPES Service Authorization and Enforcement 534 Requirements", Internet-Draft TBD, May 2002. 536 [5] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD, 537 May 2002. 539 [6] A. Beck et al., "Requirements for OPES Callout Protocols", 540 Internet-Draft http://www.ietf.org/internet-drafts/ 541 draft-ietf-opes-protocol-reqs-03.txt, December 2002. 543 [7] A. Barbir et al., "Security Threats and Risks for Open Pluggable 544 Edge Services", Internet-Draft http://www.ietf.org/ 545 internet-drafts/draft-ietf-opes-threats-00.txt, October 2002. 547 [8] A. Barbir et al., "An Architecture for Open Pluggable Edge 548 Services (OPES)", Internet-Draft http://www.ietf.org/ 549 internet-drafts/draft-ietf-opes-architecture-04, December 2002. 551 [9] A. Barbir et al., "OPES Treatment of IAB Considerations", 552 Internet-Draft http://www.ietf.org/internet-drafts/ 553 draft-ietf-opes-iab-01.txt, February 2004. 555 Informative References 557 [10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 558 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. 559 Waldbusser, "Terminology for Policy-Based Management", RFC 560 3198, November 2001. 562 [11] L. Cranor, et. al, "The Platform for Privacy Preferences 1.0 563 (P3P1.0) Specification", W3C Recommendation 16 http:// 564 www.w3.org/TR/2002/REC-P3P-20020416/ , April 2002. 566 [12] "Hit Metering", RFC . 568 Author's Address 570 Abbie Barbir 571 Nortel Networks 572 3500 Carling Avenue 573 Nepean, Ontario K2H 8E9 574 Canada 576 Phone: +1 613 763 5229 577 EMail: abbieb@nortelnetworks.com 579 Appendix A. Acknowledgements 581 TBD 583 Intellectual Property Statement 585 The IETF takes no position regarding the validity or scope of any 586 intellectual property or other rights that might be claimed to 587 pertain to the implementation or use of the technology described in 588 this document or the extent to which any license under such rights 589 might or might not be available; neither does it represent that it 590 has made any effort to identify any such rights. Information on the 591 IETF's procedures with respect to rights in standards-track and 592 standards-related documentation can be found in BCP-11. Copies of 593 claims of rights made available for publication and any assurances of 594 licenses to be made available, or the result of an attempt made to 595 obtain a general license or permission for the use of such 596 proprietary rights by implementors or users of this specification can 597 be obtained from the IETF Secretariat. 599 The IETF invites any interested party to bring to its attention any 600 copyrights, patents or patent applications, or other proprietary 601 rights which may cover technology that may be required to practice 602 this standard. Please address the information to the IETF Executive 603 Director. 605 Full Copyright Statement 607 Copyright (C) The Internet Society (2003). All Rights Reserved. 609 This document and translations of it may be copied and furnished to 610 others, and derivative works that comment on or otherwise explain it 611 or assist in its implementation may be prepared, copied, published 612 and distributed, in whole or in part, without restriction of any 613 kind, provided that the above copyright notice and this paragraph are 614 included on all such copies and derivative works. However, this 615 document itself may not be modified in any way, such as by removing 616 the copyright notice or references to the Internet Society or other 617 Internet organizations, except as needed for the purpose of 618 developing Internet standards in which case the procedures for 619 copyrights defined in the Internet Standards process must be 620 followed, or as required to translate it into languages other than 621 English. 623 The limited permissions granted above are perpetual and will not be 624 revoked by the Internet Society or its successors or assignees. 626 This document and the information contained herein is provided on an 627 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 628 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 629 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 630 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 631 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 633 Acknowledgment 635 Funding for the RFC Editor function is currently provided by the 636 Internet Society.