Re: [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: rddp@core3.amsl.com
Delivered-To: rddp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47B128C15A for <rddp@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 FyMbMGMwLOON for <rddp@core3.amsl.com>; Wed, 11 Mar 2009 18:05:42 -0700 (PDT)
Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 9260928C13D for <rddp@ietf.org>; Wed, 11 Mar 2009 18:05:42 -0700 (PDT)
Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id RqNi1b0090cQ2SLA416Ln9; 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
Cc: imss@ietf.org, Black_David@emc.com
Subject: Re: [rddp] Storage Maintenance (storm) BOF reminder & requests
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rddp>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-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
- [rddp] Storage Maintenance (storm) BOF reminder &… Black_David
- [rddp] STORM BOF time Black_David
- Re: [rddp] Storage Maintenance (storm) BOF remind… Stephen Bailey
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Julian Satran
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Lars Eggert
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Knight, Frederick
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Mallikarjun C.
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Robert D. Russell
- Re: [rddp] [Junk released by Allow List] Re: [Ips… Felix Marti
- Re: [rddp] [Junk released by Allow List] Re: [Ips… Mikkel Hagen
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Bernard Metzler
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Caitlin Bestler
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Caitlin Bestler
- Re: [rddp] Storage Maintenance (storm) BOF remind… Uri Elzur
- Re: [rddp] [Ips] Storage Maintenance (storm) BOF … Robert D. Russell
- Re: [rddp] Storage Maintenance (storm) BOF remind… Fredy Neeser
- Re: [rddp] Storage Maintenance (storm) BOF remind… Minturn, Dave B
- Re: [rddp] Storage Maintenance (storm) BOF remind… Felix Marti