[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OPS-AREA] Issue 1: should we have a security boilerplateformanagement protocols and data models?
Hi -
> From: "David Harrington" <ietfdbh at comcast.net>
> To: "'Randy Presuhn'" <randy_presuhn at mindspring.com>; "'ops-area (IETF)'" <ops-area at ietf.org>
> Sent: Wednesday, February 04, 2009 11:54 AM
> Subject: RE: [OPS-AREA] Issue 1: should we have a security boilerplateformanagement protocols and data models?
...
> I am not sure which goal you find admirable, but I assume you mean
> suggesting that protocols should support access control, and the info
> model access should differentiate between modify sensitivity and
> expose sensitivity.
However, it's not even clear whether netconf access control will
even be formulated in those terms (it might be "per RPC") nor
do we even know whether the granularity of "information element"
would be congruent with what netconf might do. (I would hope so,
but then it might start to look surprisingly like VACM.)
> I tried to write the text to say that the protocol should support
> control of access to the information. I tried to avoid saying anything
> about using a particular conceptualization/model of access control.
> "support" could be for a proprietary access control model, or a
> standardized one - but some type of access control should be
> supported.
We're in agreement. The difficulty is that access control models
aren't *necessarily* formulated in terms of information elements,
even though doing so is in my opinion a very sensible thing.
> I think that whether the access control is standardized or
> proprietary, it will be reasonable to expect that the access control
> will differentiate between operations that expose and those that
> modify (if there is a modify capability).
Maybe. If it looks like some CLI access control models, it will
be organized around a set of "verbs" rather than information objects.
I certainly don't recommend such an approach, but until netconf
nails this down, I'd be wary of trying to predict how it will end up.
Randy