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

Mark Carlson <mark.carlson@oracle.com> Thu, 08 April 2010 21:12 UTC

Return-Path: <mark.carlson@oracle.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 4969E3A694D for <clouds@core3.amsl.com>; Thu, 8 Apr 2010 14:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Level:
X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 2QFHE7j-6MBV for <clouds@core3.amsl.com>; Thu, 8 Apr 2010 14:12:49 -0700 (PDT)
Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id 555E13A67A4 for <clouds@ietf.org>; Thu, 8 Apr 2010 14:12:49 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o38LCdjk001723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Apr 2010 21:12:41 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o38LCcTi002279; Thu, 8 Apr 2010 21:12:38 GMT
Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 159327891270761081; Thu, 08 Apr 2010 14:11:21 -0700
Received: from Macintosh-335.local (/129.150.48.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Apr 2010 14:11:21 -0700
Message-ID: <4BBE4678.6040202@oracle.com>
Date: Thu, 08 Apr 2010 15:11:20 -0600
From: Mark Carlson <mark.carlson@oracle.com>
Organization: Oracle
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Sam Johnston <sjj@google.com>
References: <C6A1D07CACFDBD4D9422C7D7ED288D41041896117A@34093-MBX-C01.mex07a.mlsrvr.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> <0C9A0528F0979949A528AD5F6B83DA9709D5C0AB@xmb-sjc-227.amer.cisco.com> <4BBE14D5.3030307@oracle.com> <v2h460b71b91004081403veec63fbcwb7ea00f64cf4d0f1@mail.gmail.com>
In-Reply-To: <v2h460b71b91004081403veec63fbcwb7ea00f64cf4d0f1@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000208070807000006050201"
X-Source-IP: acsmt354.oracle.com [141.146.40.154]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4BBE46C7.0119:SCFMA4539814,ss=1,fgs=0
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 21:12:57 -0000

CDMI objects can be accessed through plain old HTTP at their URL
(subject to standard access controls) and can be POSTed without having
to code to CDMI semantics. No "mount" is needed. CDMI is shrink to
fit, so if this is all you offer, you can just put up a cloud that does 
these
functions.

-- mark

On 4/8/10 3:03 PM, Sam Johnston wrote:
> Mark,
>
> I should perhaps have been more specific. I'm well aware of CDMI but 
> am looking for something simple and lightweight, somewhere between 
> HTTP and WebDAV rather than a HTTP-based SMB/CIFS. There's certainly 
> applications for the latter but it wasn't what I had in mind.
>
> Sam
>
> On 8 April 2010 19:39, Mark Carlson <mark.carlson@oracle.com 
> <mailto:mark.carlson@oracle.com>> wrote:
>
>     Exactly. http://snia.org/cloud - CDMI is essentially done.
>
>     -- mark
>
>     On 4/8/10 11:34 AM, Masum Hasan (masum) wrote:
>>
>>     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://home.comcast.net/%7Emasumz/>
>>
>>     http://wwwin-people.cisco.com/masum/ (Intranet)
>>
>>     *From:* clouds-bounces@ietf.org <mailto: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 <mailto: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
>>     <mailto: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,sid97_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 <mailto:mwebb@cisco.com>]
>>     *Sent:* Thursday, April 08, 2010 8:23 AM
>>     *To:* clouds@ietf.org <mailto:clouds@ietf.org>
>>     *Cc:* Linda Dunbar; carlw@mcsr-labs.org
>>     <mailto: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
>>
>>
>>     _______________________________________________
>>     clouds mailing list
>>     clouds@ietf.org <mailto:clouds@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/clouds
>
>     _______________________________________________
>     clouds mailing list
>     clouds@ietf.org <mailto:clouds@ietf.org>
>     https://www.ietf.org/mailman/listinfo/clouds
>
>