IPS Draft charter revision

[Black_David@emc.com]

Here's a draft of the revised charter for the IP Storage
WG.  Aside from the schedule update, the following substantial
changes have been made:

- Security requirements reflect the current "MUST implement"
	status of confidentiality.
- Text on bridges and gateways to existing protocols has been
	reworded to avoid any implication that proxy support
	is required.
- We have to finish some of what we're doing before undertaking
	any new protocol encapsulation work.

There have also been some minor editorial cleanups.

Comments to the list, please.  This'll go to the Area Directors
for approval and posting on the IETF web site in about a week.

Thanks,
--David

IP Storage (ips) 

Chair(s):
Elizabeth Rodriguez <egrodriguez@lucent.com>
David Black <black_david@emc.com>

Transport Area Director(s): 
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>

Transport Area Advisor: 
Allison Mankin <mankin@isi.edu>

Technical Advisor(s): 
Keith McCloghrie <kzm@cisco.com>

Mailing Lists: 
General Discussion:ips@ece.cmu.edu 
To Subscribe: ips-request@ece.cmu.edu 
In Body: subscribe ips 
Archive: http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html 

Description of Working Group: 
There is significant interest in using IP-based networks to transport block
storage
traffic. This group will pursue the pragmatic approach of encapsulating
existing
protocols, such as SCSI and Fibre Channel, in an IP-based transport or
transports.
The group will focus on the transport or transports and related issues
(e.g.,
security, naming, discovery, and configuration), as opposed to modifying
existing protocols. Standards for the protocols to be encapsulated are
controlled
by other standards organizations (e.g., T10 [SCSI] and T11 [Fibre Channel]).
The
WG cannot assume that any changes it desires will be made in these
standards, and
hence will pursue approaches that do not depend on such changes unless they
are
unavoidable. In that case the WG will create a document to be forwarded to
the
standards group responsible for the technology explaining the issue and
requesting
the desired changes be considered. The WG will endeavor to ensure high
quality
communications with these standards organizations. The WG will consider
whether
a layered architecture providing common transport, security, and/or other
functionality for its encapsulations is the best technical approach.

The protocols to be encapsulated expect a reliable transport, in that
failure to
deliver data is considered to be a rare event for which time-consuming
recovery
at higher levels is acceptable. This has implications for both the choice of
transport protocols and design of the encapsulation(s). The WG's
encapsulations
may require quality of service assurances (e.g., bounded latency) to operate
successfully; the WG will consider what assurances are appropriate and how
to
provide them in shared traffic environments (e.g., the Internet) based on
existing IETF QoS mechanisms such as Differentiated Services. 

Use of IP-based transports raises issues that do not occur in the existing
transports for the protocols to be encapsulated.  The WG's protocol
encapsulations will incorporate the following: 

- Congestion control suitable for shared traffic network environments such
as the
	Internet. 
- Security including authentication, keyed cryptographic data integrity
	and confidentiality, sufficient to defend against threats up to and
including
	those that can be expected on a public network.  Implementation of
basic
	security functionality will be required, although usage may be
optional.

The WG will also address the following issues related to its protocol
encapsulations:

- Naming and discovery mechanisms for the encapsulated protocols on IP-based
	networks, including both discovery of resources (e.g., storage) for
	access by the discovering entity, and discovery for management. 
- Management, including appropriate MIB definition(s). 

These may be addressed is documents separate from the main protocol
specifications.

The WG specifications will allow the implementation of bridges and gateways
that connect to existing implementations of the encapsulated protocols.
The WG will preserve the approaches to discovery, multi-pathing, booting,
and
similar issues taken by the protocols it encapsulates to the extent
feasible. 

It may be necessary for traffic utilizing the WG's encapsulations to pass
through
Network Address Translators (NATs) and/or firewalls in some circumstances;
the
WG will endeavor to design NAT- and firewall-friendly protocols that do not
dynamically select target ports or require Application Level Gateways. 

Effective implementations of some IP transports for the encapsulated
protocols
are likely to require hardware acceleration; the WG will consider issues
concerning
the effective implementation of its protocols in hardware. 

The standard internet checksum is weaker than the checksums use by other
implementations of the protocols to be encapsulated. The WG will consider
what
levels of data integrity assurance are required and how they should be
achieved. 

The WG will produce requirements and specification documents for each
protocol
encapsulation, and may produce applicability statements. The requirements
and
specification documents will consider both disk and tape devices, taking
note
of the variation in scale from single drives to large disk arrays and tape
libraries, although the requirements and specifications need not encompass
all such devices. 

The WG will not work on: 

- Extensions to existing protocols such as SCSI and Fibre Channel beyond
	those strictly necessary for the use of IP-based transports. 
- Modifications to internet transport protocols or approaches requiring
	transport protocol options that are not widely supported, although
the
	WG may recommend use of such options for block storage traffic. 
- Support for environments in which significant data loss or data corruption
	is acceptable. 
- File system protocols. 

Operational Structure: 

Due to the scope of the task and the need for parallel progress on multiple
work items, the WG effort is organized as follows: 

A technical coordinator will be identified and selected for each protocol
encapsulation adopted as a work item by the group. This person will be
responsible for
coordinating the technical efforts of the group with respect to that
encapsulation,
working with and motivating the document editors, and evangelizing the
group's work
within both the community and relevant external organizations such as T10
and T11. 

In addition to the normal responsibilities of IETF working group chairs, the
IPS
chairs are responsible for selection of coordinators, identifying areas of
technical
commonality and building cross-technology efforts within the group. 

Coordinators for initially important encapsulations: 

SCSI over IP (aka iSCSI): John Hufferd (hufferd@us.ibm.com) 
Fibre Channel (FC-2) over IP: Murali Rajagopal (muralir@lightsand.com) 
iFCP: Franco Travostino (travos@nortelnetworks.com) 

The WG will not undertake any new protocol encapsulation work before
successfully
completing WG Last Call on one or more of the encapsulations that it is
currently
working on.

Goals and Milestones:

Done    Submit final version of iSCSI requirements draft to the IESG for
consideration
		as an Informational RFC.
Oct 01  Post initial version of draft specifying DHCP usage for booting via
iSCSI,
		and revised version of iSCSI boot draft on Internet-Draft
servers.
Dec 01  Meet at Salt Lake City IETF meetings with goal of closing all issues
for main
		protocol specifications.
Feb 02  WG Last Calls on main protocol specifications (iSCSI, iSCSI
naming/discovery
		FCIP, iFCP, FC common encapsulation).
Mar 02  Meet at Minneapolis IETF meetings with goal of closing all issues
for all
		other drafts.
Apr 02  Submit main protocol specifications to IESG.
Apr 02  WG Last Calls on SLP usage, iSCSI boot and iSNS drafts.
Jun 02  Submit SLP usage, iSCSI boot and iSNS drafts to IESG.
Jun 02  WG Last Calls on MIBs
Jul 02  Meet at Yokohama IETF meetings to deal with any remaining issues and
consider
		what (if any) additional work the WG should undertake.
Aug 02  Submit MIB drafts to IESG.