Re: [clouds] Scope of the Cloud is too big

"Masum Hasan (masum)" <masum@cisco.com> Thu, 08 April 2010 17:36 UTC

Return-Path: <masum@cisco.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 44FB328C144 for <clouds@core3.amsl.com>; Thu, 8 Apr 2010 10:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 UbQKle25g5jy for <clouds@core3.amsl.com>; Thu, 8 Apr 2010 10:36:03 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id F34C528C14F for <clouds@ietf.org>; Thu, 8 Apr 2010 10:34:55 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AloFAO+vvUurR7Hu/2dsb2JhbACBP5l5caF8mSmCEkoVghgEgyQ
X-IronPort-AV: E=Sophos; i="4.52,171,1270425600"; d="scan'208,217"; a="112452835"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 08 Apr 2010 17:34:52 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o38HYq2o016147; Thu, 8 Apr 2010 17:34:52 GMT
Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 10:34:52 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD741.CB8C0C48"
Date: Thu, 08 Apr 2010 10:34:51 -0700
Message-ID: <0C9A0528F0979949A528AD5F6B83DA9709D5C0AB@xmb-sjc-227.amer.cisco.com>
In-Reply-To: <v2x460b71b91004080819w37556de8x17a6e5616d52b438@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [clouds] Scope of the Cloud is too big
Thread-Index: AcrXLujbh3xcXg7PSMSXWnS9N9HeDwAEkF2w
References: <C6A1D07CACFDBD4D9422C7D7ED288D41041896117A@34093-MBX-C01.mex07a.mlsrvr.com><4BBC9B0C.5050207@stpeter.im><C6A1D07CACFDBD4D9422C7D7ED288D41041896119B@34093-MBX-C01.mex07a.mlsrvr.com><D7AB7C87-E8F6-496B-9D37-E13FAED746F2@cisco.com><008001cad669$a4d0add0$440c7c0a@china.huawei.com><010401cad673$9e2ca6f0$da85f4d0$@org><00d001cad676$0be2fa30$440c7c0a@china.huawei.com><C6A1D07CACFDBD4D9422C7D7ED288D4104189615B3@34093-MBX-C01.mex07a.mlsrvr.com><9DF482BD-96B8-4E85-941C-190134DBB2CC@cisco.com><C6A1D07CACFDBD4D9422C7D7ED288D41041896160C@34093-MBX-C01.mex07a.mlsrvr.com> <v2x460b71b91004080819w37556de8x17a6e5616d52b438@mail.gmail.com>
From: "Masum Hasan (masum)" <masum@cisco.com>
To: Sam Johnston <sjj@google.com>, Gene Golovinsky <gene@alertlogic.com>
X-OriginalArrivalTime: 08 Apr 2010 17:34:52.0614 (UTC) FILETIME=[CBD63660:01CAD741]
Cc: clouds@ietf.org
Subject: Re: [clouds] Scope of the Cloud is too big
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, 08 Apr 2010 17:36:10 -0000

Re. your comment on pursuing "storage API like Amazon's S3" in IETF. Why
that is needed when storage networking SDO SNIA is working on one (SNIA
CDMI)?

 

 

--Masum

 

408 219 9713   Cell                  408 853 5926   Desk

http://home.comcast.net/~masumz/

http://wwwin-people.cisco.com/masum/ (Intranet)

 

 

From: clouds-bounces@ietf.org [mailto:clouds-bounces@ietf.org] On Behalf
Of Sam Johnston
Sent: Thursday, April 08, 2010 8:19 AM
To: Gene Golovinsky
Cc: clouds@ietf.org
Subject: Re: [clouds] Scope of the Cloud is too big

 

Gene,

 

You're definitely not alone in thinking this would be a worthy topic for
IETF and as co-conspirator (along with Cisco's Chris Hoff) and author of
the existing CloudAudit draft spec I'd love to see IETF people starting
to work with the group. We have weekly calls on Monday at 10am PST/1pm
EST and discuss in the cloudaudit Google Group[1]. The goal for v1 is to
create a trivial HTTP-based interface that can be implemented by
uploading files rather than coding. Similarly, OGF's OCCI working group
has produced a number of Internet-Drafts that could be picked up by
IETF.

 

Another area that I think would be very interesting for IETF to take on
(moreso than virtualisation management) is a simple, HTTP-based storage
API like Amazon's S3 - only without the potential patent problems[2]. I
believe that HTTP already takes care of many/most of the issues (e.g.
authentication, encryption, ranged GETs, etc.) and IETF has proven
experience in the area (WebDAV).

 

Another issue I ran into while writing cush[3] was how to remotely
instruct servers to migrate (live?) resources - for example, moving a
virtual machine, database, etc. from one location to another using a
mobile device on a 3G connection. I believe WebDAV's COPY and MOVE verbs
are a good start (this is what we're using for OCCI) but they could be
reviewed and possibly promoted for more generic application.

 

Considering that most of these APIs (at least the ones I'm involved in)
are trying to be as close as possible to the "uniform interface" of
HTTP, I believe there's benefit to be had in reviewing the relevant RFCs
with these new applications in mind. For example, while HTTP has a
perfectly good metadata channel (headers) and thus obviates the need for
envelope formats (Atom, SOAP, etc), it lacks the ability to link,
annotate and categorise resources. It also has some internationalisation
problems (e.g. ASCII) and inefficient serialisation (e.g. SPDY). HTTP
1.1 has served us well for many years but perhaps it's time to start
thinking about what HTTP 2.0 might look like?

 

Sam

 

-- 
Sam Johnston

Technical Program Manager

Site Reliability Engineering

Google Switzerland GmbH

 

1. http://groups.google.com/group/cloudaudit
2. http://tinyurl.com/s3patent

3. http://code.google.com/p/cush/

 

On 8 April 2010 15:40, Gene Golovinsky <gene@alertlogic.com> wrote:

http://www.cloudaudit.org/ is an initiative, not a standard.

The plan for the group is to submit proposal to the IETF:

http://searchsecuritychannel.techtarget.com/news/interview/0,289202,sid9
7_gci1508024,00.html

 

Which means I am not alone thinking this is a worthy topic for IETF to
take on.

When and if the proposal will be submitted there is still going to be a
lot of work to make it a standard.

 

At least two approaches are possible. 1. Do nothing while waiting for
Cloud Audit proposal. 2. Start working with the group.

Considering how fast Cloud technologies have been evolving and how
critical Security is for the adoption of it I am for #2.

 

--Gene

 

 

 

From: Mark Webb [mailto:mwebb@cisco.com] 
Sent: Thursday, April 08, 2010 8:23 AM
To: clouds@ietf.org
Cc: Linda Dunbar; carlw@mcsr-labs.org; Gene Golovinsky


Subject: Re: [clouds] Scope of the Cloud is too big

 

Look at 

 

http://www.cloudaudit.org/

 

For cloud audit.  It is difficult to specify audit when the services are
so different today.  

 

The industry has not settled on a small set of services definitions of
what "cloud" is. So, how does one audit SaaS, PaaS?  When the services
offered in that space are so different?  IaaS is the most mature and
perhaps the lcd of cloud.  

 

So, who here thinks that "IT functions as a service" or ITaaS is
something that IETF can specify?  OK that was rhetorical.  My point is,
the real opportunity is to look for elements that are mature enough to
have some problem to be solved defined.  Then ensure you are not
duplicating what other SDO or Forum are already working on.

 

Mark Webb