Re: [storm] WG Action: STORage Maintenance (storm)

>This draft should be prepared so that it could become a Draft Standard RFC,
but it is up to >the to decide whether to advance it to Draft Standard.

There is a missing word here.  I assume it is up to the Working Group to
decide?

Mallikarjun

> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf
> Of IESG Secretary
> Sent: Tuesday, August 04, 2009 9:00 AM
> To: ietf-announce@ietf.org
> Cc: ttalpey@microsoft.com; storm@ietf.org
> Subject: [storm] WG Action: STORage Maintenance (storm)
> 
> A new IETF working group has been formed in the Transport Area.  For
> additional information, please contact the Area Directors or the WG
> Chairs.
> 
> STORage Maintenance (storm)
> ----------------------------------
> Last Modified: 2009-08-04
> 
> Current Status: Active Working Group
> 
> Chairs:
> - David L. Black <black_david@emc.com>
> - Tom Talpey <ttalpey@microsoft.com>
> 
> Transport Area Director(s):
> - Magnus Westerlund <magnus.westerlund@ericsson.com>
> - Lars Eggert <lars.eggert@nokia.com>
> 
> Transport Area Advisor:
> - Lars Eggert <lars.eggert@nokia.com>
> 
> Mailing Lists:
> General Discussion: storm@ietf.org
> To Subscribe: storm-request@ietf.org
> In Body: (un)subscribe
> Archive: http://www.ietf.org/mail-archive/web/storm/index.html
> 
> Description of Working Group:
> 
> 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 and FCIP) for which there is
> significant usage. The time has come to reflect feedback from
> implementation and usage into updated RFCs; this work may include:
> 
> - 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. Backwards compatibility
> is required.
> 
> Significant changes to the existing protocol standards are out of
> scope, including any work on version 2 of any of these protocols.
> 
> Stability is critical to the usage of these protocols, so 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 all implementations of a protocol have done something
> different than what the RFC specifies, it is appropriate for
> a new RFC to document what the "running code" actually does and
> deprecate the unused original behavior.
> 
> Initial list of work items:
> 
> (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node
> architecture key) and 5048 (corrections/clarifications) into
> one draft (3720bis), removing features that are not implemented
> in practice. This draft should be prepared so that it could
> become a Draft Standard RFC, but it is up to the to decide
> whether to advance it to Draft Standard.
> 
> (2) iSCSI: Add features to support SAM-4 (4th version of the SCSI
> architecture) in a backwards-compatible fashion, as iSCSI is
> currently based on SAM-2. This will be a separate draft
> from the iSCSI update in the previous bullet. The Working
> group may add additional minor useful iSCSI features
> to this draft.
> 
> (3) FCIP: IP Protocol number 133 was allocated to a precursor of
> the FCIP protocol in 2000, but this allocated number is not
> used by FCIP. The working group will consider whether this
> allocated number should be returned to IANA for future
> reallocation.
> 
> (4) 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. This
> will be done via a short draft that updates RFC 4172, and
> not via a complete rewrite of RFC 4172. A combined draft
> is expected that encompasses items (3) and (4).
> 
> (5) RDDP MPA: Good support for MPI applications requires a small
> update to the startup functionality to allow either end
> of the connection to initiate.
> 
> (6) iSER: Experience with Infiniband implementations suggest a few
> minor updates to reflect what has been done in practice.
> 
> The working group is expected to maintain good working relationships
> with INCITS Technical Committee T10 (SCSI standards) and INCITS
> Technical Committee T11 (Fibre Channel standards) via overlaps in
> membership as opposed to appointment of formal liaisons. The
> liaison process (including IAB appointment of a liaison or
> liaisons) remains available for use if needed.
> 
> Goals and Milestones:
> 
> June 2009 First version of FCIP protocol number and iFCP Address
> Translation mode draft
> 
> July 2009 First version of iSCSI SAM-4 (and other) new features draft.
> 
> Aug 2009 First version of RDDP MPA startup change draft
> 
> Sep 2009 Working Group Last Call on FCIP protocol number and iFCP
> address
> change draft
> 
> Sep 2009 First version of combined iSCSI draft (3720bis)
> 
> Oct 2009 First version of iSER update draft
> 
> Oct 2009 Working Group Last Call on RDDP MPA startup change draft.
> 
> Dec 2009 Functionally complete iSCSI SAM-4 (and other) new features
> draft.
> 
> Feb 2010 Working Group Last Call on iSER update draft
> 
> March 2010 Working Group Last Call on iSCSI SAM-4 (and other) new
> features draft.
> 
> April 2010 Working Group decision on whether to seek Draft Standard RFC
> status for the combined iSCSI draft (3720bis). [Note: decision may be
> made
> significantly before this date.]
> 
> Sep 2010 Working Group Last Call on combined iSCSI draft (3720bis)
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm