Subject: RE: [NGO] max-access clause

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 6 Dec 2006 19:38:51 +0200

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Wednesday, December 06, 2006 7:26 PM
> To: Phil Shafer
> Cc: NETCONF Goes On
> Subject: Re: [NGO] max-access clause
> 
> >>> - for me create and delete are not really important. I 
> need only one 
> >>> write right that includes create and delete. While there might be 
> >>> cases where the distinction between delete and write might be 
> >>> important I believe these are rare so I feel we add 
> complexity for little gain.
> > 
> > We see cases where this is useful, such as a 
> logical/virtual router, 
> > where a user is allowed to modify them, but not to make a new one.
> 
> 
> Also something as basic as the interfaces table.
> You may be able to create/delete optional features that a 
> rooted in an interface instance, but not create/delete 
> interfaces.  And of course, you may be able to create/delete 
> the items in a container, but not the container itself (e.g., 
> interfaces/interface).
> 

Yes, interface table entries are one of the more illustrious examples of
configuration objects in MIBs that would allow only read but not create
operations. This is because initially interfaces were designed to be
only 'physical' things. However, the model proved to have its own
limitations, when people extended the concept of an interface to virtual
things (like VLANs) and then they had to hack around the model to allow
for 'creation' of 'virtual' interfaces. 

Dan

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 13 Dec 2006 14:26:56 +0200

AGENT-CAPABILITIES would have extended in SNMP the understanding from
the manager side about the agent implementation capabilities. There were
some tentatives to implement this for an algorithmic interaction between
manager and managed entities, but they did not go too far AFAIK. 

Dan

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Wednesday, December 13, 2006 1:38 PM
> To: Peder Chr. Norgaard
> Cc: NETCONF Goes On
> On Wed, Dec 13, 2006 at 10:47:51AM +0100, Peder Chr. Norgaard wrote:
>  
> > To make it possible to implement such a mechanism that will work 
> > against many different vendors' NETCONF servers, it is necessary to 
> > standardize the structure of the elements in the interface 
> elements, 
> > their names and types etc and the placement in the entire server 
> > hierarchy; but it is not necessary to specify anything 
> about accessability.
> > 
> > MAX-ACCESS clause or not, SNMP does not offer you anything 
> like this.
> 
> The SNMP way of doing this is to try a set operation and to 
> be prepared to understand the return code. Ugly, but possible.
> 
> Sure, it would be nice if the agent/server can indicate 
> without a write attempt what is writable.  NETCONF perhaps 
> allows to do this without a real write if you use the 
> #validate noption.
> 
> But yes, having a mechanism to do this properly would help.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		 {International|Jacobs} 
> University Bremen
> <http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 
> 28725 Bremen, Germany
>