Re: Storage Maintenance (storm) BOF reminder & requests

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 <[email protected]> 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