Re: Last Call TMF resolution

David,

bullet g is saying:
"g. MUST free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once it receives each associated Nop-Out acknowledgement that the initiator generated in response to each Async Message."

It does not assume a Nop-Out always, it simply implies that a Nop-Out ack is received for each Async.  Don't see any issues for legacy initiators that don't send Nop-Outs (which were never sent Asyncs anyway per the new clarification added in bullet d).  Looks alright to me.  Are you OK?


Regarding your issue with 4.1.2 (which you consider as a omission), I tend to slightly differ.  Note that section 4.1.2 is exclusively meant for all implementations - old and new.  So I did not want to put any wording in there that requires them to implement and support FastAbort on third-party sessions as the baseline behavior (that imposes an unfair requirement on all targets to implement unlike initiators which can choose to implement the new semantics).  But your comment OTOH is valid.  So I think the best way to address your comment is put in more text (sigh...) in a new section 4.1.5.  It's attached below.  Take a look and let me know if that's along the lines of what you are looking for or I'm off.....

Thanks.

Mallikarjun




----- Original Message ----
From: "[email protected]" <[email protected]>
To: [email protected]; [email protected]
Sent: Thursday, January 25, 2007 6:35:02 PM
Subject: RE: Last Call TMF resolution (Was Re: [Ips] 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


4.1.4 Affected tasks shared across Legacy & FastAbort sessions
If an iSCSI target implementation is capable of supporting TaskReporting=FastAbort functionality (section 9.1), it may end up in a situation where some sessions have TaskReporting=Legacy operational (Legacy sessions) while some other sessions have TaskReporting=FastAbort operational (FastAbort sessions) even while accessing a shared set of affected tasks (section 4.1.1).

If the issuing session is a Legacy session, iSCSI target implementation is FastAbort-capable and third-party affected session is a FastAbort session, the following behavior SHOULD be exhibited by the iSCSI target layer:
a. Between steps c and d of target behavior in section 4.1.2, send an Asynchronous Message PDU with AsyncEvent=5 (section 8.1) on each connection of each third-party session to which at least one affected task is allegiant.  If there are multiple affected LUs, then send one Async Message PDU for each such LU on each connection that has at least one allegiant affected task.  When sent, the LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.
b. After step e of target behavior in section 4.1.2, free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once each associated Nop-Out acknowledgement is received that the third-party initiator generated in response to each Async Message sent in step a.

If the issuing session is a FastAbort session, iSCSI target implementation is FastAbort-capable and third-party affected session is a Legacy session, the following behavior MUST be exhibited by the iSCSI target layer: Asynchronous Message PDUs MUST NOT be sent on the third-party session to prompt the FastAbort behavior.


 
____________________________________________________________________________________
It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

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