[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NETCONF Notifications Issues List

Sharon Chisholm wrote:

Hi
Some comments as technical contributor inline: 
2) RPC Methods
  - create-subscription
    - why isn't there a stop-time in the replay capability?  [BL]
    - why stop notifications after replay (e.g. no tail -f mode) [BL]


The first issue was in the discussion list before the -04 update. I
tried to generate some discussion on the topic, but wasn't successful so
I kept it open. I'll try again. In the use cases I've seen, an implicit
stop time of when the command was sent works, so adding stop time
doesn't seem necessary. Thoughts?

For the second one, in the use cases I've seen, people don't want to
have to wait until the replay has completed before getting current
alarms. They therefore do not want replay and real-time on the same
subscription.


IMO, in both cases these are parameters that the NMS might want.
Whatever the parameter set, there should only be one version of it.
(I.e., no capabilities per parameter like with edit-config, that
was a mistake).

I don't really care what the parameters are, as much as there is
one standard way to do notification replay.  The way an agent
avoids this feature is by storing zero seconds worth of replay data,
so the rpc-reply "I have no replay data that meets these parameters"
is always returned.







6) Data Models
  - Why do we need to query the notification subscriptions? [BL]
  http://ops.ietf.org/lists/netconf/netconf.2006/msg01226.html


If a working group in any other IETF area developed a protocol with no
way to manage it, we would think they hadn't design a proper solution.
Somehow in Netconf, we seem to be holding ourselves to a lower standard.
I think we need monitoring schema to report on the state of the system.



I tend to agree with you here, but this data isn't that useful.
Maybe it will be useful during deployment debugging, who knows.
Perhaps a comprehensive data model for monitoring all aspects
of the active sessions is more appropriate.  (What does the WG think?)





Sharon


Andy

--
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/>