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

Bhumip Khasnabish <vumip1@gmail.com> Tue, 25 May 2010 17:18 UTC

Return-Path: <vumip1@gmail.com>
X-Original-To: clouds@core3.amsl.com
Delivered-To: clouds@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F0E3A6AE1 for <clouds@core3.amsl.com>; Tue, 25 May 2010 10:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Level:
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUdkkiRtE+iu for <clouds@core3.amsl.com>; Tue, 25 May 2010 10:18:24 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3E8963A6A63 for <clouds@ietf.org>; Tue, 25 May 2010 10:18:23 -0700 (PDT)
Received: by iwn42 with SMTP id 42so5192806iwn.31 for <clouds@ietf.org>; Tue, 25 May 2010 10:18:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=RZfI34o5qpxPh2L209Tjit3OaKGiySZS+GcF3YMB7Uo=; b=UyBcj8IXbpzV2f+ogwiPnd6d7USp/uXbMaKi/1CNyk4N9dLoK6Rgk6jbS5x7PhOCPW dK3tlDqepHrnw2+jMBWWgOd6XnqSXhmdNshFH++cGSWujdQTwXRYHhH/kRaWHl6xOCLQ I54twcytwSUsF9bQLh/a5ph4UsrFkL3LDbzJM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lquaIqZQiOaAiDUCapokYQ7H08GoUV+4z5Iz9HyIO5H3WqHcV5vpQf7JJW1vbWRXzR g0CzU/uyKyPHbiCJVTY3g2bvMA7F4USR/z7u6VKIW7GTAEHqDdNTq7U2zXcH9ncOhGIj NIh+LiABDRRfuhEF3FHsQrLS7g3d5RV+HPTO0=
MIME-Version: 1.0
Received: by 10.231.149.145 with SMTP id t17mr6084900ibv.25.1274807850531; Tue, 25 May 2010 10:17:30 -0700 (PDT)
Received: by 10.231.58.203 with HTTP; Tue, 25 May 2010 10:17:30 -0700 (PDT)
In-Reply-To: <4E8DA166-4F41-4174-9CF3-D7F05BD084C3@cisco.com>
References: <AANLkTikNK0e2JDPaTFKo8kZ_59TxmdG22rvBLGtFcU5e@mail.gmail.com> <4BFBFEB9.1080606@oracle.com> <4E8DA166-4F41-4174-9CF3-D7F05BD084C3@cisco.com>
Date: Tue, 25 May 2010 13:17:30 -0400
Message-ID: <AANLkTimqCSYnxKeBIO_DPkwZQ4xVS-cwV3a_IIA1wACO@mail.gmail.com>
From: Bhumip Khasnabish <vumip1@gmail.com>
To: Mark Webb <mwebb@cisco.com>
Content-Type: multipart/alternative; boundary=005045013c82167d4204876e55d8
Cc: clouds@ietf.org
Subject: Re: [clouds] Clouds SDO gap analysis template (a Table)
X-BeenThere: clouds@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Clouds pre-BOF discussion list <clouds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/clouds>, <mailto:clouds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clouds>
List-Post: <mailto:clouds@ietf.org>
List-Help: <mailto:clouds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clouds>, <mailto:clouds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2010 17:18:33 -0000

Thanks a lot Mark (M. Webb) and I agree.

Best.
Bhumip



On Tue, May 25, 2010 at 1:06 PM, Mark Webb <mwebb@cisco.com> wrote:

>
>
> I think the cloud-standards.org wiki is a fine effort.  Ad-hoc and
> informal, but with fine goals.
>
> However, it doesn't capture the full picture or all significant SDO and
> forum working on cloud related standards and profiles.  TMF (very important
> IMO) and ITU-T cloud working group, (less significant now but carries
> weight) are two that are not on this site.
>
> There is work to be done IMO.
>
> Mark Webb
>
>  On May 25, 2010, at 12:45 PM, Mark Carlson 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<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
>
> [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:+001-781-752-8003, bhumip@acm.org)
>
> © 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 listclouds@ietf.orghttps://www.ietf.org/mailman/listinfo/clouds
>
> _______________________________________________
> clouds mailing list
> clouds@ietf.org
> https://www.ietf.org/mailman/listinfo/clouds
>
>
>
> _______________________________________________
> clouds mailing list
> clouds@ietf.org
> https://www.ietf.org/mailman/listinfo/clouds
>
>


-- 
Best Regards.

Bhumip Khasnabish (Mobile:+001-781-752-8003, bhumip@acm.org)

© 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é.