iSCSI: Last 48 hr changes

[Black_David@emc.com]

> David, what is your (working group chair) take on 48 hr changes ?

Bill is basically correct - the last 48h check is supposed to catch
editorial problems and the like, especially those with unintended
technical consequences.  The right thing to do at this point is
to produce an Internet-Draft containing all of the errata and the
like that may be candidates for the 48h check and then the WG
chairs can determine whether the changes are appropriate (Julian's
agreement with an email thread is not the final authority).  The
choice for changes that are needed is essentially putting them into
the published RFC vs. putting them on the RFC Editor's site as
errata (see: http://www.rfc-editor.org/errata.html).  To Julian's
credit he did say "if I can do".

Redirection seems to be a problem area, as we have not only the
two changes below, but also the gilligan draft that requests
specific retry behavior for failures after redirection be mandated,
although I've seen little interest in that draft on the list.
I'm somewhat concerned that trying to patch redirection at this
late stage may just introduce further problems.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------


> -----Original Message-----
> From: Bill Strahm [mailto:bill@strahm.net] 
> Sent: Monday, July 14, 2003 4:08 PM
> To: Dean Scoville
> Cc: Julian Satran; 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
> > 
>