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

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Thu, 27 May 2010 07:02 UTC

Return-Path: <hannes.tschofenig@nsn.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 843853A6895 for <clouds@core3.amsl.com>; Thu, 27 May 2010 00:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 1ohdwEd5vzvH for <clouds@core3.amsl.com>; Thu, 27 May 2010 00:02:53 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id E7A923A6843 for <clouds@ietf.org>; Thu, 27 May 2010 00:02:52 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o4R72SEg030214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 May 2010 09:02:28 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o4R72SIs021511; Thu, 27 May 2010 09:02:28 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 May 2010 09:02:28 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 27 May 2010 10:02:37 +0300
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502A01B51@FIESEXC015.nsn-intra.net>
In-Reply-To: <008001cafd61$a05069c0$a6140674@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [clouds] Clouds SDO gap analysis template (a Table)
Thread-Index: Acr8Nt9nNUZKMwxITQyHFtk/RVSufABKlIVgAAG+D7A=
References: <AANLkTikNK0e2JDPaTFKo8kZ_59TxmdG22rvBLGtFcU5e@mail.gmail.com><4BFBFEB9.1080606@oracle.com><AANLkTikFsY2KS7xIDhHwKTyUQKBZSHrisdgHuIhPURaB@mail.gmail.com><4BFC0D8E.3030007@oracle.com><AANLkTillQUoRixi4gqjlqTRTE8n7WIeXVJonS-M6yOsD@mail.gmail.com> <008001cafd61$a05069c0$a6140674@china.huawei.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "ext Linda Dunbar" <ldunbar@huawei.com>, "Sam Johnston" <sjj@google.com>, "Mark Carlson" <mark.carlson@oracle.com>
X-OriginalArrivalTime: 27 May 2010 07:02:28.0436 (UTC) FILETIME=[9195E140:01CAFD6A]
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: Thu, 27 May 2010 07:02:55 -0000

Hi Linda, 

Two minor items that come to my mind. 

1) "Cloud Computing" is largely a marketing term. Many of us (including me) are not good in marketing. For discussions it therefore helps to translate the cloud terminology into something that many of us understand. 

2) Keeping up with all the "cloud" work is in some sense quite easy to do. Why? It seems that most organizations just look around what other SDOs are doing and try to figure out what cloud computing actually means.

We typically try to work on well-defined scoped work (see all the working group charters). Some SDOs have taken a different approach and that's fine as well. So far, I have not seen anyone proposing detailed *technical* work. I am looking forward to see technical contributions from Sam (in the mail thread below) and others. 

In starting new work there are additional aspects to consider (beyond what http://tools.ietf.org/html/rfc5434 says), namely:

1) Are there deployed solutions available that require standardization? (Not everything requires interoperability.) Bringing work to the IETF that has found acceptance in the marketplace already offers some advantages over starting with a clean slate. 

2) Do those companies producing whatever solutions (such as virtualization, etc.) demand that their work gets standardized? If not, then the outcome of standardization will have a hard time to find acceptance. 

Ciao
Hannes

PS: Just something to think about. When I helped to bring OAuth to the IETF nobody was talking about cloud computing. It was just about delegated authentication on the Internet. Now, a year later some people refer to the very same use cases but use the term "cloud" somewhere in the description even though nothing has changed compared to last year from a technical point of view. 


________________________________

	From: clouds-bounces@ietf.org [mailto:clouds-bounces@ietf.org] On Behalf Of ext Linda Dunbar
	Sent: 27 May, 2010 08:58
	To: 'Sam Johnston'; 'Mark Carlson'
	Cc: clouds@ietf.org
	Subject: Re: [clouds] Clouds SDO gap analysis template (a Table)
	
	

	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: clouds-bounces@ietf.org [mailto:clouds-bounces@ietf.org] On Behalf Of Sam Johnston
	Sent: Tuesday, May 25, 2010 1:18 PM
	To: Mark Carlson
	Cc: clouds@ietf.org
	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 <mark.carlson@oracle.com> 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 <mark.carlson@oracle.com> 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 <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:+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 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é.

	
	_______________________________________________
	clouds mailing list
	clouds@ietf.org
	https://www.ietf.org/mailman/listinfo/clouds