Re: Named Profiles for notification configuration (unofficial issue #16)

[Andy Bierman <ietf@andybierman.com>]

Sharon Chisholm wrote:
> hi
>
> <Andy>
>
> We don't have opaque string data models.
> We have vendors defining explicit XML data models
> in their own namespace.  There is a difference.
> </Andy>
>
> Ah. So, I guess we forgot to explicitly specify that it is necessary to
> specify some data model for the named filters. That is why it is the
> same issue. If they remain in the update, we shall add this
> clarification.

I'm not sure there is WG to have named profiles at all.
We have a mechanism -- data models configured through
standard NETCONF operations.  We don't need more, let alone
mixing them together.   How about if we see some
deployed implementations of this feature (for any profile-named
config data) in some NETCONF products before we standardize it?


> <Andy>
> I have provided an extensibility mechanism -- IANA registration.
> Each event-type is itself a data model with implementation
> requirements in the agent.  They should be registered with IANA
> and be independent of the document this WG is chartered to create.
> </Andy>
>
> I'm confused. So, the proposal in the internet draft is that
> notifications are defined in the data model, but are you proposing a
> design alternative or suggesting that working group consensus has
> already been reached and this is going to be done in another way?


All event types and any mention of any specific event content
outside the <notification> element header contents should be
removed from the document and made independent of protocol.

People (outside the WG) would then be free to register as many
notification data models with IANA as they want.  Just like
the base protocol, there should be content-independent notifications.

The only exception is the configuration-change notification.
That should be defined in this document and be mandatory-to-implement
if you support the :notification capability.


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