[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The datamodel in Notification Draft
Balazs Lengyel wrote:
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.
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
- 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 ?
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.
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.
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
--------------------------------------
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.
Sharon Chisholm wrote:
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 netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>