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

["Sharon Chisholm" <schishol@nortel.com>]

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