Subject: The datamodel in Notification Draft

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 12 May 2006 08:45:10 -0400

hi

A few bits of clarification after reading through the discussions.

1. Named profiles in the latest version of the draft are fully specified
in the XML Schema provided. This allows for persistency of subscription
information, just not the actual subscription. The callHome capability
does allow for this persistency though.

2. The information model that Andy sent out didn't seem that different
from what is in the draft already. I believe these were the differences
	- It wasn't specified in XML Schema
	- It used the term table as appose to elements
      - It had an arbitrary index instead of using sessionId and
subscriptionID
	- It better specified the subscriber. As Balasz pointed out, the
current draft if not sufficiently prescriptive. Subscriber is only a
string.

3. I think it would be good if we could look at defining minAccess and
maxAccess in a machine-readable form to publish in parallel with this
document. Failing that, I guess we have no choice but to fall back using
the documentation tag.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 17 May 2006 18:31:23 +0200

Hello,
Some comments to Andy's model:
We need the concept of "Ongoing Notification Session" (subscription in the draft)
We need this as we do not want to open a new session for each notification for each 
target. We need to store the existing sessionId and reuse it.

- target port missing, even if we have a default I believe it is generally a good idea to 
allow ports to be configured
- target transport missing (SSH, BEEP, SOAP)
- target:mixed or separate session
- I think using meaningful names are better then just using an arbitrary integer as index. 
I see this as one of the selling points for Netconf. I would propose the following that 
profileindex and filterindex should be strings, maybe the parameter should be profilename, 
filtername
- target and filter shall somehow be linked. When we want a callback you need to know 
which profile to use
- target: should the sessionId of existing sessions be included ?
- with this model ANDY you implicitly seem to accept that eventclass will be part of every 
event, correct ?

About filters:
Data should include eventclasses, xpath, subtree
Today we/Ericsson are using proprietary filters like
(eventclass1 && xpath) || (eventclass2 && xpath && xpath) || eventclass3
where xpath can be exchanged for a subtree filter. However this is impossible in both 
versions. Actually it would be enough to have one xpath/subtree filter for each eventclass.

Balazs

--------------------------------------

My personal view on modeling OPTIONAL reading only:
We need to model the following entities:
- Ongoing Notification Session (subscription in the draft)
We need this as we do not want to open a new session for each notification for each 
target. We need to store the existing sessionId and reuse it.
- Filter
- Target (callHomeSubscription in the draft)
- Profile (is it needed ?)

We need to link a target both to a filter and an ongoing session. I imagine the Netconf 
agent would work like this:
1) Event occurs
2) agent scans the list of targets
3) for each target it checks against the related filters
4) If they block the notification goto next target
5) Filters allows notification; check if it has an existing session,
		if yes goto 7
6) If no session open a new session to target
7) We have an existing session; send notification on session, goto next target

Targets would be created by normal configuration commands (maybe just before subscribing.
SessionId for a target will be set when creating a new call-home session or by the 
subscribe operation during the existing session

The above discussion misses mixed versus separate session transport as yet.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 May 2006 10:23:01 -0700

Balazs Lengyel wrote:
> We need this as we do not want to open a new session for each 
> notification for each target. We need to store the existing sessionId 
> and reuse it.

IMO, there isn't any session-based notification system
that makes sense.  We should not reinvent UDP
based notification architecture with some hack to
get around the overhead of sessions.

The notion of a session that exists even if the other
peer in the session does not exist -- is extremely broken.
Is this what you mean by "ongoing session"?

The subscription mechanism requires a manager to reenter
the filter data every time a new session is started.
This is somehow perceived as easier to use.  Supposedly
a <create-subscription> RPC is much less complex than
an <edit-config> RPC.  All the examples in the draft indicate
that the filter element is much more complicated than any of the
<edit-config> parameters, and the <filter> would be the same either way.

> 
> - target port missing, even if we have a default I believe it is 
> generally a good idea to allow ports to be configured
> - I think using meaningful names are better then just using an arbitrary 
> integer as index. I see this as one of the selling points for Netconf. I 
> would propose the following that profileindex and filterindex should be 
> strings, maybe the parameter should be profilename, filtername
> - target and filter shall somehow be linked. When we want a callback you 
> need to know which profile to use
> - with this model ANDY you implicitly seem to accept that eventclass 
> will be part of every event, correct ?

EventClass should be part of the notification header.
The <data> field in each notification should be identified
by a namespace, just like we do with the <config> element.

> where xpath can be exchanged for a subtree filter. However this is 
> impossible in both versions. Actually it would be enough to have one 
> xpath/subtree filter for each eventclass.

I'm not convinced that anything in this entire feature is economically
viable.  It seems to be a way to move complex code from 1 manager
to 1000s of agents.  I don't believe many vendors
will abandon their investment in syslog and use this instead.

> Balazs

Andy

> We need this as we do not want to open a new session for each 
> notification for each target. We need to store the existing sessionId 
> and reuse it.
> - Filter
> We need to link a target both to a filter and an ongoing session. I 
> imagine the Netconf agent would work like this:
> 1) Event occurs
> SessionId for a target will be set when creating a new call-home session 
> or by the subscribe operation during the existing session
> 
>> Nortel Ottawa, Ontario

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 18 May 2006 13:16:34 +0200

Hello Andy,
I might not really get your point.

MY point was: I do not want to go through the Netconf session set-up for each notification 
the node wants to send. This would mean session overhead, authentication overhead etc. 
This is why I say you need to hold on to and reuse the ongoing session. Even SNMP is 
moving towards session based security with ISMS as I understand.

As I understand, you on the other hand want to set up a new session and re-authenticate 
for each notification? Or did I misunderstand you?

> Is this what you mean by "ongoing session"?

NO. But if the other end does not exists (callHome) the node tries to set up a session to 
it. If the peer really doesn't exist the session setup fails the notification will not be 
sent. But if the peer exists just the session between the manager and the agent is missing 
the agent should be able to rebuild it.
> <edit-config> parameters, and the <filter> would be the same either way.

I see our solution (and my optional part) serves both callhome and subscription. The 
manager/agent will be free to choose the between the two methods. IMHO whether we reuse an 
ongoing session (as above) or not is independent from the method we used to set it up: 
subscription or callhome.

-------------------------------------------------------------------

Balazs Lengyel's personal view on modeling OPTIONAL reading only:
We need to model the following entities:
- Ongoing Notification Session
We need this as we do not want to open a new session for each notification for each 
target. We need to store the existing session id and reuse it.
- Filter
- Target (callHomeSubscription in the draft)
- Profile (is it needed ?)

6) If no session; open a new session to target

Targets would be created by normal configuration commands e.g. <edit-config>. These can be 
issued once and data will be used for a long time or you could use <edit-config> ; 
<subscribe> ; <unsubscribe> ; <edit-config : operation:delete> for short lived subscriptions.

---------------------------------------------------------------------

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 May 2006 04:51:23 -0700

Balazs Lengyel wrote:
> MY point was: I do not want to go through the Netconf session set-up for 
> each notification the node wants to send. This would mean session 
> overhead, authentication overhead etc. This is why I say you need to 
> hold on to and reuse the ongoing session. Even SNMP is moving towards 
> session based security with ISMS as I understand.
> 
> As I understand, you on the other hand want to set up a new session and 
> re-authenticate for each notification? Or did I misunderstand you?

I am not convinced that netconf session-based notifications will
be used instead of syslog UDP-based notifications in operational
networks.   I'm not sure the overhead of auth/no-priv is more
than the overhead of session maintenance, but I am sure that
the manager-starts-notifications-via-subscription does not
scale well to large numbers of devices -- the initial notification
gap will be unacceptable in customer networks.

> NO. But if the other end does not exists (callHome) the node tries to 
> set up a session to it. If the peer really doesn't exist the session 
> setup fails the notification will not be sent. But if the peer exists 
> just the session between the manager and the agent is missing the agent 
> should be able to rebuild it.

This is significantly more complex than the traditional
NV-configured fire-and-forget UDP-based notification systems.
If any part of the "use-UDP-instead-of-TCP when the network
is unstable" doctrine is still true, then it is for fault
notifications.

> I see our solution (and my optional part) serves both callhome and 
> subscription. The manager/agent will be free to choose the between the 
> two methods. IMHO whether we reuse an ongoing session (as above) or not 
> is independent from the method we used to set it up: subscription or 
> callhome.
> 
> notification for each target. We need to store the existing session id 
> and reuse it.
> - Filter
> Targets would be created by normal configuration commands e.g. 
> <edit-config>. These can be issued once and data will be used for a long 
> time or you could use <edit-config> ; <subscribe> ; <unsubscribe> ; 
> <edit-config : operation:delete> for short lived subscriptions.
> 

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 18 May 2006 13:59:58 +0200

>>>> notification for each target. We need to store the existing 
>>>> sessionId and reuse it.
>>>
>>>
>> just the session between the manager and the agent is missing the 
>> agent should be able to rebuild it.
> 
> 

Currently we have 3 transport SSH, BEEP and SOAP so UDP would be something new. Do you 
suggest we should go for UDP or what is your proposal ?

For mixed notification sessions we anyway need to maintain the session.

JURGEN! Could you tell us how ISMS is solving the session based security?
As I understand they also decided to have proper security you need to maintain sessions.

Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 May 2006 14:34:48 +0200

> As I understand they also decided to have proper security you need to 

ISMS is all about using existing security solutions for SNMP. It turns
out that the most widely deployed security solutions are somehow
session based and the most widely deployed onces are running over
TCP. Note that session based security is not the same as running over
TCP.

The statement "to have proper security you need to maintain sessions"
per se might not be correct. But to have security, you need to
maintain some state between the communicating endpoints and setting
this up involves some work, even in the case of SNMPv3/USM.

We will soon post some measurement data to the ISMS list which shows
the cost of the various transport and security options for SNMP. We
did the measurements on a perfect network but also under conditions of
packet loss. All I can say is that those who use a stock net-snmp
implementation really should not worry about a TCP transport in case
the network is in trouble. With other SNMP stacks you might be better
off - we did not measure them.

/js

PS: Also SNMPv3/USM has some overhead when you send the first
    notification and you have to synchronize clocks. You do not establish
    a session key which saves on round trip times, but also reduces
    the level of security you get if you are paranoid (or you have to
    do more frequent key changes). The point is that you have to look
    at the whole system and that it is misleading to separate out
    pieces of the picture and to look at it in isolation.

PPS: Even if you consider signed syslog messages over plain UDP, it might
     be instructive to figure out what the overall performance will be
     end-to-end including generation and verification of the
     signatures.

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

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 18 May 2006 14:31:19 +0200

Hello,

Andy Bierman wrote:
>>
>> Currently we have 3 transport SSH, BEEP and SOAP so UDP would be 
>> something new. Do you suggest we should go for UDP or what is your 
>> proposal ?
> 
> 
> No -- you are missing my point.
> I am not convinced that netconf is an appropriate protocol
> to replace the functionality of syslog.  I would just
> use syslog if I wanted a notification system that scales.
> If I wanted a nice-to-have feature to make NMS netconf dev-work
> a little easier, I would consider using netconf notifications.
> 
> 
OK I would say let's kick out syslog (I don't need it). For other event classes would you 
like to have long life sessions with session maintenance and reuse or session set up for 
every notification or ???
I go with Sharon who opted for reuse in the draft.

Balazs

PS. For me the non-syslog part is really important not just nice-to-have.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 May 2006 05:07:54 -0700

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 22 May 2006 12:35:09 -0400

Hi,

Juergen answered this question somewhat. I agree with all his
comments. Sessions are not required for security (as USM
demonstrates), but the use of sessions can help to amortize the
overhead of transport connection and security costs over multiple
messages.

Let me discuss the ISMS solution that is in the ***current*** SSHSM
document in more detail. This is a work in progress, so things may
change. SSHSM is the SSH Security Model for SNMP.

SSMSM establishes one or more SSH sessions between an SNMP manager and
agent. Each session is based on transportType, transportAddress,
securityName (the principal or user), the securityModel (in this case
the SSH security model), and a securityLevel. 

While SNMPv3 supports noAuthNoPriv, authPriv, and authNoPriv, SSHSM
uses only authPriv. If an application asks for a different
securitylevel, the message will still be sent over an SSH transport
connection with authentication and encryption. I expect further debate
over this approach. We decided that the details of the security
mechanisms (the authentication protocol used, the SSH protocol options
selected, etc.) should be opaque to SSHSM. Unless the SNMP engine has
more insight into and control over the SSH transport connection
parameters, and the security model violates the data hiding rules of
the RFC3411 architecture, we don't have a way to deal with multiple
securitylevels easily. Of course, an operator may choose to deploy
their SSH transport connections differently, but SSHSM will not know,
just as netconf won't know if a BEEP or SSH session is not deployed as
called for.

Sessions are reusable. It does not matter whether the session was
initially created by a manager as a request/response channel, or
created by an agent as a notifications channel. What matters is that
the transport and securityName/Model/Level match.

SSHSM sessions may be closed by either side at any time for resource
management (or other reasons). When a message is sent, the security
model in the sender checks to see if a suitable session exists. If
not, it creates an appropriate session (if it cannot, it discards the
message and sends back an error to the other parts of the engine). 

Multiple SNMP messages, of the request/response variety or
notifications, may be sent over an existing session. SNMP messages are
BER encoded, with length tags, etc., and do not have the same issues
of document validation that a XML-based document has, and that
multiple XML messages in a stream has. So the never-ending RPC is not
an issue that has arisen in ISMS.

Just like in netconf, any callback mechanism has been underspecified. 

In ISMS, Balsz's discussion of the loop for notifications is slightly
different because we use a modular approach:
For each event {
	determine the targets, 
	apply filters, 
	send message request to message processing
}
For each message request {
	build each notification,
	send message to transport mapping
}
For each message {
	Check whether suitable session exists
	If not, create session
	send message
}

Hope this helps,

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

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen
Schoenwaelder
> Sent: Thursday, May 18, 2006 8:35 AM
> To: Balazs Lengyel
> Cc: Andy Bierman; Netconf (E-mail)
> Subject: Re: The datamodel in Notification Draft
> 
> 
> > As I understand they also decided to have proper security 
> you need to 
> > maintain sessions.
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 May 2006 10:16:46 -0700

> change. SSHSM is the SSH Security Model for SNMP.

Thank you for this summary.
It does help a lot.

One thing that seems very clear is that the IESG and many
WG participants seem intent on ignoring the NM protocol
silo proliferation problem, and in fact seem intent
on making it worse.

Now I see why notifications over netconf makes sense.
Compared to the option of using vastly different protocols,
data, and security models for every little NM task,
and if you are going down the XML path anyway -- it makes sense.

Andy