Re: [clouds] Clouds SDO gap analysis template (a Table)

[Mark Carlson <[e-mail]>]

+1 to this. This is a great example of where IETF can aid the cloud efforts.
The cloud efforts at the various SDOs always look for other existing 
standards
to leverage. CDMI, for example, references 
<http://cdmi.sniacloud.com/cdmi_spec/2-references/2-references.htm> no 
fewer than 10 existing IETF RFCs.
SNIA recently embarked on an effort to add more interoperable auditing 
to CDMI
and would readily reference the IETF work if it incorporated the 
requirements of
data and storage management.

-- mark

On 5/27/10 7:27 AM, Gene Golovinsky wrote:
>
> Mark and all.
>
> One of the areas where I am convinced Cloud can benefit from IETF 
> efforts is logging.
>
> As I mentioned a few months ago "Auditability" for any Cloud 
> infrastructure and applications either does not exist at all or in its 
> enfancy.
>
> CloudAudit is making very good progress towards some aspects of 
> "Auditability", but it is mostly geared towards identifying and 
> locating appropriate compliance documents in the defined namespace.
>
> I have in mind logging Syslog style. The content of the logs for the 
> Cloud should be different from your traditional server, router, switch 
> log since the managed entity itself is obfuscated in the cloud.
>
> This leads to almost impossible forensics and compliance objectives 
> unless Cloud participating entity logs information consistently and in 
> interoperable manner.
>
> I'll be sending high level proposal soon. I believe it will be 
> specific enough and complimentary to CloudAudit efforts.
>
> --Gene
>
> *From:* [e-mail] [mailto:[e-mail]] *On 
> Behalf Of *Mark Webb
> *Sent:* Thursday, May 27, 2010 8:17 AM
> *To:* Linda Dunbar
> *Cc:* [e-mail]
> *Subject:* Re: [clouds] Clouds SDO gap analysis template (a Table)
>
> Linda,
>
> In principle I think you have a good point that I agree with in the 
> longer term.  I think if the IETF community wants to be relevant to 
> whatever cloud computing is, then the group needs to find something 
> within the scope of IETF _and_ not already being worked by some other 
> SDO or forum where a significant contribution, (job to be done, 
> problem to be solved) needs to be made.
>
> I see the "gap analysis" as only a means to that end, (identify a real 
> concrete problem & potential solution in need of standardization at 
> this point in time for cloud).
>
> Keeping all possible outcomes in play also means to me that IETF may 
> have no _significant_ new cloud value at this snapshot in time, (as 
> unpopular as that may be).
>
> Mark Webb
>
> PS: with the understanding that individuals, groups, organizations 
> will shop SDOs for path of least resistance for their own benefit.
>
> On May 27, 2010, at 1:58 AM, Linda Dunbar wrote:
>
>
>
> I don't think it is realistic for IETF to keep up with all the Cloud 
> work done by other SDO. "Cloud" is just too big a scope for one IETF 
> working group. We should focus on one concrete problem. Other SDO's 
> work will be background and justify why this problem has to be solved 
> by IETF instead of other SDO.
>
> Linda Dunbar
>
> ------------------------------------------------------------------------
>
> *From:* [e-mail] <mailto:[e-mail]> 
> [mailto:[e-mail]] *On Behalf Of *Sam Johnston
> *Sent:* Tuesday, May 25, 2010 1:18 PM
> *To:* Mark Carlson
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [clouds] Clouds SDO gap analysis template (a Table)
>
> Bhumip/Mark,
>
> In terms of gap analysis, I'd be more interested in seeing other 
> groups feeding into IETF than having it picking up the scraps. I 
> certainly intend to submit CloudAudit, and ideally [parts of] OCCI to 
> the I-D/RFC process for a start. IETF is well known for having clean, 
> interoperable specifications which is something specialist groups are 
> not so good at.
>
> Sam
>
> On 25 May 2010 19:49, Mark Carlson <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
> That's great. When the IETF decides what it wants to do, you should
> also create and maintain an entry up there.
>
> Thanks,
>
> -- mark
>
>
> On 5/25/10 11:15 AM, Bhumip Khasnabish wrote:
>
> Dear Mark,
>
> Thanks for your inputs and suggestions.
>
> Yes, we'll utilize all of the relevant existing information from the 
> sites that you mention and a few others.
>
> As you know our objective is to determine the gaps (existing and 
> emerging) and focus on where IETF can contribute in terms of 
> standardization (protocol development, protocol extension 
> recommendation, etc.) and profile development for Cloud-based services.
>
> Hope these help clarify matters.
>
> Thanks again.
>
> Best.
>
> Bhumip
>
>
> On Tue, May 25, 2010 at 12:45 PM, Mark Carlson 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
> Bhumip,
>
> Not sure why you are doing this. The information you need is largely 
> already
> available on http://cloud-standards.org <http://cloud-standards.org/> 
> wiki. Each SDO has already created
> an entry describing their cloud work, and they use a standard template 
> already
> to describe each standard.
>
> For example, here is one for an already finalized standard:
>
>
> http://cloud-standards.org/wiki/index.php?title=SNIA_Cloud_Data_Management_Interface_%28CDMI%29
>
>
>   Cloud Standard
>
> *1. The name of the specification*
>
> SNIA Cloud Data Management Interface
>      
>
> *2. A short statement (<100 words) of the purpose and function of the 
> specification* The SNIA Cloud Data Management Interface (CDMI) is the 
> functional interface that applications will use to create, retrieve, 
> update and delete data elements from the cloud. As part of this 
> interface the client will be able to discover the capabilities of the 
> cloud storage offering and use this interface to manage containers and 
> the data that is placed in them. In addition, metadata can be set on 
> containers and their contained data elements through this interface.
>
> *3. The version number (or other distinct identifier) and date of the 
> most recently approved version of the specification.*
>
> SNIA Architecture - 1.0 standard
>
> *4. If the specification is part of a group of explicitly related 
> specifications from the same source, the name of the group of 
> specifications.* Not applicable
>
> *5. URI for the normative text of the specification 
> *http://www.snia.org/tech_activities/standards/curr_standards/cdmi
>
>
>     SOURCE
>
> *6. The name of the SDO that generated/authored/hosted the 
> specification. *Storage Networking Industry Association
>
> *7. URI for the SDO* http://snia.org <http://snia.org/>
>
> *8. The level of approval that the SDO has conferred on the 
> specification as described by the SDO's process.* SNIA Architecture 
> (Final Standard)
>
> *9. The language or languages in which the specification is available. 
> *US English
>
>
>     SUBJECT
>
> *10. Which of the categories of Cloud services does the standard 
> address? *(Infrastructure as a Service - IaaS, Data Storage as a 
> Service - DaaS, Platform as a Service - PaaS, Software as a Service - 
> SaaS) DaaS (Cloud Storage)
>
> *11. Does the standard address both functional and management aspects 
> of the service?* Yes. Management is done by setting metadata on 
> containers of data and individual data elements. The functional 
> interface allows CRUD semantics for storage of data via HTTP.
>
>
>     OPTIONAL
>
> *12. The level of approval of the specification in this generic 
> lifecycle taxonomy:*
>
> Final standard
>
>
> *13. URI for the applicable SDO's patent and copyright rules, if any, 
> applicable to development and use of the specification.* SNIA IP 
> Policy <http://www.snia.org/about/corporate_info/ip_policy/>
>
> *14. URI for the SDO's posting location, (if any) for notices from 
> participants or individuals regarding claims under the rules stated 
> under number 15.* SNIA IP Policy 
> <http://www.snia.org/about/corporate_info/ip_policy/>
>
> *15. Interoperability, conformance, or certification test activity for 
> the specification (by owner name or URI).*
>
> None
>
> *16. Known implementations of the specification (by owner name or URI).*
>
> The SNIA Cloud Storage TWG is producing an open source reference 
> implementation.
>
> *17. A list (or URI pointer to same) of the other specifications* that 
> are normatively referenced in the specification.*
>
>
> [ISO-8601] International Standards Organization, "Data elements and 
> interchange formats -- Information interchange -- Representation of 
> dates and times", ISO 8601:20044 
> -http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40874
>
> [ITU-T509] International Telecommunications Union Telecommunication 
> Standardization Sector (ITU-T), Recommendation X.509: Information 
> technology - Open Systems Interconnection - The Directory: Public-key 
> and attribute certificate frameworks, May 2000. Specification and 
> technical corrigenda - http://www.itu.int/ITU-T/publications/recs.html
>
> [RFC2119] IETF RFC 2119 <http://tools.ietf.org/html/rfc2119>. Key 
> words for use in RFCs to Indicate Requirement Levels 
> -http://www.ietf.org/rfc/rfc2119.txt
>
> [RFC2045] IETF RFC 2045 <http://tools.ietf.org/html/rfc2045>. 
> Multipurpose Internet Mail Extensions (MIME) Part One: Format of 
> Internet Message Bodies -http://www.ietf.org/rfc/rfc2045.txt
>
> [RFC2578] IETF RFC 2578 <http://tools.ietf.org/html/rfc2578>. 
> Structure of Management Information Version 2 (SMIv2) - 
> http://www.ietf.org/rfc/rfc2578.txt
>
> [RFC2616] IETF RFC 2616 <http://tools.ietf.org/html/rfc2616>. 
> Hypertext Transfer Protocol -- HTTP/1.1 - 
> http://www.ietf.org/rfc/rfc2616.txt
>
> [RFC3280] IETF RFC 3280 <http://tools.ietf.org/html/rfc3280>. Internet 
> X.509 Public Key Infrastructure Certificate and Certificate Revocation 
> List (CRL) Profile - http://www.ietf.org/rfc/rfc3280.txt
>
> [RFC3530] IETF RFC 3530 <http://tools.ietf.org/html/rfc3530>. Network 
> File System (NFS) version 4 Protocol - http://www.ietf.org/rfc/rfc3530.txt
>
> [RFC3986] IETF RFC 3986 <http://tools.ietf.org/html/rfc3986>. Uniform 
> Resource Identifier (URI): Generic Syntax - 
> http://www.ietf/org/rfc/rfc3986.txt
>
> [RFC4346] IETF RFC 4346 <http://tools.ietf.org/html/rfc4346>. The 
> Transport Layer Security (TLS) Protocol Version 1.1 - 
> http://tools.ietf.org/rfc/rfc4346.txt
>
> [RFC4627] IETF RFC 4627 <http://tools.ietf.org/html/rfc4627>. The 
> application/json Media Type for JavaScript Object Notation (JSON) 
> -http://www.ietf.org/rfc/rfc4627.txt
>
> [RFC5246] IETF RFC 5246 <http://tools.ietf.org/html/rfc5246>. The 
> Transport Layer Security (TLS) Protocol Version 1.2 - 
> http://tools.ietf.org/rfc/rfc5246.txt
>
> *18. A list (or URI pointer to same) of the other specifications* that 
> are referenced in the specification (except the ones listed under 
> number 17).*
>
> [CRC] Williams, Ross, "A Painless Guide to CRC Error Detection 
> Algorithms", Chapter 16, August 
> 1993,http://www.repairfaq.org/filipg/LINK/F_crc_v3.html
>
> [PKS12] RSA Laboratories, PKCS #12: Personal Information Exchange 
> Syntax, Version 1.0, June 1999. Specification and Technical 
> Corrigendum - http://www.rsa.com:80/rsalabs/node.asp?id=2138 
> <http://www.rsa.com/rsalabs/node.asp?id=2138>
>
> [REST] "Representational State Transfer" - 
> http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm 
> <http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm>
>
> [RESTful Web] Richardson, Leonard and Sam Ruby, RESTful Web Services, 
> O'Reilly, 2007.
>
> [SIRDM] Storage Industry Resource Domain Model - 
> http://www.snia.org/education/storage_networking_primer/sirdm/
>
>
> *19. A list (or URI pointer to same) of other specifications* with 
> which the specification may (speculatively) interoperate or act in 
> complementary, compatible fashion.*
>
> OCCI - see OGF entry.
>
> *20. A list (or URI pointer to same) of other specifications* similar 
> to this specification. (Whether or not substitutable.)*
>
> None.
>
> -----------------------------------
>
> The template can be found here:
> http://cloud-standards.org/wiki/index.php?title=Template
>
> -- mark
>
>
>
> On 5/25/10 10:33 AM, Bhumip Khasnabish wrote:
>
>     Dear All,
>
>     Attached please find a template (a Table) that can be utilized for
>     Clouds SDO gap analysis.
>
>     Very much appreciate your comments, inputs, suggestions for
>     updating it.
>
>     The plan is to populate this template with SDOs' information,
>
>     once this template is finalized through email discussion.
>
>     Thanks a lot for your support and contributions
>
>     Best Regards.
>
>     Bhumip
>
>
>     Bhumip Khasnabish (Mobile:[phone], [e-mail]
>     <mailto:[e-mail]>)
>
>     © 2010 Bhumip Khasnabish. Do not view, print, forward, and save
>     the content of this email if you are not the intended recipient of
>     the communiqué.
>
>       
>
>     _______________________________________________
>
>     clouds mailing list
>
>     [e-mail]  <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/clouds
>
>        
>
>
> _______________________________________________
> clouds mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/clouds
>
>
>
>
> -- 
> Best Regards.
>
> Bhumip Khasnabish (Mobile:[phone], [e-mail] 
> <mailto:[e-mail]>)
>
> © 2010 Bhumip Khasnabish. Do not view, print, forward, and save the 
> content of this email if you are not the intended recipient of the 
> communiqué.
>
>
> _______________________________________________
> clouds mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/clouds
>
>
>
> _______________________________________________
> clouds mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/clouds
>
>
> _______________________________________________
> clouds mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clouds
>