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

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 25 Jan 2007 18:04:07 -0800 (PST)

David,

Welcome back.

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,

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).

Mallikarjun

----- Original Message ----
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, December 28, 2006 3:27 PM
To: [email-masked]
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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

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

____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news

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

---

From: [email-masked]
Date: Thu, 25 Jan 2007 21:35:02 -0500

Mallikarjun, 

(section 8.1) on:
> 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