Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: from osgood.ece.cmu.edu (OSGOOD.ECE.CMU.EDU [128.2.129.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h4NMVw308173 for ; Fri, 23 May 2003 18:31:58 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix, from userid 953) id 807D395; Fri, 23 May 2003 18:31:57 -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 C883E8E; Fri, 23 May 2003 18:31:50 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix) id D81BF89DB; Fri, 23 May 2003 18:31:33 -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 C728689D6 for ; Fri, 23 May 2003 18:31:33 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix) id 7918683; Fri, 23 May 2003 18:31:33 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix, from userid 953) id 4B5EC86; Fri, 23 May 2003 18:31:33 -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 664BD83 for ; Fri, 23 May 2003 18:31:29 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix, from userid 363) id 346DA89DC; Fri, 23 May 2003 18:31:29 -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 50D1A89D6 for ; Fri, 23 May 2003 18:31:27 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix) id BAE0D7A; Fri, 23 May 2003 18:31:26 -0400 (EDT) Delivered-To: ips@ece.cmu.edu Received: by hazard.ece.cmu.edu (Postfix, from userid 953) id 93ADE98; Fri, 23 May 2003 18:31:26 -0400 (EDT) Received: from mail.ivivity.com (unknown [64.238.111.99]) by hazard.ece.cmu.edu (Postfix) with ESMTP id E48E77A for ; Fri, 23 May 2003 18:31:18 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <2CY0TCFB>; Fri, 23 May 2003 18:31:18 -0400 Message-ID: From: Eddy Quicksall To: "Julian_Satran@Il.Ibm.Com (julian_satran@il.ibm.com)" , "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)" Subject: FW: iSCSI: TargetPortalGroupTag for discovery Date: Fri, 23 May 2003 18:31:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3217B.06EC9D90" Sender: owner-ips@ece.cmu.edu Precedence: bulk X-Spam-Status: No, hits=-11.1 required=5.0 tests=BAYES_10,HTML_70_80,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_01C3217B.06EC9D90 Content-Type: text/plain 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_01C3217B.06EC9D90 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message

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_01C3217B.06EC9D90--