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

Bhumip Khasnabish <vumip1@gmail.com> Tue, 25 May 2010 17:16 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 4326D3A6EF4 for <clouds@core3.amsl.com>; Tue, 25 May 2010 10:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.759
X-Spam-Level:
X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=0.839, 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 AE6tmFtlzZYu for <clouds@core3.amsl.com>; Tue, 25 May 2010 10:16:50 -0700 (PDT)
Received: from mail-yw0-f202.google.com (mail-yw0-f202.google.com [209.85.211.202]) by core3.amsl.com (Postfix) with ESMTP id 3F4463A6F01 for <clouds@ietf.org>; Tue, 25 May 2010 10:16:01 -0700 (PDT)
Received: by ywh40 with SMTP id 40so2491280ywh.18 for <clouds@ietf.org>; Tue, 25 May 2010 10:15:50 -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=WrD6MuQLVzYqQ07FqL+AbbgxVi+tB+Ja7atlkYid/w8=; b=AmzLwzDegUWMLVXpe3nyQGMfnozkz8bhK/doxPBeeEah2VZbpdxdSl5fOQk2qKu95n 5Y6r98rVCRm+E4Q8014dC1pfCVPziwM1zsuweRVkFDx1A1STfRqjpfIXfGbI75mBJWZD PsiGZ1DfVrOi4QAGrK6v/HJ1OGs6WsV7rM0bI=
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=Cq9WRCV3+96vp/YvAsvhkgl5EhpoYzIg1B2cSKSCNYGuXvjexuD/kqEkSYwbT9YvwS HMPV6NLlYsUWmjyRqHZ8SMSahvF3+1yvWDIm2N4hZr3naE3/4MjDghMH5tCHxHCNqDKU 8Nv7pFqANPb1Ok9EEbYaC1RZj8q5b/xumY4lA=
MIME-Version: 1.0
Received: by 10.231.148.73 with SMTP id o9mr5899228ibv.21.1274807749656; Tue, 25 May 2010 10:15:49 -0700 (PDT)
Received: by 10.231.58.203 with HTTP; Tue, 25 May 2010 10:15:49 -0700 (PDT)
In-Reply-To: <4BFBFEB9.1080606@oracle.com>
References: <AANLkTikNK0e2JDPaTFKo8kZ_59TxmdG22rvBLGtFcU5e@mail.gmail.com> <4BFBFEB9.1080606@oracle.com>
Date: Tue, 25 May 2010 13:15:49 -0400
Message-ID: <AANLkTikFsY2KS7xIDhHwKTyUQKBZSHrisdgHuIhPURaB@mail.gmail.com>
From: Bhumip Khasnabish <vumip1@gmail.com>
To: Mark Carlson <mark.carlson@oracle.com>
Content-Type: multipart/alternative; boundary=0016e645ba581340cb04876e4f42
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:16:54 -0000

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 <mark.carlson@oracle.com>wrote;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
>
>


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