RE: Last Call TMF resolution (Was Re: iSCSI Implementer's Guide -WG Last Call status, 2nd try)

Mallikarjun, 

> Let me respond to your note under two separate covers.
> 
> Regarding b1, good catch!  I fixed the text as below:
> 
> d. MUST generate an Asynchronous Message PDU with AsyncEvent=5
(section 8.1) on:
> i) each connection of each third-party session to which at 
> least one affected task is allegiant if 
> TaskReporting=FastAbort is operational on that third-party session,

I think g. needs some related attention, as it assumes a Nop-Out
that won't happen when the AsyncEvent=5 message is not sent.
 
> Regarding b2, I agree with you that it should be at least a 
> SHOULD, if not a MUST (since FastAbort was already negotiated 
> on that session).  However, I do not see which specific text 
> in 4.1.2 you believe is implying a MUST NOT.  Need more help 
> here.  Just to be clear, I now added the following to 
> initiator behavior in 4.1.3:
> 
> c. MUST respond to each Async Message PDU with AsyncEvent=5 
> as defined in section 8.1 (this step also applies when the 
> initiator is receiving the Async Message in the third-party role).

The 4.1.2 problem is omission of text.  4.1.2 never covers the
possibility that one could use FastAbort on a third-party session
when the TMF arrived on a non-FastAbort session.  I interpret this
as "MUST NOT" on the theory that this area of task management is
tightly specified, and hence both 4.1.2 and 4.1.3 come with
"MUST NOT do anything else" requirements.  We'd be better off
explicitly explaining what to do.

Thanks,
--David

 
> ----- Original Message ----
> From: "[email protected]" <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Sent: Wednesday, January 24, 2007 5:34:41 PM
> Subject: [Ips] iSCSI Implementer's Guide - WG Last Call 
> status, 2nd try
> 
> 
> Your WG chair has resurfaced and apologizes for being
> incommunicado these past few weeks (took a badly needed
> vacation for a couple of weeks, including from email,
> and have been digging out ever since).  In the time since
> my previous WG Last Call status message, three things
> appear to have happened:
> 
> a) Issue (2) has been resolved on the list with new text
>     in the -04 version of the draft.  I thank everyone
>     involved.
> b) There was some discussion of behavior of task management
>     functions that affect more than one initiator when
>     not all the initiators have the TaskReporting key
>     set to FastAbort.
> c) There was some discussion of the Response Fence.
> 
> --- b) Task management when not all initiators use FastAbort.
> 
> I believe the rough consensus of the WG is that FastAbort
> can only be used on a session that has negotiated its use
> (i.e., the new TaskReporting key was negotiated to FastAbort).
> This has a couple of implications:
> 
> b1) This means that if the session that sent the TMF uses
> FastAbort but some other affected iSCSI session doesn't,
> FastAbort MUST NOT be used with that other affected session.
> 
> b2) In the reverse direction, if the session that sent the TMF
> does not use FastAbort, but some other affected session does,
> FastAbort could be used with that other affected session.
> 
> Each of these raises an issue:
> o This text in Section 4.1.3 on target behavior violates b1):
> 
>      d. MUST generate an Asynchronous Message PDU with AsyncEvent=5 
>           (section 8.1) on: 
>           i)  each connection of each third-party session to which at 
>             least one affected task is allegiant, and 
> 
> --> The target has to first check whether the third-party session
>     uses FastAbort, otherwise the AsyncEvent=5 message will be
>     rather unexpected (e.g., by a 3720-only initiator).  This
>     text needs to be corrected.
> 
> o The text in Section 4.1.2 currently prohibits FastAbort on
>     third party sessions when FastAbort is not used on the
>     session that sent the TMF (i.e., the "could" in b2 above
>     is a "MUST NOT" with the current text).
> 
> --> Any requirement option (MUST/SHOULD/MAY/MUST NOT/SHOULD NOT)
>     appears to work here, but we need to consciously make a
>     decision.  I lean towards "SHOULD" instead of "MUST NOT".
>     Keep in mind that this is for a session for which usage
>     of FastAbort has been negotiated.  Any change from the
>     current "MUST NOT" will entail a fair amount of editing
>     work.
> 
> --- c) The Response Fence
> 
> I believe that the WG rough consensus of the discussion about
> the Response Fence functionality is that the functionality is
> needed to deal with the ordering issues in the cases called
> out in Section 3.3.3 of the -04 version of the draft (note
> that the Initiator MUST negotiate TaskReporting=ResponseFence
> or TaskReporting=FastAbort before relying on response fence
> behavior).
> 
> Unfortunately, I have to object to Section 3.3.1, which appears
> to be trying to modify SAM-2 to add the Response Fence flag.
> That can't be done in IETF, and any T10 modification would be
> to SAM-4, whereas iSCSI is still based on SAM-2.  I think the
> mention of SAM-2 and model of the interface between SCSI and
> a SCSI transport needs to be removed from Section 3.3.1.  The
> items numbered (1) and (2) in that section look ok (and in
> fact useful to keep) - the problematic text is that which
> suggests the existence of a "Response Fence flag" in the
> abstract interface between SCSI and the SCSI transport (e.g.,
> iSCSI) along with the mention of "SCSI protocol interface
> model" in Section 3.3.  The upshot will be that Response
> Fence behavior will be specified in a fashion that makes it
> only applicable to the cases spelled out in Section 3.3.3.
> 
> ------------------
> 
> So, I think we need further list discussion of the b) and c)
> issues, including what the b2) requirement level should be.
> 
> I will monitor this discussion on at least a daily basis in
> the hope of driving it to a relatively prompt conclusion, and
> I will carefully read the -04 version of the draft in the
> interim to see if I turn up anything else that may need
> attention.
> 
> 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 protected]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: Thursday, December 28, 2006 3:27 PM
> To: [email protected]
> Subject: [Ips] iSCSI Implementer's Guide - WG Last Call status
> 
> The Working Group Last Call on this draft nominally ended on
> December 18th, but there was no reason to treat that as a hard
> cutoff.  I am now ending the WG Last Call on this draft, although
> list discussion of issues should be continued.
> 
> There have been two issues raised during this WGLC:
> (1) Task Management - how to deal with uncooperative third-
>     party initiators.  This issue has been resolved
>     on the list.
> (2) Target checks - whether to discourage targets from
>     checking for initiator mistakes that the target can
>     tolerate.  At the moment, I think the "rough consensus"
>     of the WG is not to do this - if anyone other than
>     Eddy thinks this is important to clarify, they need
>     to speak up promptly after the holidays.
> 
> The process from here is that Mallikarjun will submit a
> revised version of the draft in the near future (there are
> still some details to be worked out on the list).  I will
> be completely out of action (no email) the first two weeks
> of January, so there will be time for people to check for
> problems/issues/etc.  I will check the revised draft and
> send it to Lars with a request for RFC publication sometime
> in the second half of January (probably during the week of
> January 22nd).
> 
> 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 protected]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------

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