Subject: RE: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement

From: [email-masked]
Date: Sat, 3 Dec 2005 13:54:03 -0500

Independent of "legal best", "practical best" is the Implementers
Guide where we can say things like "not REQUIRED" to make it
abundantly clear.
 
RFC Errata processing is currently broken for all practical purposes
at the RFC Editor.
 
Thanks,
--David
---------------------------------------------------- 
David L. Black, Senior Technologist 
EMC Corporation, 176 South St., Hopkinton, MA  01748 
+1 (508) 293-7953             FAX: +1 (508) 293-7786 
[email-masked]        Mobile: +1 (978) 394-7754 
---------------------------------------------------- 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian
Satran
Sent: Saturday, November 19, 2005 7:59 PM
To: William Studenmund
Cc: [email-masked]; Pittman, Joseph; [email-masked]
Subject: Re: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement

You are right and we have to fix this somewhere (errata is probably the
legal best). Julo 

William Studenmund <[email-masked]> 
Sent by: [email-masked] 

15-11-05 13:28 

To
Julian Satran/Haifa/IBM@IBMIL 

cc
[email-masked], "Pittman, Joseph" <[email-masked]> 

Subject
Re: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement

On Nov 15, 2005, at 1:29 AM, Julian Satran wrote:

> William Studenmund <[email-masked]> wrote on 14-11-2005 
> 21:26:31:
>
>  > Waiting for other sessions to finish any form of processing is my
>  > biggest concern with how we handle aborts.
>
> Joseph concern (as I read it) was related to waiting for status ack on 
> other nexi before handing the initiator the response to the TM 
> command.
> This is not required by iSCSI.

Actually, I was just re-reading the Abort Task Set and Clear Task Set 
text, and the status ack requirement is in RFC 3720. It's in section 
10.6.2 on page 136, in step d) of the "The target:" events section:

         d) Takes note of last-sent StatSN on each of the connections in
            the iSCSI sessions (one or more) sharing the affected task
            set, and waits for acknowledgement of each StatSN (may
            solicit for acknowledgement by way of a NOP-In).  If some
            tasks originate from non-iSCSI I_T_L nexi then the means by
            which the target insures that all affected tasks have
            returned their status to the initiator are defined by the
            specific protocol.

So the concern Joseph has (which I also have as best I understand 
everyone's position) does apply to RFC 3720. :-|

Take care,

Bill
_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips