Re: NETCONF Minutes for IETF 67 [draft 1]

[Andy Bierman <ietf@andybierman.com>]

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
> > 2.1) StreamList Design
> >
> > The group discussed the StreamsList construct introduced
> > in the -04 draft.  This is a list of 1 to N stream names that
> > should be combined by the agent to produce the notification
> > output for a particular session.
>
> [...]
>
> > Cons:
> >  - Streams can have different data formats, and some combinations
> >     may not make sense, or the agent may not be capable of combining
> >     them (i.e., the reason streams exist in the first place.)
> >  - There is no simple way for the manager to know which combinations
> >    are permitted
>
> I don't understand this argument.  Maybe I don't understand how the
> streams are supposed to work at all...  I thought that the idea is
> that each <notification> is a complete XML instance document.  For
> example
>
>   <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>     <my-event xmlns="http://example.com/event/1.0";>
>        <!-- any valid XML here -->
>     </my-event>
>   </notification>
>
> or
>
>   <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>     <syslog xmlns="http://ietf.org/netconf/syslog/1.0"/>
>        Jun 11 21:34:52  dent chassisd[2971]:
>         CHASSISD_IFDEV_DETACH_ALL_PSEUDO:
>         ifdev_detach(pseudo devices: all)
>     </syslog>
>   </notification>
>
> or
>
>   <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>     <snmp xmlns="http://example.com/snmp"/>
>        <!-- clever representation of an snmp trap here -->
>     </snmp>
>   </notification>
>
> etc.
>
> Why would it be difficult for the agent or manager to mix these on a
> single subscription?


The streams may be different on the agent for various reasons,
not just different output encoding.  Implementation constraints
such as distributed sub-agents may be a factor.  Different
capabilities (such as replay) that may not be supported on all
streams, or implemented in a uniform way, may be a factor.
Streams may have 'choice' parameters (A or B) and combining
streams (1 with A, 1 with B) may produce undefined results.

The WG agreed that configuration of streams is out of scope
right now.  Combining N arbitrary streams into 1 subscription
is a form of stream configuration, even if it isn't explained
that way in the draft.


> >  - The same system event can be conveyed in different ways, across
> >    multiple streams.  Manager-selected combinations of streams
> >    would either create duplicate notifications or require complex
> >    duplicate suppression
>
> So suppose the manager want to subscribe to the snmp and syslog
> streams, and these contain some duplicate events.  If you can't
> subscribe to more than one stream, you'd open two sessions.  You will
> still get the duplicate events.  So I don't understand why this is an
> argument agains streamslist.

This needs to be configured as 1 stream in a proprietary manner,
until a standard exists for stream configuration.

> This being said, I don't have a strong opinion on this issue.  I just
> don't understand the arguments.
>
>
>
> /martin


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