Subject: RE: [NGO] max-access clause

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 8 Dec 2006 13:42:55 +0100

I understand very well the pragmatic arguments in this discussion between
Peder and Andy. My question then is:

   It seems we DO NOT want to STANDARDIZE on the ACCESS aspect of
   config/information (or any MIB object for that matter).

   So why should we then worry at all, if we come to a standards setting
   organisation if we do not want to standardize?

I also doubt that in pragmatic sense the runtime "compliance" info works.
Andy already stated he did a MIB for it. We also have AGENT-CAPABILITIES
and the sysORTable that supposedly allows agents to report (at runtime)
what exactly they support... but few (if any) implementations really
support it, let alone deployments.

Bert

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]]
> Sent: Thursday, December 07, 2006 15:39
> To: Peder Chr. Norgaard
> Cc: NETCONF Goes On
> Subject: Re: [NGO] max-access clause
> 
> 
> Peder Chr. Norgaard wrote:
> > On Wed, 6 Dec 2006, Juergen Schoenwaelder wrote:
> > 
> >> On Tue, Dec 05, 2006 at 09:54:58AM -0800, Andy Bierman wrote:
> >>
> >>> It has been suggested that we can agree on the enumerations
> >>> for the max-access clause, without actually defining an ACM first.
> >>
> >> In the SNMP world, SMI's max-access has nothing to do with 
> an access
> >> control (assuming this is what you mean with ACM). RFC 2578 says:
> >>
> >>   The MAX-ACCESS clause, which must be present, defines whether it
> >>   makes "protocol sense" to read, write and/or create an 
> instance of
> >>   the object, or to include its value in a notification.  
> This is the
> >>   maximal level of access for the object.  (This maximal level of
> >>   access is independent of any administrative 
> authorization policy.)
> >>
> >> I believe SMIv2 got this right. But perhaps NETCONF wants something
> >> else...
> >>
> > 
> > I would like to add completely different opinion to this dicussion.
> > 
> 
> These are very good comments.
> You convinced me that we should not simply follow SMIv2
> to be consistent with SNMP.
> 
> Do you think we should:
>    1) have a different (better) max-access clause than SMIv2
>    2) not have a max-access clause in data models at all
>    3) replace (or enhance) max-access with run-time conformance
>       info as it relates to that particular agent implementation
> 
> Note that I proposed a MIB that did (3) about 5 years in
> the EOS WG.  Vendors thought it was "too revealing" to
> clearly indicate at runtime which objects they fully or only
> partially supported.  They much preferred to let customers
> think all their products implement consistent NM interfaces.
> The very existence of a MIB to indicate otherwise was a non-starter.
> 
> 
> Andy
> 
> 
> > It seems from the discussion so far that it will be very 
> hard to agree 
> > upon a satisfying mechanism equivalent to SMIv2 MAX-ACCESS.  And it 
> > makes me think that maybe we should not do it at all.
> > 
> > There are two reasons for this.
> > 
> > First, the SMIv2 MAX-ACCESS is not all that smart in 
> real-life.  The 
> > number of times I've had to define a parallel private MIB object to 
> > allow configuration of a parameter that the standard MIB 
> has decided to 
> > be read-only is only beaten by the number of times I've had 
> to write a 
> > note in AGENT-CAPABILITY stating that a createable or 
> writeable object 
> > is read-only in this specific agent.  Not mention the few, but 
> > significant number of times the writeability of an object 
> has turned out 
> > to depend on the value of other objects - say, you can 
> configure MTU on 
> > a PPP interface but not on an Ethernet interface.  (Yes, I 
> do know that 
> > MTU is configurable on some kinds of Ethernet interfaces - 
> it is just an 
> > example.)
> > 
> > My total experience is that the existence of the MAX-ACCESS 
> clause in 
> > standard MIBs has helped neither me, as an implementor of 
> SNMP agents, 
> > nor the implementor of management applications; it has 
> actually made the 
> > life of both parties more complex.
> > 
> > Second, the (IMHO) most significant new concept in NETCONF is the 
> > <get>/<get-config> dichotomy.  It allows the server to tell 
> the client 
> > exactly which elements the server views as configurable.  
> It allows the 
> > server to respond to a <get> with an MTU element for both PPP and 
> > Ethernet interfaces, but drop the MTU element from the 
> Ethernet element 
> > when responding to a <get-config>, thereby hinting that MTU can be 
> > changed with, say, <edit-config> for PPP but not for 
> Ethernet.  And that 
> > is how it should be - the server is, after all, the only 
> entity that 
> > knows what is writeable and what is not.
> > 
> > I would urge the group to consider not copying the 
> MAX-ACCESS concept 
> > from SMIv2 into whatever data model solution is created for 
> NETCONF.  
> > The concept was not all that successfull in SMIv2, and the 
> need for it 
> > is considerably less in NETCONF.
> > 
> > Thank you for reading so far.
> > 
> > best regards
> > -- 
> > Peder Chr. Nørgaard            Senior System Developer, M. Sc.
> > Ericsson Denmark A/S, Telebit Division
> > Skanderborgvej 232             tel: +45 30 91 84 31
> > DK-8260 Viby J, Denmark         fax: +45 89 38 51 01
> >         e-mail: [email-masked]
> > (old e-mail 2000-2003: [email-masked])
> >          (old e-mail 1992-2000: [email-masked])
> > ----------------------------------------------------------------
> > OBS: The opinions in this mail are personal and should not be taken
> > for opinions of Ericsson.
> > ----------------------------------------------------------------
> > This communication is confidential and intended solely for the
> > addressee(s). Any unauthorized review, use, disclosure or 
> distribution
> > is prohibited. If you believe this message has been sent to you in
> > error, please notify the sender by replying to this transmission and
> > delete the message without disclosing it. Thank you.
> > 
> > E-mail including attachments is susceptible to data corruption,
> > interruption, unauthorized amendment, tampering and viruses, and we
> > only send and receive e-mails on the basis that we are not 
> liable for
> > any such corruption, interception, amendment, tampering or 
> viruses or
> > any consequences thereof.
> > 
> > 
> > 
> --------------------------------------------------------------
> ----------
> > 
> > _______________________________________________
> > NGO mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ngo
> 
> 
> _______________________________________________
> NGO mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ngo
> 

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

---

From: "Peder Chr. Norgaard" <[email-masked]>
Date: Wed, 13 Dec 2006 11:09:43 +0100 (CET)

>   organisation if we do not want to standardize?

There are lots of things that need to be standardized and should be. 
My point is that my experience shows that specifically the ACCESS aspect 
is hard for standard organizations to get right and, in the NETCONF 
context, does not add information valuable to any party.  See the example 
in my response to Andy's mail.

> support it, let alone deployments.

I agree with you on that.  I have had the dubious pleasure of maintaining 
an AGENT-CAPABILITIES for a major SNMP agent implementation;  that was a 
nightmare, and I don't think our customers ever used it for anything.

But, then, runtime compliance is not what I am advocating.

best regards
addressee(s). Any unauthorized review, use, disclosure or distribution

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we
only send and receive e-mails on the basis that we are not liable for
any such corruption, interception, amendment, tampering or viruses or
any consequences thereof.