[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The datamodel in Notification Draft
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.
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/>
--
Balazs Lengyel Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320 Fax: +36 1 4377792
Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com
--
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/>