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

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 27 Mar 2006 13:28:47 -0500

hi

<Andy>
Not sure how access control applies to opaque parameters? Yikes!
</Andy>

Compared to opaque data models? No, I don't see why this is more of an
issue. Not saying this is a good thing, but it is the way it is. The
implementer would apply their own access control to the no-longer-opaque
parameters and determine if the user should have access.

<Andy>
There aren't going to be any blatant proprietary hooks in NETCONF. 
</Andy>
That's quite the statement. My crystal ball doesn't work that well ...

If there is working group consensus that we don't need extensibility in
the filtering, then I'm (as an individual) fine with it being removed
(as an editor).

In general though, as far as trying to support implementations, there
will be two options

1) Explicitly preclude proprietary extensions
2) Provide a standard way (such as URLs) to enable 'predictable'
proprietary extensions.

Note that the first case really comes in two parts. The first is where
to ensure interoperability we want to limit extensions to limit the
number of ways to say the same thing. The second is that we ensure we
have defined things rich enough to cover everything that will reasonably
come up.

This more relates to other topics of extensibility that came up (such as
event classes) than this issue, but this discussion reminded me of the
extensibility discussion ...

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 10:46:09 -0800

> parameters and determine if the user should have access.

We don't have opaque string data models.
We have vendors defining explicit XML data models
in their own namespace.  There is a difference.

> That's quite the statement. My crystal ball doesn't work that well ...

Well, I'm the co-Chair, and mine does.
Fully-specified, interoperable mechanisms are required for
inclusion in any standard NETCONF namespace.  What you do outside
any such namespaces is not my concern.

> 2) Provide a standard way (such as URLs) to enable 'predictable'

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.

> extensibility discussion ...

Andy