Re: target opcodes allowed for discovery sessions

"Mallikarjun C." <[email protected]>
Newsgroups gmane.ietf.ips
Message-ID <[email protected]>
Yes, my recollection matches Ken's.

In the absence of objections, I'll add a note to the implementer's draft about it - that targets SHOULD NOT send any responses other than a Text Response and Logout Response on a Discovery session, once in full feature phase.  Along with an implementation note that a target may simply drop the connection when it would have requested a Logout via an Async Message on Normal sessions.

Mallikarjun


----- Original Message ----
From: "Sandars, Ken" <[email protected]>
To: Eddy Quicksall <[email protected]>; Paul Hughes <[email protected]>; Julian Satran <[email protected]>
Cc: IP Storage Mailing List (E-mail) <[email protected]>
Sent: Tuesday, November 21, 2006 1:23:13 PM
Subject: RE: [Ips] target opcodes allowed for discovery sessions


Hello Gentlemen,

Section 12.21 SessionType states for a discovery session:

The only requests a target accepts in this type of session are a text
request with a SendTargets key and a logout request with reason "close
the session".

I can't find any text to prevent the target from sending a Nop-In or an
Async Message. I do remember a long discussion about whether to allow
the AM to request logout, but thought the answer was a loud "no, keep it
simple, drop the connection".

Cheers
Ken


________________________________

From: Eddy Quicksall [mailto:[email protected]] 
Sent: Wednesday, 22 November 2006 03:47
To: Paul Hughes; Julian Satran
Cc: IP Storage Mailing List (E-mail)
Subject: Re: [Ips] target opcodes allowed for discovery sessions


When I look at 3.3 it says the target must reject all other requests.
But I don't think a NOP-out is a request. Is there another part of the
draft that says the initiator can't send a NOP-out during discovery?

Eddy

    ----- Original Message ----- 
    From: Julian Satran <mailto:[email protected]>  
    To: Paul Hughes <mailto:[email protected]>  
    Cc: IP Storage Mailing List (E-mail) <mailto:[email protected]>  
    Sent: Tuesday, November 21, 2006 2:38 AM
    Subject: Re: [Ips] target opcodes allowed for discovery sessions


    As I re-read the draft I can't find any text that forbids a
target to send NOP-IN in a discovery session. 
    But that was definitely not the intent and don't be surprised if
some initiator will drop your session. 
    Also Mallikarjun may want to mention this oversight in the
implementation guide. 
    
    Julo 
    
    
    
    "Paul Hughes" <[email protected]> 

    21/11/06 06:11 

        
        To
        "IP Storage Mailing List \(E-mail\)" <[email protected]> 
        cc
        
        Subject
        [Ips] target opcodes allowed for discovery sessions    

            

    


    Is a target allowed to send an Asynchronous Message PDU to
request a logout of a discovery session? 

    Is a target allowed to send a NOP-In PDU to an initiator on a
connection that's part of a discovery session?  If so, should I assume
that the TTT must be 0xFFFFFFFF since the initiator isn't allowed to
send a NOP-Out PDU on a discovery session? 

    Thanks, 
    Paul 

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

    ________________________________

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


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


 
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.