Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10

From: Randy Presuhn <[email-masked]>
Date: Wed, 17 Jul 2013 11:28:44 -0700 (GMT-07:00)

Hi -

>From: Andy Bierman 
>Sent: Jul 17, 2013 6:36 AM
>To: Randy Presuhn 
>Cc: Steve Waldbusser , [email-masked], "Giles Heron (giheron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , [email-masked]
>Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10
>
>Hi,
>
>From the POV of an agent developer this is one of the fundamental
>flaws in SNMP -- natural data structures are not possible.
>IMO, the "unfolded" tables make agent implementation a nightmare.

In that regard it's no worse than a normalized database.
If you'd like a much more human-friendly (object-oriented)
way of representing information, GDMO/CMIP would have
been your ticket.  But we know where that went.  :-|

...
>It is better for the NMS if every agent supports every possible creation order
>for every data structure.  It is easy to say an agent MUST support any order.

True.

>Reality doesn't follow RFC 2119 though, and agent developers end up
>putting lots of undocumented restrictions in their code.  NMS developers
>are forced to play detective and figure out what each agent implementation
>will actually accept.

And this is what makes no sense to me.  These "undocumented
restrictions" actually *increase* agent code complexity.  They
are effectively additional hidden state.  Providing a consistent
semantic for dangling references (as was done in the SNMPv3 MIBs)
both simplifies agent code *and* makes it more robust.  Everyone
wins.  The pain of developers who add "undocumented restrictions"
is entirely self-inflicted.

>So even though Steve's suggestion is more restrictive, IMO it might actually
>help the NMS developer if the bar is set a little lower on the agent.

I think the phrase "the bar is set a little lower" frames
the discussion in a misleading way.  Eliminating side effects
and defining a consistent semantic for dangling references
*reduces* agent implementation complexity.  Permitting
side effects and implementation-specific ordering constraints
increases agent implementation complexity, increases NMS
complexity, and muddies the question of what it means to
be interoperable.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jul 2013 11:56:03 -0700

> been your ticket.  But we know where that went.  :-|

(Disclaimer: I work on YANG-based tools all day, every day.)

The balance between power and ease-of-use is hard to get right.
I think YANG scores higher on that metric than anything else
I've seen.

> is entirely self-inflicted.

But to the agent developer in a hurry, it's SNMP
(Simply Not My Problem) :-)

CLI is much worse than SNMP wrt/ undocumented restrictions.
(The whole thing is ad-hoc so one might say CLI is a completely
undocumented API.)

In fact, the trouble facing NETCONF adoption has everything
to do with transitioning from no-rules ad-hoc CLI to anything
structured (NETCONF/YANG included), and nothing to do with SNMP.

> complexity, and muddies the question of what it means to

IMO this is no different than any other optional functionality.
The NMS developer may avoid an optional mechanism because
not all agents support it.  The agent developer may have valid
reasons why it cannot be implemented.

The WG can require creation in any order and hope for
the best from vendors.

I suggest using a protocol with some sort
of a transaction model with datastore validation. SNMP has
neither of those, rendering it DOA for configuration.

> Randy

Andy