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

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 27 Mar 2006 14:05:37 -0500

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.

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

Sharon

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Mar 2006 11:20:14 -0800

> same issue. If they remain in the update, we shall add this

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?

> 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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Mar 2006 13:35:48 -0800

> in their own namespace.  There is a difference.

To put this another way:

Among the very first standard objects for netconf
configuration should not be a standard pointer to
opaque proprietary extensions.  This somehow misses
the point of the whole standards thing.

Besides, this is XML, not SMI.
You don't need these objects anymore.
Just extend the RPC parameter set in your own namespace
any way you want.

 >...

Andy