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 h4NKNv301751 for ; Fri, 23 May 2003 16:23:57 -0400 (EDT) Received: by bache.ece.cmu.edu (Postfix, from userid 953) id BCD7784; Fri, 23 May 2003 16:23:56 -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 B02B176; Fri, 23 May 2003 16:23:46 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix) id 3082A89D2; Fri, 23 May 2003 16:23:30 -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 1E2498953 for ; Fri, 23 May 2003 16:23:30 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix) id DF09F83; Fri, 23 May 2003 16:23:29 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix, from userid 953) id B862C8E; Fri, 23 May 2003 16:23:29 -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 9391183 for ; Fri, 23 May 2003 16:23:26 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix, from userid 363) id 8034589D5; Fri, 23 May 2003 16:23: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 EE24D8953 for ; Fri, 23 May 2003 16:23:24 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix) id D53FE75; Fri, 23 May 2003 16:23:24 -0400 (EDT) Delivered-To: ips@ece.cmu.edu Received: by hazard.ece.cmu.edu (Postfix, from userid 953) id 19A057E; Fri, 23 May 2003 16:23:23 -0400 (EDT) Received: from mail.ivivity.com (unknown [64.238.111.99]) by hazard.ece.cmu.edu (Postfix) with ESMTP id 3D05C75 for ; Fri, 23 May 2003 16:23:20 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <2CY0TCCL>; Fri, 23 May 2003 16:23:19 -0400 Message-ID: From: Eddy Quicksall To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" , "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)" Subject: RE: iSCSI: TargetPortalGroupTag for discovery Date: Fri, 23 May 2003 16:23:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32169.25A81140" 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_01C32169.25A81140 Content-Type: text/plain 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_01C32169.25A81140 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message

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_01C32169.25A81140--