Re: [clouds] CloudApps BoF (IETF-80) proposal for your review and comments

Vishwas Manral <vishwas.ietf@gmail.com> Mon, 31 January 2011 18:45 UTC

Return-Path: <vishwas.ietf@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 51D8A3A6C21 for <clouds@core3.amsl.com>; Mon, 31 Jan 2011 10:45:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.454
X-Spam-Level:
X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 YYrvKBetz5zW for <clouds@core3.amsl.com>; Mon, 31 Jan 2011 10:45:48 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 992243A6B01 for <clouds@ietf.org>; Mon, 31 Jan 2011 10:45:47 -0800 (PST)
Received: by wwa36 with SMTP id 36so6590764wwa.13 for <clouds@ietf.org>; Mon, 31 Jan 2011 10:49:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=26HY3Grpez7WAKdLR5wwfRWd2SuZkUN0WbzvJDSL6ZI=; b=XvAZGEULS17dOOE81FtOUSIFeG5HXFskbicMunQuyUmO1oV2rN6I55Nx+Na82Cr6mI ZFhRERoSxu0FfEwp9sscH4oLe2S0rF9zX4UmaSa0fscnZ1VFlz2lTADK5gACYd4XBixZ 1xlOgp7DgfG43RkJP36oQcnUCdLzQAh8Sy+MI=
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=wn+pINBduXGrG3100IU2DN/4RBg5KSqv0hyMQViJDamHCzzUdDb96Q/xRep7cCb5/u /8ZEM35TFm+cAFPcA1es+TksCKqtrzPchfSlojWZRUyvJ7D596CR2IqbgLHAhIWlquXg OzKykmbqCErt6irIkTGvF81ghQHrsY0++ZhYk=
MIME-Version: 1.0
Received: by 10.216.3.144 with SMTP id 16mr12157012weh.45.1296499740465; Mon, 31 Jan 2011 10:49:00 -0800 (PST)
Received: by 10.216.151.100 with HTTP; Mon, 31 Jan 2011 10:49:00 -0800 (PST)
In-Reply-To: <4D47015E.1010905@stpeter.im>
References: <AANLkTi=Qm3rSzkx4uoNt7XL2999DotMpC0+LAaKoDpZi@mail.gmail.com> <4D47015E.1010905@stpeter.im>
Date: Mon, 31 Jan 2011 10:49:00 -0800
Message-ID: <AANLkTikgt5Mw1d-b2Eo5LEq7sS54L3vn-Ahx3gsUijRo@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1
Cc: clouds@ietf.org
Subject: Re: [clouds] CloudApps BoF (IETF-80) proposal for your review and comments
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: Mon, 31 Jan 2011 18:45:49 -0000

Hi Peter,

I would not totally agree. For nearly every new protocol developed,
that I have worked on there has been seperate  requirement documents,
use cases as well as protocol extension documents - have a look at
MPLS, TRILL and PCE. I do not think we should not consider the phase.

I however agree it should be a shorter phase to define requirements
and use cases.

You are right some of the drafts are about VDI, however the others you
mention are now directly related to it (the Yokota draft is more about
resource management and mobility in the cloud).

Thanks,
Vishwas

On Mon, Jan 31, 2011 at 10:37 AM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> On 1/29/11 2:43 PM, Bhumip Khasnabish wrote:
>> I plan to submit it by the deadline (Monday-31-January-2011).
>>
>> http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Khasnabish-et-al-CloudApps-BoF-Proposal-v7-30Jan2011.doc
>
> It would have been good to post actual text to the list. Attachments
> that require support for proprietary formats are not welcome.
>
>> So, pls review and send me your comments and suggestions ASAP. Many thanks.
>
> Let me say that you are making some progress. At least you now have
> separate proposals that are focused on more particular problem domains
> (e.g., applications vs. operations).
>
> However, when I read this proposal I see several big warning flags.
>
> First, as various folks explained in Beijing, IETF participants prefer
> to develop protocols, because that's what we do best. Your proposal is
> to work on:
>
> Phase 1 - Use cases, reference framework, survey
>
> Phase 2 - Requirements
>
> Phase 3 - New protocol, profile of existing protocols, and/or APIs
>
> That approach might work well in other SDOs, but I don't think it is a
> recipe for success at the IETF.
>
> Second, everything in this proposal still reeks of the old "clouds are
> special" attitude. As folks explained in Beijing, we care about solving
> specific engineering problems, not building any kind of cloud-related
> application that some people might find interesting.
>
> Several of the referenced drafts talk about the problem of building
> virtual desktop infrastructure (VDI):
>
> http://tools.ietf.org/id/draft-wang-clouds-vdi-problem-statement-00.txt
>
> http://www.ietf.org/id/draft-ma-clouds-vdi-survey-00.txt
>
> http://www.ietf.org/id/draft-yokota-cloud-service-mobility-00.txt
>
> http://tools.ietf.org/id/draft-cloud-log-00.txt
>
> Those documents seem to provide a good start toward defining a more
> focused engineering problem that IETF participants could work on (my
> apologies, but I have yet to read them in depth). I would suggest
> throwing out Phases 1 and 2 to some extent (using them only as
> background to the engineering problem) and trying to get to Phase 3 as
> quickly as possible.
>
> Holding a Bof about forming a VDI WG might be appropriate at IETF 80 in
> Prague. At the least it would help IETF folks understand whether there
> really is a problem here that the IETF needs to solve, how many people
> are willing to work on building solutions, etc. See RFC 5434 for some
> *very* helpful information about the thinking (and work!) necessary to
> hold a successful BoF.
>
> Next steps:
>
> a. Read RFC 5434 and restructure your proposal a bit to answer the
> questions posed in that document.
>
> b. Complete the BoF request template here:
>
> http://trac.tools.ietf.org/bof/trac/
>
> Because I will be the continuing area director at IETF 80, I will
> volunteer to be your responsible AD.
>
> Also, do you plan to request additional BoF slots at IETF 80 (e.g., for
> CloudCenter/DataCenter Operations)? It takes a lot of work to hold a
> successful BoF. It even takes a lot of work to hold an unsuccessful BoF!
> Therefore I counsel you to plan accordingly, and to hold only one BoF
> per IETF meeting if you want to form multiple working groups in
> different IETF areas.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>
>
> _______________________________________________
> clouds mailing list
> clouds@ietf.org
> https://www.ietf.org/mailman/listinfo/clouds
>
>