idnits 2.17.1 draft-fisher-cloudassets-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2016) is 2775 days in the past. Is this intentional? -- 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: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3470' is defined on line 569, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 T. Fisher 2 Internet Draft P. Walsh 3 Intended status: Informational Jackpine Technolgies Corp. 4 Expires: March 18, 2017 September 19, 2016 6 Cloud Assets 7 draft-fisher-cloudassets-00 9 Abstract 11 There is no standardized method to describe assets used in a cloud 12 such that they can be moved from one cloud to the next independent 13 of the underlying architecture. This document defines Cloud Assets 14 as a lightweight description of cloud resources and proposes a 15 standardization of Cloud Assets into three major categories: 16 Resource Assets, Component Assets, and Composite Assets. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 18, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction...................................................3 53 1.1. Terminology...............................................3 54 1.2. Background................................................4 55 2. Requirements...................................................4 56 3. Use Cases......................................................4 57 4. Cloud Assets...................................................5 58 4.1. Resource Assets...........................................5 59 4.1.1. Clouds...............................................5 60 4.1.2. Cloudspaces..........................................5 61 4.1.3. Cloud Networks.......................................5 62 4.1.4. Templates............................................5 63 4.1.5. Devices..............................................5 64 4.1.6. Appliances...........................................5 65 4.2. Component Assets..........................................5 66 4.2.1. Software: Applications...............................6 67 4.2.2. Software: Source Code................................6 68 4.2.3. Software: Data.......................................6 69 4.2.4. Test Cases...........................................6 70 4.2.5. Virtual Services.....................................6 71 4.2.6. Networks.............................................6 72 4.3. Composite Assets..........................................6 73 4.3.1. Systems..............................................6 74 4.3.2. Scenarios............................................7 75 4.3.3. Deployments..........................................7 76 4.3.4. Test Bundles.........................................7 77 5. Usage Example..................................................7 78 5.1. Resource Assets...........................................7 79 5.1.1. Cloud................................................7 80 5.1.2. Cloudspace...........................................8 81 5.1.3. Cloud Network........................................8 82 5.1.4. Template.............................................8 83 5.1.5. Device...............................................8 84 5.1.6. Appliance............................................9 85 5.2. Composite Assets..........................................9 86 5.2.1. System...............................................9 87 5.2.2. Scenario............................................10 88 5.2.3. Deployment..........................................10 89 5.2.4. Test Bundle.........................................10 90 6. Sample........................................................10 91 7. Security Considerations.......................................12 92 8. IANA Considerations...........................................13 93 9. References....................................................13 94 9.1. Normative References.....................................13 95 9.2. Informative References...................................13 96 10. Acknowledgments..............................................13 98 1. Introduction 100 1.1. Terminology 102 The following terms are used in this document: 104 o Cloud Assets - The basis for building provisioning, and testing 105 of cloud-based environments. 107 o Cloud Environments - The user implementation of a cloud 108 infrastructure. 110 o Cloud Infrastructure - Infrastructure as a servcie that a user 111 can consume from anywhere over the Internet. The cloud focuses on 112 providing consumers the required capabilities rather than 113 specific backend compute resources. 115 o Infrastructure as a Service (IAAS) - a standardized, highly 116 automated offering, where compute resources, complemented by 117 storage and networking capabilities are owned and hosted by a 118 service provider and offered to customers on-demand. Users are 119 able to self-provision this infrastructure, using a Web-based 120 graphical user interface that serves as an IT operations 121 management console for the overall environment. API access to the 122 infrastructure may also be offered as an option. [2] 124 o Resource Assets - Elements of a cloud infrastructure registered 125 by the cloud administrator. 127 o Cloud Administrator - An entity that administers the 128 infrastructure supporting the cloud. 130 o Component Assets - Elements of a cloud environment imported by 131 the user. 133 o Composite Assets - Combinations of resource and component assets 134 into defined entities 136 o Virtual Machine - a software implementation of a complete system 137 platform that supports the execution of a complete operating 138 system and corresponding applications in a cloud. [1] 140 1.2. Background 142 As more and more cloud infrastructure choices become available for 143 consumers, the difficulty in choosing the cloud that best supports 144 the customers needs throughout their application lifecycle becomes 145 increasingly difficult. No cloud is a "one size fits all" and 146 enabling use of different cloud providers at different points in the 147 application lifecycle will better enable consumers to focus on 148 meeting user requirements rather than infrastructure dependencies. 149 This document describes a method to help standardize how assets are 150 used in clouds so that they can be more easily migrated from one 151 cloud to the next as needs dictate. 153 2. Requirements 155 This document assumes the following requirements: 157 o Cloud agnostic - usable by any underlying cloud technology 159 o Loosely coupled - cloud updates will not break the asset 161 o Human readable - configurable by any text editor 163 o Flexible - supports wide range of use cases 165 o Lightweight - does not include underlying OS itself 167 o Reusable - well documented so that others can leverage 169 3. Use Cases 171 The following use cases drove the development of the proposed 172 standard: 174 o Moving assets to/from commercial cloud provider from/to private 175 cloud provider 177 o Moving assets from one commercial cloud provider to another 179 o Moving assets from one security classification level to another 181 o Common assets enabling security compliance across clouds 183 o Leveraging knowledge across teams working in different clouds 185 o Migration from data center to cloud 187 4. Cloud Assets 189 We propose the definition and structure of Resource, Component, and 190 Composite Assets. 192 4.1. Resource Assets 194 Resource assets are elements of a cloud infrastructure that are 195 registered to be available for use. The Cloud Administrator controls 196 which resources they want to allow access to. Resource assets 197 include the following: Clouds, Cloudspaces, Cloud Networks, 198 Templates, Devices, and Appliances 200 4.1.1. Clouds 202 The account used to access a portion of IaaS cloud provider (e.g., 203 Amazon Web Services, Google, Azure, or private cloud). 205 4.1.2. Cloudspaces 207 A private space within a cloud with separate security boundary & 208 access control (e.g. VMware Virtual Data Center or AWS Virtual 209 Private Cloud). 211 4.1.3. Cloud Networks 213 The networks in a Cloud that are accessible to the Cloudspace. 215 4.1.4. Templates 217 Base installation of operating system into a virtual machine. Also 218 known as images. 220 4.1.5. Devices 222 A device or service that is accessible from the cloud. 224 4.1.6. Appliances 226 A preconfigured (aka not configurable) virtual machine that is 227 accessible from the cloud. 229 4.2. Component Assets 231 Component Assets are imported by a user with appropriate permissions 232 and used as building blocks for the construction, configuration and 233 validation of cloud environments. Components assets include the 234 following: Software: Applications, Software: Source Code, Software: 235 Data, Test Cases, Virtual Services, and Networks. 237 4.2.1. Software: Applications 239 Applications include software installers, utilities and 240 configurations. 242 4.2.2. Software: Source Code 244 Software that is used to check out, build and install un-compiled 245 code. 247 4.2.3. Software: Data 249 Data assets are data sets available for use by other assets. Fewer 250 required components; optional encryption. 252 4.2.4. Test Cases 254 Description and properties used to perform functional, performance, 255 and/or security validation tasks. 257 4.2.5. Virtual Services 259 Virtual services are models representing the data inputs and outputs 260 of a service. 262 4.2.6. Networks 264 New networks created in the Cloud that are accessible in the 265 Cloudspace. 267 4.3. Composite Assets 269 Composite assets are combinations of resource and component assets 270 that define how and environment will be built, configured and 271 deployed (often referred to as recipes, blueprints, or manifests). 272 Composite assets include: Systems, Scenarios, Deployments, and Test 273 Bundles. 275 4.3.1. Systems 277 A single system (e.g. virtual machine) that includes: 279 o One template 280 o Zero or more Software: Application assets 282 o Zero or more Software: Source Code assets 284 o Zero or more Software: Data assets 286 o One or more Network assets 288 4.3.2. Scenarios 290 A Scenario asset includes one or more System assets and zero or more 291 Virtual Service assets. 293 4.3.3. Deployments 295 A Deployment asset includes at least one Scenario asset and zero or 296 more Test Bundle assets. 298 4.3.4. Test Bundles 300 A Test Bundle asset includes at least one Test Case asset. 302 5. Usage Example 304 All assets have minimum required fields: 306 308 String 310 String 312 String 314 316 5.1. Resource Assets 318 5.1.1. Cloud 320 #Required 322 String 324 String 326 String 328 5.1.2. Cloudspace 330 #Required 332 String 334 5.1.3. Cloud Network 336 #Required 338 String 340 5.1.4. Template 342 #Required 344 String 346 Integer 348 Integer 350 Integer 352 Integer 354 String 356 String 358 #Optional 360 Integer 362 String 364 String 366 # 0 = no, 1 = yes 368 Integer 370 5.1.5. Device 372 #Required 374 String 375 String 377 String 379 5.1.6. Appliance 381 #Required 383 String 385 String 387 Integer 389 Integer 391 5.2. Composite Assets 393 5.2.1. System 395 #Required 397 Integer 399 # specs used to select a template 401 Integer 403 Integer 405 Integer 407 # in MBytes 409 Integer 411 Integer 413 # 0 = no, 1 = yes 415 Integer 417 #Optional 419 Integer 421 Integer 422 # 0 = no, 1 = yes 424 Integer 426 5.2.2. Scenario 428 #Required 430 Integer 432 Integer 434 Integer 436 #Optional 438 Integer 440 5.2.3. Deployment 442 #Required 444 Integer 446 #Optional 448 Integer 450 String 452 5.2.4. Test Bundle 454 #Required 456 Integer 458 Integer 460 6. Sample 462 The sample xml below is for a Red Hat server with Java and JBoss 463 installed. 465 467 5 468 Red Hat 6 470 1 472 1 474 8192 476 1024 478 0 480 482 Java 484 Java JDK 8u101 486 software 488 1 490 1 492 0 494 Application 496 install.sh 498 /media 500 license.txt 502 readme.txt 504 506 john.do@example.com 508 6175555555 510 John Doe 512 "Example, Inc." 514 515 517 JBoss 519 JBoss 7 521 software 523 23 525 2 527 0 529 Application 531 install.sh 533 /media 535 license.txt 537 readme.txt 539 541 john.do@example.com 543 6175555555 545 John Doe 547 "Example, Inc." 549 551 553 7. Security Considerations 555 One should be aware of and consider the variety of security best 556 practices when working with XML and implement methods that best 557 support your application of Cloud Asset descriptions. Consider 558 especially using checksums to detect errors and verify data 559 integrity. 561 8. IANA Considerations 563 Namespace is managed by the underlying cloud infrastructure. 565 9. References 567 9.1. Normative References 569 [RFC3470] Hollenbeck, S., et al., "Guidelines for the Use of 570 Extensible Markup Language (XML) within IETF Protocols", 571 BCP 70, RFC 3470, January 2003. 573 9.2. Informative References 575 [1] Karmel, A., Chandramouli, R., and Iorga, M., "NIST Definition 576 of Microservices, Application Containers and System Virtual 577 Machines", NIST Special Publication 800-180 (DRAFT), 578 http://csrc.nist.gov/publications/drafts/800-180/sp800- 579 180_draft.pdf, February 2016 581 [2] http://blogs.gartner.com/it-glossary/infrastructure-as-a- 582 service-iaas/ 584 10. Acknowledgments 586 This document was prepared using 2-Word-v2.0.template.dot. 588 Authors' Addresses 590 Todd Fisher 591 Jackpine Technolgies Corp. 593 Email: todd.fisher@jackpinetech.com 595 Peter Walsh 596 Jackpine Technolgies Corp. 598 Email: peter.walsh@jackpinetech.com