Re: [imss] [rddp] Storage Maintenance (storm) BOF reminder & requests

Stephen Bailey <steph@cs.uchicago.edu> Thu, 12 March 2009 01:05 UTC

Return-Path: <steph@cs.uchicago.edu>
X-Original-To: imss@core3.amsl.com
Delivered-To: imss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B331428C151 for <imss@core3.amsl.com>; Wed, 11 Mar 2009 18:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 FNJU22Do0AtV for <imss@core3.amsl.com>; Wed, 11 Mar 2009 18:05:42 -0700 (PDT)
Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 925CE28C130 for <imss@ietf.org>; Wed, 11 Mar 2009 18:05:42 -0700 (PDT)
Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id Rq7Q1b00R0cQ2SLA516LHW; Thu, 12 Mar 2009 01:06:20 +0000
Received: from [10.81.152.54] ([32.152.140.93]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id S15Z1b00D216ArC8W15mkY; Thu, 12 Mar 2009 01:06:18 +0000
Mime-Version: 1.0
X-Mailer: SnapperMail 2.3.6.01 by Snapperfish
To: <Black_David@emc.com>, <ips@ietf.org>, <rddp@ietf.org>
Message-ID: <7225-SnapperMsgD1C71620C5DE1084@[10.81.152.54]>
In-Reply-To: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com>
References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com>
From: Stephen Bailey <steph@cs.uchicago.edu>
Date: Wed, 11 Mar 2009 18:05:00 -0700
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Mailman-Approved-At: Thu, 12 Mar 2009 08:05:45 -0700
Cc: imss@ietf.org, Black_David@emc.com
Subject: Re: [imss] [rddp] Storage Maintenance (storm) BOF reminder & requests
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Internet and Management Support for Storage Working Group <imss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imss>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2009 01:05:43 -0000

Any chance we could dramatically exceed our brief on this project and 
totally rewrite everything?

:-)
...... Original Message .......
On Wed, 11 Mar 2009 19:28:10 -0400 <Black_David@emc.com> wrote:
>This is a reminder that the Storage Maintenance BOF will
>be held in about 2 weeks at the IETF meetings in San Francisco.
>Please plan to attend if you're interested:
>
>THURSDAY, March 26, 2009
>Continental 1&2  	TSV  	storm  	 Storage Maintenance BOF
>
>The BOF description is at:
>http://www.ietf.org/mail-archive/web/ips/current/msg02669.html
>
>The initial agenda is here:
>http://www.ietf.org/mail-archive/web/ips/current/msg02670.html
>
>I'm going to go upload that initial agenda as the BOF agenda,
>and it can be bashed at the meeting.
>
>The primary purpose of this BOF is to answer two questions:
>(1) What storage maintenance work (IP Storage, Remote Direct
>	Data Placement) should be done?
>(2) Should an IETF Working Group be formed to undertake that
>	work?
>
>Everyone gets to weigh in on these decisions, even those who
>can't attend the BOF meeting.  Anyone who thinks that there is
>work that should be done, and who cannot come to the BOF meeting
>should say so on the IPS or RDDP mailing lists (and it'd be a
>good idea for those who can come to do this).  As part of the
>email, please indicate how you're interested in helping (author
>or co-author of specific drafts, promise to review and comment
>on specific drafts).
>
>Here's a summary of the initial draft list of work items:
>- iSCSI: Combine RFCs into one document, removing unused features.
>- iSCSI: Interoperability report on what has been implemented and
>	interoperates in support of Draft Standard status for iSCSI.
>- iSCSI: Add backwards-compatible features to support SAM-4.
>- iFCP: The Address Translation mode of iFCP needs to be deprecated.
>- RDDP MPA: Small startup update for MPI application support.
>- iSER: A few minor updates based on InfiniBand experience.
>
>Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes,
>updated ipsec security profile [i.e., IKEv2-based]) is possible if
>there's interest.
>
>There are (at least) four possible outcomes:
>(A) None of this work needs to be done.
>(B) There are some small work items that make sense.  Individual
>	drafts with a draft shepherd (i.e., David Black) will
>	suffice.
>(C) A working group is needed to undertake more complex work
>	items and reach consensus on design issues.  The WG can
>	be "virtual" and operate mostly via the mailing list
>	until/unless controversial/contentious issues arise.
>(D) There is a lot of complex work that is needed, and a WG
>	that will plan to meet at every IETF meeting should be
>	formed.
>
>Please note that the IETF "rough consensus" process requires a
>working group in practice to be effective.  This makes outcome
>(C) look attractive to me, as:
>- I'm coming under increasing pressure to limit travel, and
>	the next two IETF meetings after San Francisco are not
>	in the US.
>- I'd rather have the "rough consensus" process available and
>	not need it than need it and not have it available.
>
>Setting an example for how to express interest ...
>
>---------------
>I think that the iSCSI single RFC and interoperability report are
>good ideas, but I want to see a bunch of people expressing interest
>in these, as significant effort is involved.  It might make sense
>to do the single iSCSI RFC but put off the interoperability report
>(the resulting RFC would remain at Proposed Standard rather than
>going to Draft Standard), as I'm not hearing about major iSCSI
>interoperability issues.
>
>I think the latter four items (SAM-4 for iSCSI, deprecate iFCP
>address translation, MPI fix to MPA and iSER fixes) should all
>be done.
>
>I plan to author the iFCP address translation deprecation draft,
>and review all other drafts.
>
>I think that a virtual WG should be formed that plans to do its
>work primarily via the mailing list.  I believe the SAM-4 work
>by itself is complex enough to need a working group - I would
>expect design issues to turn up at least there and in determining
>whether to remove certain iSCSI features, but I'm cautiously
>optimistic that the mailing list is sufficient to work these
>issues out (and concerned that travel restrictions are likely t