[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed Update to Netconf Charter
On Tue, Jul 05, 2005 at 01:53:54PM -0700, David T. Perkins wrote:
> Two specific items...
> 1) I don't see the need for contexts in NETCONF data modeling,
> since contexts are simply "a mechanism to add extra
> indexing when the MIB designer failed to predict the future
> evolution of technology" (or bandaid for poor MIB design).
> With XML, I don't really believe this limitation is
> present, and, thus, a "context" will not be needed.
Using XML does not prevent MIB designers from failing to "predict
the future evolution of technology". Once you cast an XML schema
into stone, you can screw up as well. The hope, however, is that
we do not need to introduce an extra mechanism like contexts to
fix such problems.
> In the work that I have done explaining VACM, the
> concept that what security level is used can affect
> what can be accessed is always a very big surprise.
A story from real life here. I was trying to setup a subversion
server (subversion is basically a better cvs version control
system) using apache and the webdav/deltav modules. I wanted to
make the configuration such that users who have authenticated
using a cleartext channel will be treated differently from
users who have authenticated over an encrypted channel. So far,
I have not managed to do this in a nice way because the
authorization decision only knows whether someone has been
authenticated but not how this was carried out. I then realized
that SNMP actually got this right and I am still surprised that
I have not found someone to explain me how this can be done
nicely in the above mentioned scenario.
> Thus, I would characterize VACM as completely missing
> the target. It is too complex for typical usage,
> and not rich enough for realworld usage.
This may be true. The main problem with VACM is that the burden of
defining suitable security profiles is left to the operators who
really have other things to worry about. So what is left are in
most cases the "default" read-only and read-write profiles.
If we do netconf access control, we should investigate how command
line interfaces typically deal with access control. We should not
constrain ourself by the VACM design since the number of non-default
VACM tables I have seen on production systems is close to zero. If
someone has different experiences with deployed VACM configurations,
please speak up.
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
--
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/>