idnits 2.17.1 draft-erickson-opes-taxonomy-00.txt: -(82): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(99): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(100): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(161): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(168): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(174): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(211): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(248): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(251): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 Internet-Drafts being working documents. == There are 15 instances of lines with non-ascii characters in the document. == 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 Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 59 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 222 has weird spacing: '...ibed in his...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 248, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 251, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 254, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 257, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Erickson 2 INTERNET DRAFT Intel Corporation 3 Expires: August 2001 H. Orman 4 Novell 6 OPES Network Taxonomy 7 draft-erickson-opes-taxonomy-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document presents the different models for deployment of OPES 31 boxes. This document will attempt to clarify the different 32 owners/users of an OPES box in order to provide a framework for 33 discussing our observed services, trust relationships and working 34 environments. Hopefully, this document will give a common framework 35 for discussing and defining policy issues for networks using OPES 36 boxes. 38 Table of Contents 40 Status of this Memo..................................................1 41 Abstract.............................................................1 42 Table of Contents....................................................2 43 1. Introduction......................................................3 44 2. OPES Use..........................................................5 45 2.1 Content Provider and Hosting ISP.................................5 46 2.2 CDN Service......................................................5 47 2.3 Access ISP.......................................................6 48 2.4 Client...........................................................6 49 2.5 Proposed Questions...............................................6 50 4. Intellectual Property.............................................7 51 5. Acknowledgments...................................................7 52 6. References........................................................7 53 7. Disclaimer........................................................7 54 8. Author's Address..................................................8 55 9. Full Copyright Statement..........................................8 56 1. Introduction 57 There have been several example uses of OPES boxes (e.g. those found in 58 draft-beck-opes-esfnep-01.txt) that often imply very different 59 operating environments for the OPES box. In general, the current 60 working model of the Internet would place proxy boxes under four 61 different owners (and therefore three different usage models). 63 The primary owners identified are: Content Provider (or origin 64 websites), Content Delivery Networks (CDN), Clients, and of course 65 ISP�s providing both access for a client and hosting for a Content 66 Provider. Here is a diagram of this framework. 68 <========= Content Oriented # Browser Oriented ================> 69 # 70 +----------+ +---------+ # +-------------+ +-------------+ 71 | Content | | CDN | # | Access | | Client | 72 | Provider |--->| |---#-->| ISP |--->| | 73 | | | | # | | | | 74 |(web |<---| (cache |<--#---|(cache |<---|(fwd | 75 | srv)(rev | | arrays)| # | arrays)(fwd | | pxy) (client| 76 | pxy)| | | # | pxy)| | apps)| 77 +----------+ +---------+ # +-------------+ +-------------+ 78 # 79 INBOUND <====================#=======================> OUTBOUND 81 Any of the proxy or cache boxes may be a OPES box, as well as several 82 boxes not shown � however, any others will most likely also be owned by 83 one of the 5 parties. 85 This diagram still does not show any possible remote callout servers 86 (e.g. iCAP servers) that may exist. Also note that this shows 87 ownership rather than location � i.e. a CDN will often have cache 88 arrays co-located at an ISP. And, of course, there are several 89 examples of a single entity playing multiple roles (e.g. AOL acting as 90 a Content Provider, Hosting ISP, CDN and Access ISP). 92 The dividing line represents a likely point of separation of services 93 being offered specifically for either the Client or Content Provider. 94 For instance, the Access ISP is likely to offer content filtering or 95 virus checking to their customers (the clients) where the Hosting ISP 96 or CDN would have no reason to offer these services, since their 97 customer would be the Content Provider. 99 One other limitation is this diagram shows the Internet as it �is�, 100 rather than how it �will be� (though, perhaps �may be� would be a 101 better term). In the future we will quite likely see a simpler model 102 more along the lines of cable television, with a small set of Content 103 Providers, and companies acting as both distributors and access 104 provider, and in fact even owning the browsing equipment for the 105 client. This would, in fact, look more like this: 107 +----------+ 108 | +----------+ +------------------------------------+ 109 | | +----------+ | Distributor | 110 | | | Content | | +------+ | 111 | | | Provider |--------->| (rev (cache (fwd |+------+ | 112 | | | | | pxy) arrays) pxy) +|+------+ | 113 | | |(web |<---------| +|client| | 114 +-| | srv)(rev | | +------+ | 115 +-| pxy)| +------------------------------------+ 116 +----------+ 118 In any event, this represents a fairly complete set of possible proxy- 119 points where an OPES extension could be installed. 121 2. OPES Use 122 Now that there is a breakdown of the concerned parties, the services 123 that each OPES box owner will likely use or provide can be identified. 124 The following table shows the example services provided by draft-beck- 125 opes-esfnep-01.txt, and the parties that would likely offer them: 127 Content CDN Access Client 128 Provider Service ISP 129 and 130 Hosting 131 ISP 132 Virus Scanning X X 133 Insertion of Ad Banners X X X 134 Insertion of Regional 135 Data X X 136 Caching of 137 Personalized/Customized X X 138 Web Pages 139 Content Adaptation for 140 Alternate Web Access X X X 141 Devices 142 Limited Client 143 Bandwidth Adaptation X X X 144 Adaptation of Streaming X 145 Media X 146 Request Filtering X X 147 Request Filtering 148 through Content X 149 Analysis 150 Creation of User X X X 151 Profiles 152 Search Engine Index on 153 Cached Web Pages X X X 154 Language Translation X X X X 156 This table was built using the following assumptions about the concerns 157 and priorities of the owners of the OPES boxes. 159 2.1 Content Provider and Hosting ISP 160 OPES Boxes owned by the Content Provider or the Hosting ISP will most 161 likely be under the Content Provider�s control, or will at least be 162 providing services for the Content Provider. 164 2.2 CDN Service 165 OPES Boxes owned by the CDN (or a set of CDN�s in a peering 166 relationship) will be setup to handle content for their customers (the 167 content providers), and therefore will probably have features for the 168 content providers, along with any service they can add for the CDN�s 169 own revenue. 171 2.3 Access ISP 172 Currently, it is unlikely that OPES Boxes owned by an Access ISP would 173 provide services for the Content Provider (or CDN), due to the 174 proliferation of ISP�s and the large number of service agreements that 175 would have to be reached. 177 Therefore, the Access ISP will be using OPES boxes for services for 178 their own revenue (Ad banners), and for services they could provide 179 their customers (Virus Scanning, Filtering, et al), but also for 180 services they could provide selected content providers (Bandwidth 181 adaptation, Regional data, User profiles, et al). 183 2.4 Client 184 OPES Boxes owned by the Client�s themselves (primarily corporate 185 enterprises, libraries, internet cafes, etc) will offer services 186 oriented only towards the clients. 188 2.5 Proposed Questions 189 The document was created primarily to setup a framework for discussing 190 OPES services and how they would be used. However, here are a few of 191 the questions do present themselves: 193 1. What trust relationships must exist? 194 . Are all modules loaded by an administration box controlled by 195 the OPES box owner. 196 . 197 2. What security measures must exist? 198 . If security measures (such as AAA) are in place, to whom are we 199 providing secure access for? Only the owner of the box, or 200 would other trusted parties have access? 201 3. Is there any limit on functionality for proxylets from outside 202 sources? 203 . Sandboxing a java-based proxylet to disallow file access or 204 socket connections. 205 . Disallowing access to remote callout servers outside of the 206 domain. 207 4. Are there other frameworks that are currently in place or soon 208 will be? 209 5. How do we provide standardized accounting across ownership 210 domains? 211 . E.g. an ISP or CDN providing �page hit� counts to a Content 212 Provider. 213 . E.g. the usage of an OPES proxylet. 214 . Would this simply be a set of services implemented on OPES, or 215 must OPES address this directly? Perhaps a set of services 216 could be provided by OPES to facilitate accounting. 218 4. Intellectual Property 220 The IETF takes no position regarding the validity or scope of any 221 intellectual property or other rights that might be claimed to pertain 222 to the implementation or use of the technology described in his 223 document or the extent to which any license under such rights might or 224 might not be available; neither does it represent that it has made any 225 effort to identify any such rights. Information on the IETF's 226 procedures with respect to rights in standards-track and standards- 227 related documentation can be found in BCP-11. 229 Copies of claims of rights made available for publication and any 230 assurances of licenses to be made available, or the result of an 231 attempt made to obtain a general license or permission for the use of 232 such proprietary rights by implementers or users of this specification 233 can be obtained from the IETF Secretariat. 235 The IETF invites any interested party to bring to its attention any 236 copyrights, patents or patent applications, or other proprietary rights 237 which may cover technology that may be required to practice this 238 standard. Please address the information to the IETF Executive 239 Director. 241 5. Acknowledgments 243 The author would like to thank Michael Condry, Lily Yang, Christian 244 Maciocco and Manasi Bhutani for their contributions to this OPES 245 ownership model. 247 6. References 248 [1] Tomlinson, G., and al., �Extensible Proxy Services Framework�, 249 Internet-Draft work in progress. 251 [2] Yang, L., and al., �OPES Architecture for Rule Processing and 252 Service Execution�, Internet-Draft work in progress. 254 [3] Beck, A., and M. Hofmann, "Proxy Specification Rule Language", 255 Internet-Draft work in progress. 257 [4] Maciocco, C., and al., " OPES Meta-data Markup Language � 258 OMML ", Internet-Draft work in progress. 260 7. Disclaimer 262 The views and specification herein are those of the authors and are not 263 necessarily those of their employer. The authors and their employer 264 specifically disclaim responsibility for any problems arising from 265 correct or incorrect implementation or use of this specification. 267 8. Author's Address 269 Robert Erickson 270 Intel Corporation 271 MS JF3-206 272 2111 NE 25th Ave. 273 Hillsboro, OR 97124 274 Phone: +1-503-712-2016 275 E-Mail: Rob.Erickson@intel.com 277 9. Full Copyright Statement 279 Copyright (C) The Internet Society (1999). All Rights Reserved. 281 This document and translations of it maybe copied and furnished to 282 others, and derivative works that comment on or otherwise explain it or 283 assist in its implementation may be prepared, copied, published and 284 distributed, in whole or in part, without restriction of any kind, 285 provided that the above copyright notice and this paragraph are 286 included on all such copies and derivative works. However, this 287 document itself may not be modified in any way, such as by removing the 288 copyright notice or references to the Internet Society or other 289 Internet organizations, except as needed for the purpose of developing 290 Internet standards in which case the procedures for copyrights defined 291 in the Internet Standards process must be followed, or as required to 292 translate it into languages other then English. 294 The limited permissions granted above are perpetual and will not be 295 revoked by the Internet Society or its successors or assigns. 297 This document and the information contained herein is provided on an 298 "AS IS" basis and THE INTERNET SOCIETY AND THEINTERNET ENGINEERING TASK 299 FORCE DISCLIAMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 300 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMAITON HEREIN WILL NOT 301 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTEIS OF MERCHANTABILITY OR 302 FITNESS FOR A PARTICULAR PURPOSE.