[Ips] Revised storm (STORage Maintenance) BOF proposal for SF

Black_David@emc.com Mon, 02 February 2009 17:42 UTC

Return-Path: <ips-bounces@ietf.org>
X-Original-To: ips-archive@optimus.ietf.org
Delivered-To: ietfarch-ips-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id EB1EE28C238; Mon, 2 Feb 2009 09:42:35 -0800 (PST)
X-Original-To: ips@core3.amsl.com
Delivered-To: ips@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id F29903A6B35; Mon, 2 Feb 2009 09:42:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.558
X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id WzpfBnwYNb32; Mon, 2 Feb 2009 09:42:34 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com []) by core3.amsl.com (Postfix) with ESMTP id D4FD23A692A; Mon, 2 Feb 2009 09:42:33 -0800 (PST)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n12HgD0d021797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 12:42:13 -0500 (EST)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com (numailhub.lss.emc.com []) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Mon, 2 Feb 2009 12:42:10 -0500
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n12Hg9Xp018786; Mon, 2 Feb 2009 12:42:09 -0500
Received: from CORPUSMX80A.corp.emc.com ([]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 12:42:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 2 Feb 2009 12:42:09 -0500
Message-ID: <9FA859626025B64FBC2AF149D97C944A018FFA8A@CORPUSMX80A.corp.emc.com>
Thread-Topic: Revised storm (STORage Maintenance) BOF proposal for SF
Thread-Index: AcmFXZJr5VfhwDDxRKO6eQANUIj6hw==
To: <ips@ietf.org>
X-OriginalArrivalTime: 02 Feb 2009 17:42:09.0159 (UTC) FILETIME=[92693170:01C9855D]
X-EMM-EM: Active
Cc: imss@ietf.org, rddp@ietf.org
Subject: [Ips] Revised storm (STORage Maintenance) BOF proposal for SF
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ips>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

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

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.


David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
Ips mailing list