In-Reply-To: <20030714160750.A5507@strahm.net>
To: Bill Strahm <bill@strahm.net>
Cc: Dean Scoville <dean.scoville@qlogic.com>, ips@ece.cmu.edu
Subject: Re: TargetPortalGroupTag for redirection
MIME-Version: 1.0
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Message-ID: <OF9B63BEE4.EAE2B2CC-ONC2256D64.00243DCF-C2256D64.003CA6A5@telaviv.ibm.com>
Date: Tue, 15 Jul 2003 14:02:52 +0300
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I did not see it as anything else than I clarification.
It can be made in the main document or in an informational document 
sometime in the future.
But there will be no draft-21!

The 48h are only editorial.
The draft is waiting in the editor queue for the related security drafts 
to pass (mainly I think the AES).

Julo



Bill Strahm <bill@strahm.net> 
14-07-03 23:07

To
Dean Scoville <dean.scoville@qlogic.com>
cc
Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
Subject
Re: TargetPortalGroupTag for redirection






Be very careful.  I would be worried about 48h changes that change 
implementations.  The 48h check is supposed to be for fixing typos
and formating problems, not changing technical decsions.

If you need to make substatiative comments (that would require 
implementation
changes) I would advise pulling the approval, make the final changes to 
get 
something correct and ask for republication of a draft -21

David, what is your (working group chair) take on 48 hr changes ?

Bill
On Mon, Jul 14, 2003 at 11:54:24AM -0700, Dean Scoville wrote:
> 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
>