Re: [OPS-AREA] Issue 1: should we have a securityboilerplateformanagement protocols and data models?

["David Harrington" <ietfdbh at comcast.net>]

Hi,

I think you may be reading more into "information element" than I am.
In a management information system that uses verbs or RPCs, I consider
those as information elements as well. Some verbs modify, some expose.
Some RPCs modify, some expose. In a system that uses hierarchies of
things, like MIBs and XML and UNIX filesystems, both leafs and
subtrees can be information elements that can expose or possibly be
modifed.

I do not think the whole IETF strategy for managing networks should be
totally dependent on what Netconf and netmod decide to do about access
control, anyway. There are quite a few different protocols in the IETF
that address network management.

dbh

> -----Original Message-----
> From: ops-area-bounces at ietf.org 
> [mailto:ops-area-bounces at ietf.org] On Behalf Of Randy Presuhn
> Sent: Wednesday, February 04, 2009 8:25 PM
> To: 'ops-area (IETF)'
> Subject: Re: [OPS-AREA] Issue 1: should we have a 
> securityboilerplateformanagement 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
> 
> _______________________________________________
> OPS-AREA mailing list
> OPS-AREA at ietf.org
> https://www.ietf.org/mailman/listinfo/ops-area
>