[rddp] STORM WG - draft charter

Black_David@emc.com Tue, 24 March 2009 02:03 UTC

Return-Path: <Black_David@emc.com>
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 2E6263A6B19; Mon, 23 Mar 2009 19:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 REedeqhiwKtv; Mon, 23 Mar 2009 19:03:12 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 5D16F28C1B2; Mon, 23 Mar 2009 19:03:11 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n2O23xsk020179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 22:04:00 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Mon, 23 Mar 2009 22:03:54 -0400
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n2O23pNX012989; Mon, 23 Mar 2009 22:03:51 -0400
Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 22:03:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Mar 2009 22:03:48 -0400
Message-ID: <9FA859626025B64FBC2AF149D97C944A0234A317@CORPUSMX80A.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: STORM WG - draft charter
Thread-Index: AcmsJMV1xvlvkU8dSCyDoEce3SV0LQ==
To: ips@ietf.org, rddp@ietf.org
X-OriginalArrivalTime: 24 Mar 2009 02:03:51.0309 (UTC) FILETIME=[C6EE83D0:01C9AC24]
X-EMM-EM: Active
Cc: imss@ietf.org
Subject: [rddp] STORM WG - draft charter
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: Tue, 24 Mar 2009 02:03:13 -0000

I promised a draft charter before the BOF, so here it is.
This should look very familiar as it's based on the BOF
proposal that has been out for a while.  The FCIP item
below (may be possible to return an IP Protocol Number
to IANA) is new.

If the recommendation of the BOF is to form a Working Group,
the revised charter (with work items and milestones) will be
published to these lists for further review and comment before
the actual WG request goes to the IESG.

Proposed Working Group: STORM (STORage Maintenance)
	Transport (TSV) Area
Proposed Charter (First Draft) - March 23, 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; 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 draft list of work items (subject to change at the BOF):
- 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, as iSCSI is
	currently based on SAM-2.  This will be a separate draft
	from the iSCSI update in the first bullet.
- 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.  It may be possible to return this IP Protocol
	number to IANA for future reallocation.
- 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.  It
	is intended to do this with a short document that updates
	RFC 4172 (i.e., not via a complete rewrite of RFC 4172).
- 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: Make a few minor updates based on experience with InfiniBand
	and other implementations to reflect what has been done in
	practice.

Actual Goals and Milestones will be determined at the BOF.


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


Thanks,
--David
----------------------------------------------------
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
----------------------------------------------------