Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h4OLZw303061 for ; Sat, 24 May 2003 17:35:58 -0400 (EDT) Received: by bache.ece.cmu.edu (Postfix, from userid 953) id 458FA7B; Sat, 24 May 2003 17:35:58 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by bache.ece.cmu.edu (Postfix) with ESMTP id 8E10D7B; Sat, 24 May 2003 17:35:49 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix) id 3A56989DF; Sat, 24 May 2003 17:35:32 -0400 (EDT) Received: from osgood.ece.cmu.edu (OSGOOD.ECE.CMU.EDU [128.2.129.25]) by sos.ece.cmu.edu (Postfix) with ESMTP id 26E2A89DE for ; Sat, 24 May 2003 17:35:32 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix) id DF19182; Sat, 24 May 2003 17:35:31 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix, from userid 953) id AF4B697; Sat, 24 May 2003 17:35:31 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by osgood.ece.cmu.edu (Postfix) with ESMTP id C96CF82 for ; Sat, 24 May 2003 17:35:26 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix, from userid 363) id 996EE89E0; Sat, 24 May 2003 17:35:26 -0400 (EDT) X-Original-To: ips@sos.ece.cmu.edu Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24]) by sos.ece.cmu.edu (Postfix) with ESMTP id E304D89DE for ; Sat, 24 May 2003 17:35:24 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix) id 9F46F87; Sat, 24 May 2003 17:35:24 -0400 (EDT) Delivered-To: ips@ece.cmu.edu Received: by hazard.ece.cmu.edu (Postfix, from userid 953) id 1975993; Sat, 24 May 2003 17:35:23 -0400 (EDT) Received: from mail.ivivity.com (unknown [64.238.111.99]) by hazard.ece.cmu.edu (Postfix) with ESMTP id D7FF291 for ; Sat, 24 May 2003 17:35:18 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <2CY0TCPH>; Sat, 24 May 2003 17:35:17 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)" Subject: RE: FW: iSCSI: TargetPortalGroupTag for discovery Date: Sat, 24 May 2003 17:35:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3223C.5C172A30" Sender: owner-ips@ece.cmu.edu Precedence: bulk X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,HTML_60_70,HTML_FONT_COLOR_BLUE, HTML_FONT_FACE_ODD,ORIGINAL_MESSAGE version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3223C.5C172A30 Content-Type: text/plain Thanks, I suggest that if the spec is ever revised that there is a statement saying that the target portal group tag does not need to be reported when a target name is not given (ala a discovery session). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, May 24, 2003 1:29 PM To: Eddy Quicksall Cc: Ips@Ece.Cmu.Edu (ips@ece.cmu.edu) Subject: Re: FW: iSCSI: TargetPortalGroupTag for discovery Eddy, I think Marjorie is right - you SHOULD report TargetPortalGroup during a normal session to enable initiators to sense a configuration change if there was one. I will check the text for the typo - thanks - and wording. I think you may ignore it for discovery sessions. Regards, Julo Eddy Quicksall 24/05/03 01:31 To Julian Satran/Haifa/IBM@IBMIL, "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)" cc Subject FW: iSCSI: TargetPortalGroupTag for discovery Julian, Can you comment on this? I would like to not have to report the TargetPortalGroupTag during a discovery session. Eddy -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Friday, May 23, 2003 4:23 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Ips@Ece.Cmu.Edu (ips@ece.cmu.edu) Subject: RE: iSCSI: TargetPortalGroupTag for discovery The definition of SSID says this: The TargetPortalGroupTag key must also be returned the target as a confimation (typo) during connection establishment. Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie.krueger@hp.com] Sent: Friday, May 23, 2003 4:16 PM To: 'Eddy Quicksall'; Ips@Ece.Cmu.Edu (ips@ece.cmu.edu) Subject: RE: iSCSI: TargetPortalGroupTag for discovery I think the wording in the spec says TargetPortalGroupTag should be included in the Login response. It seems that a discovery session where multiple targets are being serviced by the same IP address is a case where TargetPortalGroupTag need not be reported? The intent behind reporting TargetPortalGroupTag is directed towards Full Feature Sessions so that the initiator can verify that it's discovery information is still valid. -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Friday, May 23, 2003 1:03 PM To: Ips@Ece.Cmu.Edu (ips@ece.cmu.edu) Subject: iSCSI: TargetPortalGroupTag for discovery I have a question regarding the determination of the Target Portal Group Tag during a discovery session when the TargetName is not supplied. The TargetPortalGroupTag must be reported in the first Login Response for all session types. But without the TargetName, how does the network entity determine which Target Portal Group Tag to report if two different targets in the network entity are using the same IP Address/TCP Port? Eddy ------_=_NextPart_001_01C3223C.5C172A30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Thanks,

 

=

I suggest that if the spec is ever = revised that there is a statement saying that the target portal group tag does = not need to be reported when a target name is not given (ala a discovery = session).

 

=

Eddy

 

=

-----Original = Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, May 24, = 2003 1:29 PM
To: Eddy Quicksall
Cc: Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)
Subject: Re: FW: iSCSI: TargetPortalGroupTag for discovery

 


Eddy,

I think Marjorie is right - you SHOULD report TargetPortalGroup during a = normal session to enable initiators to sense a configuration change if there = was one.
I will check the text for the typo - thanks - and wording. =
I think you may ignore it for discovery sessions.

Regards,=
Julo


Eddy Quicksall <eddy_quicksall@ivivity.com> =

24/05/03 01:31

To

Julian Satran/Haifa/IBM@IBMIL, = "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)" <ips@ece.cmu.edu> =

cc

 

Subject

FW: iSCSI: TargetPortalGroupTag for = discovery

 

 

 




Julian,

 

Can you comment = on this?

 

I would like to = not have to report the TargetPortalGroupTag during a discovery = session.

 

Eddy

 

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] =
Sent: Friday, May 23, 2003 4:23 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); Ips@Ece.Cmu.Edu = (ips@ece.cmu.edu)
Subject: RE: iSCSI: TargetPortalGroupTag for = discovery

 

The definition = of SSID says this:

 

The TargetPortalGroupTag key must also be = returned

the target as a confimation (typo) during connection establishment.

 

 

Eddy

 

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie.krueger@hp.com]
Sent: Friday, May 23, 2003 4:16 PM
To: 'Eddy Quicksall'; Ips@Ece.Cmu.Edu = (ips@ece.cmu.edu)
Subject: RE: iSCSI: TargetPortalGroupTag for = discovery

 

I think the = wording in the spec says TargetPortalGroupTag should be included in the Login response.  It seems that a discovery = session where multiple targets are being serviced by the same IP address is a = case where TargetPortalGroupTag need not be reported?  The intent = behind reporting TargetPortalGroupTag is directed towards Full Feature = Sessions so that the initiator can verify that it's discovery information is still = valid.
-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] =
Sent: Friday, May 23, 2003 1:03 PM
To: Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)
Subject: iSCSI: TargetPortalGroupTag for = discovery

I have a question regarding the determination = of the Target Portal Group Tag during a discovery session when the TargetName = is not supplied.

 

The TargetPortalGroupTag must be reported in = the first Login Response for all session types. But without the TargetName, = how does the network entity determine which Target Portal Group Tag to = report if two different targets in the network entity are using the same IP = Address/TCP Port?

 

Eddy

 

------_=_NextPart_001_01C3223C.5C172A30--