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

[Mark Webb <[e-mail]>]

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]] On  
> Behalf Of Sam Johnston
> Sent: Tuesday, May 25, 2010 1:18 PM
> To: Mark Carlson
> Cc: [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]> 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] 
> > wrote:
> Bhumip,
>
> Not sure why you are doing this. The information you need is largely  
> already
> available on 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
>
> 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
>
> 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
>
> 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. Key words for use in RFCs to Indicate  
> Requirement Levels -http://www.ietf.org/rfc/rfc2119.txt
>
> [RFC2045] IETF RFC 2045. Multipurpose Internet Mail Extensions  
> (MIME) Part One: Format of Internet Message Bodies -http://www.ietf.org/rfc/rfc2045.txt
>
> [RFC2578] IETF RFC 2578. Structure of Management Information Version  
> 2 (SMIv2) - http://www.ietf.org/rfc/rfc2578.txt
>
> [RFC2616] IETF RFC 2616. Hypertext Transfer Protocol -- HTTP/1.1 - http://www.ietf.org/rfc/rfc2616.txt
>
> [RFC3280] IETF RFC 3280. Internet X.509 Public Key Infrastructure  
> Certificate and Certificate Revocation List (CRL) Profile - http://www.ietf.org/rfc/rfc3280.txt
>
> [RFC3530] IETF RFC 3530. Network File System (NFS) version 4  
> Protocol - http://www.ietf.org/rfc/rfc3530.txt
>
> [RFC3986] IETF RFC 3986. Uniform Resource Identifier (URI): Generic  
> Syntax - http://www.ietf/org/rfc/rfc3986.txt
>
> [RFC4346] IETF RFC 4346. The Transport Layer Security (TLS) Protocol  
> Version 1.1 - http://tools.ietf.org/rfc/rfc4346.txt
>
> [RFC4627] IETF RFC 4627. The application/json Media Type for  
> JavaScript Object Notation (JSON) -http://www.ietf.org/rfc/rfc4627.txt
>
> [RFC5246] IETF RFC 5246. 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
>
> [REST] "Representational State Transfer" - http://www.ics.uci.edu/~fielding/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])
>>
>> © 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]
>> https://www.ietf.org/mailman/listinfo/clouds
>>
>
>
> _______________________________________________
> clouds mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clouds
>
>
>
>
> -- 
> Best Regards.
>
> Bhumip Khasnabish (Mobile:[phone], [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]
> https://www.ietf.org/mailman/listinfo/clouds
>
>
>
>
> _______________________________________________
> clouds mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clouds