[imss] BOF proposal for San Francisco: updates to iSCSI, other IPS protocols, RDDP protocols

[[e-mail]]

This may be of interest to members of this list.
Please discuss on the ips or rddp lists, rather than imss.

Thanks,
--David

-----Original Message-----
From: Black, David 
Sent: Sunday, January 11, 2009 8:11 PM
To: [e-mail]
Cc: Black, David
Subject: BOF proposal for San Francisco: updates to iSCSI and other IPS
protocols
Importance: High

I'm about to propose a Birds of a Feather (BOF) session for IETF in
San Francisco to discuss forming a working group (tentative name:
STORM [STORage Maintenance] to update iSCSI and other IPS protocols.
The primary purpose of this work would be to reflect implementation
experience in the specifications - this is NOT intended to be a
means of working on version 2 or even version 1.1.

The initial draft of the BOF proposal follows - by the time the BOF
is held (and hopefully well before, there will be a draft charter) -
the purpose of the BOF meeting will be to discuss the draft charter
and proposed plan of work in order to decide whether to ask that
a working group be formed.  I wrote this text quickly, so all
suggestions for edits are welcome.

A number of people have already expressed interest in the draft
work items listed below - in particular, Julian Satran, Kalman
Meth and Mallikarjun Chadalapaka have all indicated an intention
to work on the updated iSCSI specification.  Additional work items
can be added - it would be useful for anyone suggesting a work item
to indicate their intended role/contribution for that work item
(e.g., draft author).  For the implementation survey (basis for
possibly taking iSCSI to Draft Standard status), I'd be interested
in hearing from anyone who's interested *and* has worked on past
imp

Thanks,
--David
------------------------------------------------------------------

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 number of protocols (e.g., iSCSI) that have been
implemented and are being used (to varying degrees).  The purpose of
this
BOF is to determine whether a working group should be formed for
protocol
maintenance and update based primarily on implementation experience.
This work is envisioned to encompass:
- Implementation-driven revisions and updates to existing protocols.
- Interoperability reports so that some of the resulting revised
protocols
	can be taken to Draft Standard RFC status.
- Minor protocol changes or additions; this is anticipated to include
	iSCSI features for SAM-4 compliance and an MPA startup change
	needed to better support MPI applications.
The work will not include wholesale changes to the existing protocols;
this is not intended to be an opportunity to produce version 2 (or
even version 1.1) of any of the protocols.  Backwards compatibility
with existing implementations will be required for all changes and
additions.

Initial draft list of work items:
- iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node
architecture
	key) and 5048 (corrections/clarifications) into one document,
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 taking iSCSI to Draft Standard RFC
status.
	The decision about whether to target Draft Standard RFC status
would
	be discussed in the BOF in San Francisco - this may entail
updates to
	RFC 3722 [stringprep for iSCSI] and 3723 [security].
- iSCSI: Add features to support SAM-4 (4th version of SCSI
architecture)
	in a backwards-compatible fashion.  iSCSI is currently based on
SAM-2.
- iFCP: The Address Translation mode of iFCP needs to be retired (SHOULD
NOT
	implement or use), as there are problems with it, and 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) is
possible if there's interest.  I believe I have private expressions of
interest or commitment to the items explicitly listed above.


_______________________________________________
imss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/imss