Subject: [Isms] Tmsm#3: session reuse - continued

From: "David Harrington" <[email-masked]>
Date: Fri, 16 Feb 2007 09:49:02 -0500

This was a response to Bert that I left out of the earlier posting:

"Sessions are a transport-specific issue, and are controlled by a
transport model. A transport model has no idea which application has
requested that a message be sent; it typically only knows
transportDomain/Address and securityName/Model/Level. If a session
already exists that matches those parameters, it reuses it. The
transport model does not necessarily know whether the session was
first established to send a request or a notification.

I'm not sure if the transport model actually needs to deal with this.
The message MAY be dropped on the floor when a notification is sent to
a port that is enabled only for request/response traffic, or a request
was  sent to a port configured only for notification traffic, or an
agent sends a GET-request to an NMS. It seems unlikely a response
would be sent to a port unwilling to accept responses, since we
usually send the response back to the port the request came from. 

The message-processing model keeps track of outstanding
expectResponses, so it should probably be aware that no response
message was returned, when the remote node dropped a request message
(including inform) on the floor. If it was a trap, it would not be
expecting a response anyway. If it is an unexpected GET, there will be
no registered application for that pduType, so it would be dropped
anyway.

So it should probably be the message processing model or the
application that needs to know how to deal with dropped messages.

I removed the text that says a transport model needs to define a
stndard behavior."

David Harrington
[email-masked] 
[email-masked]
[email-masked]

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Feb 2007 14:17:57 +0100

On Fri, Feb 16, 2007 at 09:49:02AM -0500, David Harrington wrote:

[...]
 
> I removed the text that says a transport model needs to define a

I am not sure where we stand with this issue. I believe the original
motivaion for this "feature" were attempts to work towards call-home
support. For example, one could a "manager" establish a CG/CR session
and configure the target MIBs to direct notifications towards the same
session.

>From the viewpoint of a transport model, you do not really know / care
what PDU type is contained in a message and if there is a matching
session, you could just send the message over it. Is the issue whether
we do or do not want this behaviour? Or is the issue that we want to
classify sessions into CG/CR sessions and NO/NR sessions? This would
be difficult wrt. the existing ASIs.

Or is the issue simply that the ID said messages can be dropped?  I
would say that this is not really a new feature. Even today, if you
send CG PDUs to a NR, the messages will be dropped and if you send NO
PDUs to a CG, messages will be dropped as well. In other words, we may
choose to actually say nothing about it in the TSMS document.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany