Re: IPS Draft charter revision

[Mark Bakke <mbakke@cisco.com>]

David-

I'd like to see the iSCSI MIB last called separately, since
it will be ready as soon as the iSCSI protocol is ready, and
it has no dependencies on the other MIBs.

Thanks,

Mark

Keith McCloghrie wrote:
> 
> As you say, the iSCSI MIB would seem to be the only one which is likely
> to be done early next year.  So, maybe it's the only one worth
> separating out.
> 
> Keith.
> 
> > I can do that, with the caveat that each MIB needs to be
> > Last Called after its associated protocol.  I'm guessing
> > that the iSCSI MIB will be done well before the others.
> > Are there any other MIBs that seem likely to be ready
> > around the end of the year?  In practice, there's no
> > problem with completing things before the milestone date on
> > the charter.
> >
> > Thanks,
> > --David
> >
> > > -----Original Message-----
> > > From: Keith McCloghrie [mailto:kzm@cisco.com]
> > > Sent: Friday, August 31, 2001 2:13 PM
> > > To: Black_David@emc.com
> > > Cc: ips@ece.cmu.edu
> > > Subject: Re: IPS Draft charter revision
> > >
> > >
> > > David,
> > >
> > > The schedule below lumps all the MIBs together in the Milestones.
> > > However, the various MIBs are at different stages of development.
> > > I would expect that the first MIB to be completed does not need to
> > > wait for the last.  Do you want to reflect this in the schedule ?
> > >
> > > Keith.
> > >
> > > > 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.
> > > >
> > >
> >

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054