-------- Original Message --------
Subject: [rddp] Revised storm (STORage Maintenance) BOF proposal for SF
Date: Mon, 2 Feb 2009 12:42:09 -0500
From: [email protected]
To: <[email protected]>
CC: [email protected], [email protected]

I just sent this in with a request for approval of the
BOF.  There should be no substantial changes from what
I posted earlier, but there is a strong request for a
meeting slot later in the week due to a conflicting
meeting for the RDDP folks Mon-Wed.

---------------------------------------

Proposed Transport Area (TSV) BOF: STORM (STORage Maintenance)
Proposed for IETF San Francisco (March 22-27, 2009)

The IETF ips (IP Storage) and rddp (Remote Direct Data Placement)
working groups have produced a significant number of storage
protocols (e.g., iSCSI, iSER, FCIP and iFCP) for which there is
significant usage.  The time has come to reflect feedback from
implementation and usage into updated RFCs.  See the initial
draft list of work items below for details (expansion of this
list during the BOF is a definite possibility).

The purpose of the storm BOF is to determine whether a working group
should be formed for maintenance and update of these storage-related
protocols based primarily on implementation experience.  This work
is envisioned to encompass:

- Implementation-driven revisions and updates to existing protocols
        (i.e., updated RFCs that match the "running code").
- Interoperability reports as needed for the resulting revised
        protocols that are appropriate for Draft Standard RFC status.
- Minor protocol changes or additions; this is anticipated to
        include iSCSI features for SAM-4 compliance, some minor
        iSER corrections/clarifications and an MPA startup change
        needed to better support MPI applications.

The envisioned work **WILL NOT** include wholesale changes to the
existing protocol standards. Stability is critical to the usage of
these protocols, hence work on version 2 of any of these protocols
will be out of scope, period.  Backwards compatibility with existing
implementations will be a requirement imposed on for all protocol
changes and additions.  Note that this is a requirement for
*implementation* compatibility - if it is the case that an existing
RFC says one thing, but all the implementations of that RFC
consistently do something different, it would be appropriate for
a new RFC to document what the "running code" actually does and
deprecate the unused original behavior.

Initial draft list of work items:
- iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node
        architecture key) and 5048 (corrections/clarifications) into
        one draft, removing features that are not implemented in
        practice (e.g., markers).
- iSCSI: Interoperability report on what has been implemented and
        is known to interoperate in support of Draft Standard RFC
        status for the new iSCSI RFC.  The decision about whether to
        target Draft Standard RFC status will be discussed in the BOF
        in San Francisco - this may entail updates to RFC 3722
        [stringprep for iSCSI] and RFC 3723 [security].
- iSCSI: Add features to support SAM-4 (4th version of the SCSI
        architecture) in a backwards-compatible fashion.  iSCSI is
        currently based on SAM-2.  This will be a separate draft
        from the iSCSI update in the first bullet.
- iFCP: The Address Translation mode of iFCP needs to be deprecated
        (SHOULD NOT implement or use), as there are significant
        technical problems with its specification, and moreover,
        only the Address Transparent mode of iFCP is in use.  A
        short draft should be sufficient to do this (i.e., a
        complete rewrite of RFC 4172 is not anticipated).
- RDDP MPA: Good support for MPI applications requires a small
        update to the startup functionality to allow either end
        of the connection to initiate.
- iSER: Experience with Infiniband implementations suggest a few
        minor updates to reflect what has been done in practice.

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 expressions of interest and/or work
commitment to the items listed above that will be discussed at the
BOF.

Scheduling Request: While IETF BOFs are scheduled on a time-and-space
available basis, there is a conflicting event for the RDDP community
(includes MPA and iSER) on Mon-Wed of the IETF San Francisco week.
For this reason a Thu or Fri meeting slot is strongly requested for
this BOF in order to obtain participation of the RDDP community in
addition to the IPS community.

-----------------------------------------

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rddp

_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss

Reply via email to