SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: TargetPortalGroupTag for redirection



    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
    > 
    
    
    


Home

Last updated: Tue Aug 05 12:46:13 2003
12771 messages in chronological order