Draft Pgh. Agenda and charter

[Black_David@emc.com]

Draft agenda for Pittsburgh along with latest rev.
to proposed charter follow (both should appear on the
agenda area of the IETF web site).

Important Agenda notes:

The purpose of the Overview and Rationale talks is
review of major design decisions.  The 15 minutes
available for FC-over-IP limits discussion to major
issues; detailed review of FC-over-IP will not be
done during the ips meeting.  The 15 minute slots should
be no more than 10 min of presentation; iSCSI Multiple
Channels and Error Recovery should be no more than 5
min of presentation.  Presenters should assume that
the audience has read the drafts, and hence only cover
material necessary to get to design decisions, questions,
issues, etc.  The  5 min time slots are for updates only;
clarification questions will be entertained if time permits,
but discussion will need to take place on the mailing list.
Expect time slots to be enforced in some fashion.

Could those who are going to be presenting each of the
iSCSI items on the agenda please contact me and let me
know who's doing what.  I believe I know who the presenters
are for the other segments.

Thanks, --David

IP Storage (ips) BOF DRAFT Agenda - subject to change

-- Organizational Matters (20 min)

5 min   Agenda Bashing
5 min   A few words from the AD
10 min  Charter Bashing

	Draft charter for bashing is appended to this
	agenda.  Please bash the charter on the 
	mailing list in preference to in the meeting,
	as the charter bashing time can be productively
	used for other purposes.

-- Internet SCSI (iSCSI) (80 min)

	draft-haagens-ips-iscsireqs-00.txt
	draft-satran-iscsi-01.txt
	draft-bakke-iscsimib-00.txt

15 min  iSCSI Overview and Rationale
30 min  iSCSI Security, may include draft-klein-iscsi-security-01.txt
15 min  iSCSI Multiple Channels
15 min  iSCSI Error Recovery
5 min   iSCSI MIB

-- Related Matters (20 min)

15 min  FC-over-IP Overview and Rationale
	draft-ietf-ipfc-fcoverip-02.txt
5 min   SEP and Parallel SCSI update
	draft-wilson-sep-00.txt

IP Storage (ips) Working Group Proposed Charter - DRAFT 5

There is significant interest in using IP-based networks to transport
block storage traffic.  This group will pursue the pragmatic approach of
encapsulating existing block storage protocols, such as SCSI and certain
Fibre Channel protocols, 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
block
storage protocols.  Standards for those protocols 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 and in that case 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 storage 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 is acceptable.  This has implications
for both the choice of transport protocols and design of the
encapsulation(s).  Encapsulations of the storage protocols may require
quality of service assurances (e.g., predictable latency) to operate
successfully; the WG will consider what assurances are appropriate and
how to provide such assurances in shared traffic environments
based on existing IETF QoS mechanisms such as Differentiated Services.

Use of an IP-based transport raises issues that do not occur in existing
storage transports.  The WG will address at least the following issues:
- Congestion control suitable for shared traffic network environments, such
as
	the Internet.
- Security measures, including authentication and privacy, sufficient
	to defend against threats up to and including those that can be
	expected on a public network.
- Storage naming and discovery mechanisms for block storage services
	on IP-based networks, including both discovery of storage for
	access by the discovering entity, and discovery for management.
- Management, including appropriate MIB definition.
The WG will address security and congestion control as an integral part
of its protocol(s); naming, discovery, and management are important related
issues, but may be addressed in companion documents. 

The WG will consider issues raised by bridges and gateways to existing
implementations of block storage protocols in order to support effective
interoperability of the protocols developed in the working group with other
implementations and/or encapsulations of the same block storage protocol(s).
The WG will strive to support the approaches to discovery, multi-pathing,
and booting taken by the existing block storage protocols it encapsulates
at the levels of those protocols.

It may be necessary for block storage traffic 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 block storage traffic
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 used by existing
block storage implementations.  The WG will consider what levels of data
integrity assurance are required for block storage traffic over IP networks
and how they should be achieved.

The WG will produce a framework document describing the encapsulation or
encapsulations it intends to pursue, and requirements, applicability
and protocol specification documents for each encapsulation.  The framework
document will consider whether both end-system and gateway node (including
gateways to Fibre Channel) requirements can be accommodated in a single
protocol
family (e.g., as has been done by the IP Security Protocol).  The
applicability
and requirements documents will consider both disk and tape devices and take
note of the variation in scale from single drives to large disk arrays and
tape libraries; the protocols need not be applicable to all such devices.

The WG will not work on:
- Extensions to existing block storage protocols 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.
 
Milestones

Aug 00 Initial meeting in Pittsburgh.  Discuss selection of encapsulation
	approach or approaches.
Sep 00 Submit initial version of framework draft on encapsulation
	approaches.
Dec 00 Discuss framework draft, as well as requirements, applicability
	and protocol specification drafts for at least one protocol
	encapsulation at IETF meeting in San Diego.
Feb 01 Submit requirements, applicability, and protocol specification 
	drafts for at least one protocol encapsulation to the IESG for
	consideration as a Proposed Standard.
Mar 01 Discuss related drafts (e.g., MIBs, discovery) for at least the
	first protocol encapsulation at IETF meeting in Minneapolis.  
Jun 01 Submit MIB and discovery draft to the IESG.  Begin revision
	of WG charter as appropriate in consultation with ADs.
Aug 01 Meet at IETF meeting to close any open issues and finish any
outstanding
	work items.