RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types

["Ayman Ghanem" <aghanem@cisco.com>]

Julian,

I stated in my e-mail that I do not want to reopen this issue at this stage.
Leaving it the way it is in draft-14 is perfectly acceptable. Changing "MAY"
to "MUST" with the text per David's last e-mail is also acceptable.

-Ayman


> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Tuesday, July 09, 2002 10:37 PM
> To: Ayman Ghanem
> Cc: Black_David@emc.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types
> Importance: High
>
>
>
> This was subject to a long debate relate to SendTargets.
> The issue was that SendTargets was (with resistance) accepted as a
> "lightweight" discovery.
> We did not want in any way to encourage long-lived discovery sessions as
> there are other and better mechanisms
> to do so (SLP, iSNS) and iSCSI should not have a completely embedded
> discovery (going to IP storage
> should enable you to leverage other protocols for management).
> I will strongly oppose anything that encourages long lived discovery and I
> think that using the last call to reopen
> without any new argument an old and closed issue is an abuse of the
> process.
>
> Julo
>
>
>
>
>                       "Ayman Ghanem"
>
>                       <aghanem@cisco.co        To:
> <Black_David@emc.com>, <ips@ece.cmu.edu>
>
>                       m>                       cc:
>
>                       Sent by:                 Subject:  RE:
> iSCSI: DLB's [T.6] 2.3  iSCSI Session Types
>
>                       owner-ips@ece.cmu
>
>                       .edu
>
>
>
>
>
>                       07/08/2002 06:53
>
>                       PM
>
>                       Please respond to
>
>                       "Ayman Ghanem"
>
>
>
>
>
>
>
>
> David,
>
> The issue that came up before was if a discovery session could be kept
> open,
> why not allow the initiator and target to send NOPs, and allow the target
> to
> send Async messages when new targets become available?
>
> I don't mean to bring up this issue again at this stage, but using "MAY"
> leaves room for implementations that want to support this. If we allow NOP
> and Async PDUs on a discovery session, then changing "MAY" to "MUST" will
> be
> fine.
>
> -Ayman
>
>
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Monday, July 08, 2002 9:19 AM
> > To: aghanem@cisco.com; ips@ece.cmu.edu
> > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types
> >
> >
> > Ayman,
> >
> > Something needs to be cleaned up here, as the current text appears
> > to allow all types of iSCSI PDUs on a discovery session.  I didn't
> > intend to restrict a discovery session to one Send Targets followed
> > by a logout (i.e., it could be kept open with the initiator periodically
> > sending a new Send Targets to see if anything has changed), but I
> > did intend to forbid SCSI commands, task management, etc. on Discovery
> > sessions.  Is that reasonable, or are there additional types of iSCSI
> > PDUs that you want to see allowed for new device notifications?
> >
> > Thanks,
> > --David
> >
> > > -----Original Message-----
> > > From: Ayman Ghanem [mailto:aghanem@cisco.com]
> > > Sent: Sunday, July 07, 2002 12:41 PM
> > > To: ips@ece.cmu.edu
> > > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types
> > >
> > >
> > > I prefer leaving this as "MAY" for implementations that want
> > > to support new
> > > device notifications. There was a discussion on whether
> > > discovery sessions
> > > should be long-lived or not. Using MAY allows both without
> > > breaking any
> > > thing.
> > >
> > > -Ayman
> > >
> > > > [T.6] 2.3  iSCSI Session Types
> > > >
> > > >       b)  Discovery-session - a session opened only for
> > > target discov-
> > > >       ery; the target MAY accept only text requests with
> > > the SendTar-
> > > >       gets key and a logout request with reason "close the session".
> > > >
> > > > Change "MAY" to "MUST", and say that other requests MUST be
> > > rejected.
> > > >
> > >
> >
>
>
>
>
>
>