Re: [clouds] Cloudy focus

Sam Johnston <samj@samj.net> Tue, 23 February 2010 01:29 UTC

Return-Path: <samj@samj.net>
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 0E11D28C4B7 for <clouds@core3.amsl.com>; Mon, 22 Feb 2010 17:29:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level:
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 k8ZJVVCtoRlw for <clouds@core3.amsl.com>; Mon, 22 Feb 2010 17:29:57 -0800 (PST)
Received: from eu1sys200aog115.obsmtp.com (eu1sys200aog115.obsmtp.com [207.126.144.139]) by core3.amsl.com (Postfix) with SMTP id 52BBB28C4C5 for <clouds@ietf.org>; Mon, 22 Feb 2010 17:29:57 -0800 (PST)
Received: from source ([209.85.220.219]) by eu1sys200aob115.postini.com ([207.126.147.11]) with SMTP ID DSNKS4MwDXeYN2d1dUUtAONJ6gB2I7ja054U@postini.com; Tue, 23 Feb 2010 01:31:58 UTC
Received: by fxm19 with SMTP id 19so3186966fxm.1 for <clouds@ietf.org>; Mon, 22 Feb 2010 17:31:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.239.153.71 with SMTP id y7mr1679372hbb.210.1266888716859; Mon, 22 Feb 2010 17:31:56 -0800 (PST)
In-Reply-To: <4B8326B5.4030405@dcrocker.net>
References: <4B8326B5.4030405@dcrocker.net>
Date: Tue, 23 Feb 2010 02:31:56 +0100
Message-ID: <21606dcf1002221731o23124eb8lfab4924291023d37@mail.gmail.com>
From: Sam Johnston <samj@samj.net>
To: dcrocker@bbiw.net
Content-Type: multipart/alternative; boundary=001485f6cea2f03a2404803a83da
Cc: clouds@ietf.org, Mark Nottingham <mnot@mnot.net>
Subject: Re: [clouds] Cloudy focus
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, 23 Feb 2010 01:29:59 -0000

On Tue, Feb 23, 2010 at 1:52 AM, Dave CROCKER <dhc2@dcrocker.net> wrote:

I think that the few postings, so far, underscore the need to have
> significant clarity and focus about the interest in pursuing any cloud work
> in the IETF.
> <...>
> Even if the initial set is discarded, we should start discussions with a
> statement of specific problems that need to be solved in the IETF, and why
> the existing efforts elsewhere are either inappropriate for the work or
> insufficient to them.
>

Thanks for the pragmatism Dave.

I've been patiently waiting for the IETF to take an interest in cloud while
working on the OGF's OCCI <http://www.occi-wg.org/> for the best part of a
year now. Having stared at the problem from every angle it occurs to me that
there are two sensible ways forward:

a. Treat everything as a feed (as we do at Google with GData aka AtomPub)
and/or
b. "Enhance" HTTP such that resources can be annotated (attributes),
correlated (categories) and interrelated (links) out-of-band, without
resorting to Atom/SOAP-style envelopes.

Having had limited success selling Atom to the working group I later found
that a lot of what we need can be done by tweaking HTTP, for example with
Mark's draft-nottingham-http-link-header<http://tools.ietf.org/html/draft-nottingham-http-link-header>er>,
my
draft-johnston-http-category-header<http://tools.ietf.org/html/draft-johnston-http-category-header>
and
either raw headers or a Set-Cookie style draft for attributes.

This would allow others (like the OGF, DMTF, etc.) to create and animate
arbitrarily complex models, leaving the payload "clean" for existing
standard formats like OVF (in much the same way as the Internet currently
caters for multiple image formats). It would also be incredibly useful for
other traditional applications such as content management.

Hopefully this gives you some ideas as to how the IETF might engage without
treading on the toes of the (many) existing standards efforts.

Sam