RE: IPS Draft charter revision

[Black_David@emc.com]

Ok, revised milestones will have iSCSI MIB going before
the other MIBs - keep in mind that we can always do things
earlier than the milestone dates.  --David

> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Tuesday, September 04, 2001 10:29 AM
> To: Keith McCloghrie
> Cc: Black_David@emc.com; ips@ece.cmu.edu
> Subject: Re: IPS Draft charter revision
> 
> 
> 
> 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
>