Re: max-access: access control model discussion

[Andy Bierman <ietf@andybierman.com>]

Balazs Lengyel wrote:
> I agree that a detailed mapping of max-access to operations is needed. 
> The recent discussion about the operation parameter in edit-config also 
> shows us that much of the complexity lies in understanding different 
> access clauses on nested elements.

This problem has been studied before in the SMIng WG.
Nested MAX-ACCESS is not purely hierarchical.

This is one area where containers really help.
Consider nested containers in dynamic 'rows'.
The NMS creates the parent row, and the agent
creates a read-only container in that row.
After this operation succeeds, the NMS has read-create
access to create entries in that nested container.


> I would also say that mapping from the SMI-2 max-access clause is needed 
> as we will be borrowing from the modeling work of SNMP.
>
> I see the following main points about the two versions:
> Sharon's max-access:
> - It is assumed that the read,write,create,delete,execute rights are 
> orthogonal in a sense so the netconf server needs to check only one of 
> them for each operation not the complete set.

This is not true.
Consider the 'replace' operation carefully.
It can be any or all of "create, write, delete",
in the same PDU.


> Andy's max-access:
> _ It is assumed that the set of access possibilities is completely 
> hierarchical so it is easier to use a smaller list then the 25 possible 
> permutations in Sharon's list.
>
> I believe both solutions could do the job.
>
> Balazs


Andy


> Andy Bierman wrote:
> > Balazs Lengyel wrote:
> > > Let's assume we have the following data model:
> > >
> > > <if>
> > >   <name>eth0</name>
> > >   <opstate>up</opstate>
> > > </if>
> > >
> > > - if can be created/deleted max-access: all
> > > - name must be created together with if max-access: all
> > > - opstate is a read only variable that might be created automatically 
> > > by the managed system max-access: read-only
> > >
> > > If I want to create <if> can I create the read-only <opstate> object 
> > > or do I have to rely  on the managed system to automaticaly create it ?
> > >
> > > If I want to remove the <if> can I remove the read-only <opstate>? (I 
> > > do not want to allow  removing <opstate> without removing <if>.)
> > >
> > > What are the correct max-access setting ? (The question is the same 
> > > both for Andy's and Sharon's solution.)
> >
> > I will rewrite my original email to use existing MAX-ACCESS from SMIv2
> > instead of my extended MAX-ACCESS (based on well-known sub-states in 
> > MIBs),
> > In your example, read-create covers the case where read-write and 
> > read-only
> > data objects are instantiated by the agent, concurrently with the
> > objects instantiated by the NMS.
> >
> > IMO, the actual netconf operations need to be explicitly supported
> > (notify, read, merge, replace, create, delete) with detailed text
> > explaining the mapping.
> >
> > > Balazs
> >
> > Andy


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