In-Reply-To: <2A8D600C919D2D41A3DAA2D2FEC71714471374@homer.qlogic.org>
To: "Dean Scoville" <dean.scoville@qlogic.com>
Cc: ips@ece.cmu.edu
Subject: RE: TargetPortalGroupTag for redirection
MIME-Version: 1.0
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Message-ID: <OF0C443B7F.C5535F0E-ONC2256D64.002EDCC1-C2256D64.003CA6D3@telaviv.ibm.com>
Date: Tue, 15 Jul 2003 14:02:53 +0300
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Dean,

The last 48h is only for editorial changes.
However I think that I will try to publish the errata - as I know it now - 
sometime during the next month and send a note to the list.

Again don't expect any changes - only editorials and perhaps 
clarifications.

Regards,
Julo



"Dean Scoville" <dean.scoville@qlogic.com> 
14-07-03 21:54

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ece.cmu.edu>
Subject
RE: TargetPortalGroupTag for redirection






Julian,
I've heard several references to changes that will be made during
the "last 48h". When do you expect the "last 48h" window to occur?
Is the delay due to a backlog at the RFC editor?

Do you have a list of the changes that are planned for the "last 48h"
(or a new iSCSI draft that includes them) so we can start upgrading
our Draft 20 implementations to be compliant with what will 
eventually become the iSCSI RFC?

thanks,
Dean

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, July 11, 2003 10:06 PM
To: Robert D. Russell
Cc: ips@ece.cmu.edu
Subject: Re: TargetPortalGroupTag for redirection


Bob,

Your interpretation is correct.
I will see what I can do on the text (if I can do) during the "last 48h".

Thanks,
Julo



"Robert D. Russell" <rdr@io.iol.unh.edu> 
10-07-03 16:58

To
ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL
cc

Subject
TargetPortalGroupTag for redirection






Julian:

The 6th UNH iSCSI Plugfest has been underway since Monday, 7 July,
with 22 companies participating.  Yesterday we came up with the
first issue relating to the standard, and it is a minor one that
actually is related to the discussion on the mailing list at the
end of May under the thread TargetPortalGroupTag for discovery.

The issue here involves the use of the TargetPortalGroupTag
during discovery.  Section 10.13.5 says:
  "All of the redirection status class responses MUST return one
  or more text key parameters of the type "TargetAddress", which
  indicates the target's new address."
and Section 12.8 says:
  "If the TargetAddress is returned as the result of a redirect
  status in a login response, the comma and portal group tag
  MUST be omitted."

However, Section 5.3.1 says:
  "During the Login Phase the iSCSI target MUST return the
  TargetPortalGroupTag key with the first Login Response PDU
  with which it is allowed to do so (i.e., the first Login
  Response issued after the first Login Request with the C bit
  set to 0) for all session types."

where as a result of the discussion on the mailing list in May,
the end of that last quote should probably now read:
  "for Normal sessions."

There seems to be an inconsistency in the case of redirection,
because on the one hand, the target MUST NOT supply the
target portal group tag with the required TargetAddress,
but on the other hand it MUST supply the target portal group tag
in the required TargetPortalGroupTag key.

Presumably, the target portal group tag is omitted from the
TargetAddress because it is not meaningful during a redirection,
and therefore, the TargetPortalGroupTag key should not be
required if the first Login Response is a redirection response.
This is especially relevant because the target at the new
address could presumably supply a different TargetPortalGroupTag
value.

Is this the correct interpretation?

The issue is complicated a bit by the fact that redirection is
not required to occur on the first Login Response, and continuation
of the Login Phase may depend on the initiator knowing the target
portal group tag value.  Therefore, the first Login Response
should probably be allowed to omit the TargetPortalGroupTag key only
when it is a redirection or is a response to a first Login Request
that includes the SessionType=Discovery key.

Comments?

Thanks,
Bob Russell