idnits 2.17.1 draft-jacquenet-ip-vpn-needs-00.txt: ** The Abstract section seems to be numbered 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Abstract' ) ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6.1.3. Security considerations' ) ** 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 an Authors' Addresses Section. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([VPN-FRAME], [TAXONOMY], [RFC-2026], [RFC-2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 91 has weird spacing: '...rs, and which...' == Line 205 has weird spacing: '... of the sco...' == Line 345 has weird spacing: '...nerally consi...' == Line 491 has weird spacing: '...ntioned resou...' == Line 495 has weird spacing: '...service man...' == (1 more instance...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC-2026' on line 553 looks like a reference -- Missing reference section? 'VPN-FRAME' on line 38 looks like a reference -- Missing reference section? 'TAXONOMY' on line 560 looks like a reference -- Missing reference section? 'RFC-2119' on line 555 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Jacquenet 2 INTERNET-DRAFT France Telecom R & D 3 Document: draft-jacquenet-ip-vpn-needs-00.txt 4 Category: informational 5 Expires: January 2001 7 Functional requirements for the deployment of an IP VPN service 8 offering 9 11 1. Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026 ([RFC-2026]). 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 This document aims at identifying the requirements which should be 35 taken into consideration by a service provider, when considering the 36 deployment of an IP VPN service offering. From this perspective, 37 this document does not specify any technical means which could be 38 used to deploy an IP VPN service offering, unlike the [VPN-FRAME] 39 document. 41 This document tries to express a service provider perspective, 42 according to its own experience of IP-based service offerings, and 43 to its own perception of the (constantly) evolving needs of the 44 customers of such services. To some extent, this document can be 45 viewed as a complementary taxonomy effort of the [TAXONOMY] draft. 47 3. Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 51 this document are to be interpreted as described in RFC 2119 ([RFC- 52 2119]). 54 4. Glossary 55 CPE: Customer Premises Equipment. 56 Customer: See " subscriber ". 57 SLA: Service Level Agreement. A SLA is a contractual document 58 which a subscriber and a service provider have 59 agreed upon. 60 SLS: Service Level Specification. A SLS is the technical and 61 detailed specification of an SLA. 62 SMFA: Specific Management Functional Area, such as 63 configuration management, performance management, 64 security management, alarm management and accounting 65 management. 66 SoHo: Small office Home office. 67 Subscriber:A subscriber (or a customer) is a legal representative 68 who has the (legal) ability to subscribe to a service 69 offering. 70 User: A user is an entity (a human being or a process, from a 71 general perspective) who has been named by a subscriber 72 and appropriately identified by a service provider, so 73 that he might benefit from a service according to his 74 associated rights and duties. 75 VPN: Virtual Private Network. A collection of switching 76 resources (namely routers) and transmission resources 77 which will be used over an IP backbone to process the IP 78 traffic which will reflect the data oriented- 79 communication service of an enterprise (VPNs which are 80 designed to support intranet-based applications) or a set 81 of enterprises (VPNs which are designed to support 82 extranet-based applications). An IP VPN may also provide 83 an access to the Internet, from a service offering 84 perspective. 86 5. Some basic definitions 88 5.1. What's an IP VPN ? 90 An IP VPN is a set of IP switching and transmission resources which 91 is dedicated to the use of a set of authorized users, and which is 92 deployed over a public IP backbone. 94 5.2. What's an IP VPN service offering ? 96 An IP VPN service offering is one of the services which may be 97 provided by a service provider, and which consists in engineering, 98 deploying and managing one or more IP VPN(s) for the corresponding 99 subscriber, and according to the needs which have been expressed by 100 this subscriber before the contractual agreement has been signed 101 between the subscriber and the service provider, AND during the 102 contractual lifetime of the above-mentioned agreement. 104 5.3. The customers of an IP VPN service offering 106 An IP VPN service offering is designed to address some of the needs 107 of the corporate enterprises. From that perspective, an IP VPN 108 service offering will have to consider the following categories of 109 subscribers: 111 - a single enterprise which may subscribe to the IP VPN service 112 offering to exclusively address its internal data communication 113 needs, within the context of running intranet applications; 115 - a set of enterprises which may subscribe to the IP VPN service 116 offering to exclusively address their data communication needs 117 between themselves, within the context of running extranet 118 applications. Some or all of these enterprises may also subscribe to 119 the IP VPN service offering to address their own internal data 120 communication needs, without any kind of interference. 122 In any case, the subscriber of an IP VPN service offering is an 123 administrative entity which has been granted to represent an 124 enterprise or a set of enterprises, at least from a legal 125 perspective. Subscribing to an IP VPN service offering also means 126 that there will be at least one IP VPN which will be deployed for 127 the subscriber. 129 5.4. The users of an IP VPN service offering 131 The users of an IP VPN service offering are the human beings (or 132 processes) which will communicate with other human beings (or 133 processes) thanks to the use of workstations (PCs, Unix 134 workstations, whatever) to exchange information between them by 135 using the resources of the IP VPN service offering. From this 136 perspective, the users can be classified into two categories: 138 - static users, i.e. users who will communicate with the other users 139 (or part of) by using the resources of the IP VPN service offering 140 without moving from their office and by always using the same 141 workstation. This office can be precisely identified, at least 142 according to some basic geographical considerations; 144 - mobile users, i.e. users who will communicate with the other users 145 (or part of) by using the resources of the IP VPN service offering 146 wherever they may be and, more precisely, one can distinguish: 148 * the mobile users who may move within a single location among the 149 various locations which will be used/granted by the IP VPN service 150 offering subscriber (e.g. one of the sites of a given enterprise 151 which will be interconnected by at least one IP VPN which is part of 152 the contract the subscriber and the IP VPN service provider have 153 agreed upon). That kind of mobile user may use a given set of 154 workstations within the above-mentioned location and may make use of 155 the IP VPN service offering resources only when moving within this 156 location; 157 * the mobile users who may move between the set of (or part of) 158 locations which will be used/granted by the IP VPN service offering 159 subscriber. That kind of mobile user may make use of the IP VPN 160 service offering resources only when moving within this set of 161 locations; 162 * the mobile users who may make use of the IP VPN service offering 163 resources wherever they may be, including accessing these resources 164 through the Internet network or from their home, within the context 165 of SoHo workers. 167 6. Description of the requirements for an IP VPN service offering 169 6.1. Architectural considerations 171 6.1.1. The network components of an IP VPN service offering 173 According to the definition which has been given in chapter 5.1, the 174 network components of an IP VPN service offering will have to 175 process the IP traffic that will be exchanged between the users of 176 the IP VPN service offering, and that will reflect the use of an as 177 widest as possible range of applications, ranging from electronic 178 mail to video-conferencing applications. 180 Moreover, since an IP VPN service offering will have to consider the 181 connection of sites which may belong to an enterprise (or a set of 182 enterprises), there should be no kind of limitation in terms of 183 link-layer-based access technology (1), such as PSTN, ISDN, xDSL, 184 leased line, ATM, Frame Relay, etc. If there is such a limitation, 185 this will have to be clearly and precisely stated when defining the 186 technical specifications of the IP VPN service offering. 188 From this access perspective, it should be possible to provide a 189 back-up capability (2) whenever the primary access link from a site 190 to one of the IP VPN(s) which may have been deployed for the 191 subscriber fails to be operational. 193 As far as IP traffic is concerned, an IP VPN service offering will 194 obviously make use of an IP forwarding and routing global resource 195 which may be distributed among various locations, including customer 196 and service provider premises. Nevertheless, since an IP VPN service 197 offering belongs to the range of internetworking service offerings 198 which are (to be) provided by a service provider, the limit of 199 responsibility will have to be clearly identified between both 200 parties - namely the customer and the IP VPN service provider. 202 (1): considering the link layer technology which is used (or yet to 203 be used) by the IP backbone which will support the IP VPNs that will 204 be deployed within the context of an IP VPN service offering is, by 205 definition, out of the scope of this document. Nevertheless, the 206 engineering characteristics of such an IP backbone will have to be 207 taken into account when specifying the IP VPN service offering. 209 (2): this back-up capability should obviously be as dynamic as 210 possible, i.e. the back-up link should be dynamically established as 211 soon as the primary access link fails to be operational, and should 212 become dynamically idle as soon as the primary access link comes 213 back up. 215 6.1.1.1. Numerical considerations 216 The dimensioning considerations which may characterize an IP VPN 217 service offering can be expressed as the number of expected 218 customers, the number of expected users per customer, and/or the 219 number of expected IP VPNs to be deployed. 220 From that perspective, the technical specification of an IP VPN 221 service offering should consider the following assumptions: 223 - it should be possible to deploy more than one IP VPN per 224 subscriber, especially when considering the IP layer as the multi- 225 service layer of the subscriber; 226 - the number of sites which may be interconnected by a given IP VPN 227 is obviously a function of the size of the subscriber (in terms of 228 turnover or number of employees, for example), and it may also 229 reflect the organization of the subscriber (e.g. national banks 230 which are composed of thousands of agencies which may have a 231 permanent access to a central site, and a record manufacturing 232 company, which may have a couple of production sites, an R and D 233 location, and its headquarters). From that perspective, the number 234 of sites may dramatically vary from one subscriber to another, 235 typically ranging from 2 or 3 sites, up to several thousands of 236 locations, both national and international. 238 6.1.1.2. Permanent access and temporary access 240 The IP VPN service offering should allow both permanent and 241 temporary access (to one or several IP VPNs) for its users, 242 according to their very own rights (see the corresponding " security 243 considerations " chapter). Once again, there should be no limitation 244 in the type of access technology which may be used as the IP 245 transportation technology. 247 6.1.1.3. IP traffics considerations 249 The IP VPN service offering should handle any kind of IP traffic - 250 namely broadcast, anycast, multicast and unicast, and may also have 251 the ability to activate the appropriate filtering capabilities 252 whenever required, and whatever the filter may be, upon request of 253 the customer. 255 An example of such a request would consist in optimizing as far as 256 possible the time needed for an authorized user to become a member 257 of a video-conferencing service according to some specific 258 scheduling requirements which may have an impact on the processing 259 functions of the corresponding IP multicast trafic (wherever these 260 functions may be located), if the video-conferencing application has 261 been built so that it may gracefully benefit from the activation of 262 such multicast processing capabilities. 264 6.1.1.4. IP numbering schemes considerations 266 The IP VPN service offering should gracefully take care of the 267 following cases : 269 - the subscriber has deployed its own private numbering scheme on 270 every location which may benefit from the IP VPN service offering, 271 and this IP numbering scheme should never be changed in any case; 273 - the subscriber has deployed a globally unique IP numbering scheme 274 composed of public IP addresses which have been delivered by the 275 IANA; 277 - the subscriber has deployed NO IP numbering scheme, and has made 278 no specific request either : in this case, the IP VPN service 279 offering should be able to address this need, whatever the 280 corresponding provisioning may be (i.e. private and/or public - 281 including an IPv6-based numbering scheme, if appropriate). 283 The IP VPN service offering should also provide the following 284 capabilities: 285 - a dynamic IP address allocation mechanism whenever requested by 286 the user, and whatever the access may be, i.e. either permanent or 287 temporary; 289 - an IP numbering scheme outsourcing feature, which may consist for 290 the service provider in managing the IP numbering scheme which has 291 been deployed by or allocated to the subscriber, including the 292 multicast addressing scheme. 294 The appropriate DNS service which may be provided to the subscriber 295 will have to be taken into consideration as well, whenever 296 appropriate (e.g. when connecting a new location to one of the IP 297 VPNs which have been deployed for the subscriber). 299 6.1.1.5. Accessing the Internet 301 The IP VPN service offering may also provide an access to the 302 Internet network for all the authorized users which have been 303 declared by the subscriber(3). 305 The IP VPN(s) which may be deployed for the subscriber may either 306 process the corresponding IP traffic (i.e. the traffic which is 307 destined to or comes from the Internet network) or reject the 308 corresponding traffic thanks to the activation of the appropriate 309 filtering capabilities (4). 311 (3): the subscriber may also request that some of his " Web-based 312 communication" servers which would be installed in one of the sites 313 connected to one of his IP VPNs, might be accessed from the Internet 314 network. This probably yields some security considerations which are 315 detailed in paragraph 6.1.3. of the present document. 317 (4): it's important to note that BOTH cases (at least one of the IP 318 VPNs which have been deployed for the subscriber will process the 319 "Internet" traffic, or none of these IP VPNs will process the 320 "Internet" traffic) may very well correspond to the " Internet 321 access " capability (or, more suitably, option) of the IP VPN 322 service offering. 324 6.1.1.6. Migration considerations 326 Subscribers of the IP VPN service offering who have already deployed 327 their own private network (whatever the technology) should not 328 suffer from migration considerations (whatever they are), when 329 evolving from the above-mentioned network towards one or more IP 330 VPNs. This migration should be as smooth as possible, both from an 331 economical and technical perspectives. 333 6.1.2. Quality of service considerations 335 6.1.2.1. The basic nature of applications 337 Applications that may be run over the IP VPN(s) which has(ve) been 338 deployed for the subscriber can be classified into two categories 339 (it is obviously the responsibility of the subscriber to decide 340 whether an application is "critical" or "not that critical"): 342 - there are applications which are critical either to delay, jitter, 343 throughput or reliability (or a combination of the above-mentioned 344 criteria). Real-time applications (such as voice over IP) are 345 generally considered as sensitive applications, for example; 346 - there are applications which are not that critical, i.e. they can 347 accept an affordable degradation when being transmitted, even from a 348 user perspective. For example, a transaction process thanks to the 349 use of the Telnet protocol can accept some delay variations (which 350 may even cause the loss of a given set of datagrams), because the 351 integrity of the transaction is not that damaged, especially when 352 considering the fact that the Telnet protocol relies upon the TCP 353 layer. On the other hand, the loss of a single IP datagram during an 354 FTP-based file transfer may have a dramatic impact on the integrity 355 of the file, so that the user could simply be unable to use this 356 file. 358 This critical/not that critical kind of typology for the 359 applications which are to be run over the IP VPN(s) which will be 360 deployed for a given subscriber will have to be taken into account 361 by the IP VPN service offering, at least from a quality of service 362 perspective, so that it will have to consider the deployment of QOS- 363 based IP VPNs. 365 6.1.2.2. Dealing with congestion 367 Whenever a congestion is experienced in the IP backbone which will 368 support the IP VPNs (and wherever this congestion may take place), 369 it may affect the transmission of the IP datagrams. Some of these 370 datagrams will reflect the activation of sensitive applications, 371 others will reflect the activation of not-that-sensitive 372 applications. 374 It is therefore the responsibility of the IP VPN service provider to 375 provide any means which may be appropriate so that: 377 - sensitive applications-based IP datagrams will never have to 378 suffer from any kind of congestion, either in the IP VPN which 379 processes such datagrams, or somewhere in the IP backbone, provided 380 it has been clearly stated (by any means appropriate) that the 381 responsibility of such a congestion is the IP VPN service provider's 382 responsibility. This means that no such datagrams will be lost 383 during their transmission over the IP VPN, which yields the notion 384 of quality of service guarantees for such datagrams. Such guarantees 385 will have to be expressed in terms of QOS indicators, and these 386 indicators will have to be as precisely as possible defined and 387 measured on a regular basis (e.g. one month), so that they might be 388 used as part of the contract which will be signed between the 389 subscriber and the service provider; 391 - not-that-sensitive applications-based IP datagrams may 392 occasionally suffer from any kind of congestion. This "suffering" 393 might be expressed in terms of classes of service, which may allow 394 the service provider to: 396 * process (i.e. transmit) some datagrams more rapidly than others, 397 according to a scheduling policy which may be part of the contract 398 between the subscriber and the service provider; 399 * discard some datagrams rather than others, according to a 400 discarding policy which may be part of the contract between the 401 subscriber and the service provider; 402 * commit in providing a maximum loss rate (or some equivalent 403 indicator), which may vary according to the number of classes of 404 service that may be defined and activated by the service provider 405 within the network resources he's responsible of (e.g. a one out of 406 a thousand datagrams for the "economy" class of service, a one out 407 of a million datagrams for the "business" class of service, and a 408 one out of a billion datagrams for the "first" class of service). 409 6.1.2.3. Service guarantees 411 According to what has been mentioned in the above chapter, the IP 412 VPN service provider will have to commit in some specific service 413 guarantees which will be part of the contract that will be signed 414 between the subscriber and the service provider. This yields the 415 notion of SLA both parties will have to agree upon, and the 416 corresponding specification is the SLS. 418 The IP VPN service offering should therefore have the ability to 419 provide a range of SLAs/SLSes to address the needs of its 420 subscribers. 422 6.1.3. Security considerations 424 6.1.3.1. Identifying and authenticating the users 426 The IP VPN(s) to be deployed will be used by human beings (or 427 processes) who will have to be precisely authorized and 428 authenticated. In other words, the IP VPN service offering will have 429 to provide any appropriate means which will help both parties in 430 being convinced that no unexpected/unauthorized user will access the 431 IP VPN resources which might be deployed for the subscriber. 433 Identifying the user means that the service provider will have to 434 provide an as precise as possible answer to the following question: 435 "who does the (requesting) user claim to be ?" 437 Authenticating the user means that the service provider will have to 438 provide an as precise as possible answer to the following question: 439 "since the identity of the user has been (somewhat) confirmed (by 440 answering to the previous question), who is the actual human being 441 according to the identification information he has provided and what 442 are his rights ?" 444 6.1.3.2. Protecting the resources of the subscriber 446 When deploying one or several IP VPNs for the subscriber, the IP VPN 447 service offering will have to provide the appropriate guarantees 448 that the corresponding resources have the ability to deny any kind 449 of malicious intrusion, especially by protecting the access to the 450 locations (by " location ", the author means either a site which may 451 have a permanent access to the IP VPN resources, or a site which may 452 have a temporary access to the IP VPN resources, including mobile 453 hosts) of the subscriber which might be interconnected by the IP 454 VPN(s), and also by ensuring that the IP VPN resources will deny the 455 access to the locations of the subscriber which are not even 456 connected to the IP VPN(s). 458 6.1.3.3. Preserving the data confidentiality within the IP VPN(s) 460 The IP VPN service offering will have to preserve the 461 confidentiality of the information which is to be transmitted over 462 the IP VPN resources. Moreover, if several IP VPNs are to be 463 deployed for a given subscriber, the IP VPN service offering will 464 have to preserve the confidentiality of the information which is to 465 be transmitted through the various IP VPNs so that any kind of 466 interference might never occur between these IP VPNs. 467 6.1.3.4. Identifying and authenticating the network resources 469 The IP VPN service offering will have to guarantee that, for a given 470 IP VPN (or a set of IP VPN(s)) which has (have) been deployed for a 471 given subscriber, all of the network resources that will be used by 472 this (these) IP VPNs have been appropriately identified and 473 authenticated, so that they have the right to process (i.e. mainly 474 forward and route) the corresponding IP traffic. 476 As far as the security is concerned, the less the (network) 477 resources involved in the processing of the IP traffic of a given IP 478 VPN, the more secure this IP VPN will be. 480 6.1.4. Service management considerations 482 The management of an IP VPN service offering will have to comply 483 with the following requirements: 485 - engineer, deploy and manage the switching and transmission 486 resources which will support the IP VPN service offering, from a 487 network perspective. This features reflects the network element 488 management part of the service management activity; 490 - manage the IP VPNs which have been deployed over the above- 491 mentioned resources. This feature reflects the network management 492 part of the service management activity; 494 - manage the IP VPN service offering itself (this reflects the 495 service management part of the service management activity). From 496 a general perspective, the service management should at least 497 include the global activation of the five classical SMFAs which have 498 been specified by ISO - namely alarm, security, configuration, 499 performance and accounting management. This means in particular: 501 * the specification and the establishment of SLAs between the 502 service provider and the various subscribers, according to the 503 corresponding SLSes; 504 * the measurement of the indicators which have been defined within 505 the context of the above-mentioned SLAs, on a regular basis (namely 506 one day, one week, one month, one quarter, one year, or else); 507 * the management of the users which have been identified and granted 508 by the subscriber, so that they may benefit from the IP VPN(s) which 509 have been deployed accordingly. This should also include the 510 integration of the management of possible user/subscriber 511 directories. 513 - finally manage the IP VPN business, which mainly consists in 514 provisioning administrative and accounting information related to 515 the IP VPN service offering subscribers. This feature reflects the 516 business management part of the service management activity. 518 7. Constraints and selection criteria of an IP VPN service offering 520 7.1. Functional constraints 522 It is assumed the service provider already operates an IP backbone, 523 which could support an IP VPN service offering. This implies that 524 the technical choices must be taken in accordance to the 525 technologies and equipment which are already in use in this 526 backbone. Nevertheless, the technical solutions which will be 527 considered must be supported by the Internet standardization process 528 for compatibility, modularity and backward compatibility purposes. 529 Furthermore, some security functions are needed to ensure that the 530 IP VPN(s) which is (are) provided to the customer is (are) actually 531 "private", and these specific requirements may have an impact on the 532 functional features which are currently supported by the equipment 533 of the IP backbone. 535 7.2. Selection criteria 537 7.2.1. Performances 538 As far as the performances are concerned, the IP VPN service 539 offering should support the following characteristics : 541 - the time to access the service from a user standpoint should be 542 expressed in milliseconds. 544 7.2.2. Quality of service 546 To be defined according to the SLAs which should be provided along 547 with the provisioning of the IP VPN service offering itself, 548 according to the " quality of service considerations " paragraph 549 (6.1.2) of the present document. 551 8. References 553 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 554 3", BCP 9, RFC 2026, October 1996. 555 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, March 1997 557 [VPN-FRAME]Gleeson, B., Heinanen, J., Armitage, G., Malis, A., "A 558 Framework for IP Based Virtual Private Networks ", RFC 559 2764, February 2000 560 [TAXONOMY] Berkowitz, H., "Requirements Taxonomy for Virtual 561 Private Networks",draft-berkowitz-vpn-tax-00.txt, work 562 in progress, March 1999 564 9. Author's address 566 Christian Jacquenet 567 France Telecom Research and Development 568 42, rue des Coutures 569 BP 6243 570 14066 Caen cedex 04 571 France 572 Phone: + 33 2 31 75 94 28 573 Fax: + 33 2 31 73 56 26 574 Email: christian.jacquenet@francetelecom.fr 576 10. Full copyright statement 578 Copyright (C) The Internet Society (2000). All Rights Reserved. 580 This document and translations of it may be copied and furnished to 581 others, and derivative works that comment on or otherwise explain it 582 or assist its implementation may be prepared, copied, published and 583 distributed, in whole or in part, without restriction of any kind, 584 provided that the above copyright notice and this paragraph are 585 included on all such copies and derivative works. However, this 586 document itself may not be modified in any way, such as by removing 587 the copyright notice or references to the Internet Society or other 588 Internet organizations, except as needed for the purpose of 589 developing Internet standards in which case the procedures for 590 copyrights defined in the Internet Standards process must be 591 followed, or as required to translate it into languages other than 592 English. 594 The limited permissions granted above are perpetual and will not be 595 revoked by the Internet Society or its successors or assigns. 597 This document and the information contained herein is provided on an 598 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 599 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 600 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 601 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 602 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.