RE: iSCSI-Asynch event code

["THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>]

Martins,

I think this should be added, but I don't see any need to say that the initiator send an empty Text Request. It is possible (perhaps even likely in the event of a path change) that the initiator will decide to start a negotiation at the same time that the target sends the Asynch Message requesting negotiation. If so, the Initiator could send Text Negotiation before it has received (or processed) the message from  the target. Therefore, the target has to accept the initiator starting the negotiation with its own keys.

Also, all the standard keys currently allowed in FFP are declarations so it doesn't matter who offers keys first. 

An example:
Initiator and target are using a sync steering method where PDUs are aligned to transport segments/packets.
A path change occurs that reduces the path MTU.
Both the initiator and target detect the new MTU.
                       Async message request negotiation <- t
i -> Text negotiation (MaxRecvPDUDataSize)               -> t
i <-   Async message arrives 
but the negotiation has already started so the initiator doesn't need to take action on it. 

Regards,
Pat

-----Original Message-----
From: Martins Krikis [mailto:mkrikis@yahoo.com]
Sent: Wednesday, June 12, 2002 1:41 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI-Asynch event code


I don't mind this code being added for completeness
sake, nor will I be overly disappointed if it isn't.

If it is added, however, perhaps we should go half
a step farther and demand that the Text Request coming
from the initiator MUST be empty? That way the target
is
really "in charge" and may _originate_ any key
negotiable
in FFP. Just my $.02. Comments?

Martins Krikis, Intel Corp.

Disclaimer: These are my opinions and
            may not be my employer's.



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com