Re: architecture and security

[Phil Shafer <phil@juniper.net>]

Balazs Lengyel writes:
>1) A router with multiple virtual routers.
>2) I have a big box: where user A is responsible for ...

One of the core concepts behind netconf was leveraging the existing
CLI concepts, infrastructure and implemenation to avoid being a
third management model (after the CLI and SNMP).  By avoiding this,
we hope to make netconf easier to implement, more powerful to use,
and more familiar to operators.

This was the motivation behind mirroring the existing configuration
models implemented by vendors (running, distinct-startup, candidate)
rather than rolling our own.  (It also helped us avoid the tendency
to invent new "must-have" features that no one ever heard of ;^)

So when I think of issues like classes of users and virtual routers,
the first question that comes to mind is how do existing routers
handle this?  Virtual routers are typically keyed off either incoming
interface or user login name.  The router knows which VR you are
accessing before you start entering commands.  This same solution
can be leveraged for netconf.  In the same way that a CLI user should
only see local log files or messages for their own VR, so a netconf
login should only have access to the notifications for the VR into
which the netconf session is attached.

Similar for classes of users.  If the CLI filters syslog files/messages
by user class, this same mechanism should be leveraged for netconf.  If
you couldn't see if as a user, you should see if as a netconf session.

So netconf should definitely not prevent you from doing the things
you want.  It should help you expose your device's abilities while
leveraging the existing infrastructure.

Thanks,
 Phil

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