Re: event classes (sec. 3.5)

[Andy Bierman <ietf@andybierman.com>]

Balazs Lengyel wrote:
> ....
> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
> "notify about delayed results of long running RPCs [BL]". I am not 
> totally happy with the name of the event class, but I like the idea 
> behind it. If the draft misses this Ericsson will have to do some dirty 
> workaround.

I think this delayed <rpc-reply> should have its own event class
and fully defined syntax (because it's already done in the prot-spec).

This could turn out to be an important feature.
IMO, a specialized RPC to provide 'ping' type of exec
features is a good use of session-specific config.
and netconf-specific session-based notifications.

E.g.:

 <rpc message-id="101">
   <ping>
     <source>
     <target>
     <frequency>60</frequency>
     <rest-of-ping-params ...>
   </ping>
  </rpc>

  <rpc-reply  message-id="101">
    <ok/>
  </rpc-reply>

  ... 60 seconds later

  <notification>
    <event-class>rpc-reply</event-class>
    <sequence-id>42</sequence-id>
    <data>
      <rpc-reply message-id="101">
        ...  ping result # 1
      </rpc-reply>
    </data>
  </notification>

 ... 60 seconds later

  <notification>
    <event-class>rpc-reply</event-class>
    <sequence-id>43</sequence-id>
    <data>
      <rpc-reply message-id="101">
        ...  ping result # 2
      </rpc-reply>
    </data>
  </notification>



> - METRICS is certainly out of scope although I don't see any real 
> problem with it. We must note however that Netconf events are probably 
> unsuitable for HIGH volume performance data transfer.


The problem with it is that netconf is chartered
for a completely different purpose.  The ipfix protocol
is designed much more appropriately for streaming metrics
data from source to sink.  They made very different design
choices than netconf because they are solving a different
problem.  Streaming metrics data encoded in XML over a session
over TCP seems rather inefficient to me.


> - HEART BEAT - OK
> - INFORMATION event is really an extension mechanism. OK.

why not call it 'other' then?

> - SYSLOG: We spoke a lot about transferring syslog via events, but 
> please could someone say who really has a requirement to do this! If we 
> really have the requirement Jurgen please add it to your page!

IMO syslog is not an event classification at all
and does not belong in the set, unless it indicates
the exact content of the payload (like my rpc-reply event class.)
Is is syslog/RAW or syslog/COOKED or something else?
If I need to depend on the namespace URIs in the data anyway,
then what value is this classification?

I agree with you that it doesn't make a lot of sense
to tunnel syslog over netconf, but from a dev-cost POV,
it would be easy to implement syslog/RAW over netconf.
It would provide no additional value whatsoever from a modeling
perspective, but maybe it does from a transport and
security perspective.



> - SECURITY - mentioned in the initial list, but not described later. As 
> I see it security related notifications can be carried as fault or state 
> events, so I don't see a need for this event class.

agreed

> Balazs


Andy



> Andy Bierman wrote:
> > Hi,
> >
> > This section is very under-specified.
> >
> > IMO, it is impossible for independent developers
> > to select classifications in an interoperable manner.
> >
> > It is really not at all clear why we need audit, data,
> > maintenance, metrics, information, and syslog classes at all.
> >
> > Most of these are totally redundant.
> >
> > Metrics is out of scope.
> >
> > Syslog is not a proper member of this classification set.
> > In XML, we use namespaces to identify content format,
> > such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
> > The notification <data> section will be just like
> > the <config> or <data> elements already defined in
> > the protocol.
> >
> > 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/>
>
>
> --
> 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/>