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

Stephen Bailey <> Thu, 12 March 2009 01:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B331428C151 for <>; Wed, 11 Mar 2009 18:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FNJU22Do0AtV for <>; Wed, 11 Mar 2009 18:05:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 925CE28C130 for <>; Wed, 11 Mar 2009 18:05:42 -0700 (PDT)
Received: from ([]) by with comcast id Rq7Q1b00R0cQ2SLA516LHW; Thu, 12 Mar 2009 01:06:20 +0000
Received: from [] ([]) by with comcast id S15Z1b00D216ArC8W15mkY; Thu, 12 Mar 2009 01:06:18 +0000
Mime-Version: 1.0
X-Mailer: SnapperMail by Snapperfish
To: <>, <>, <>
Message-ID: <7225-SnapperMsgD1C71620C5DE1084@[]>
In-Reply-To: <>
References: <>
From: Stephen Bailey <>
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
Subject: Re: [imss] [rddp] Storage Maintenance (storm) BOF reminder & requests
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Internet and Management Support for Storage Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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:
>The initial agenda is here:
>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