Subject: Re: [eman] [MIB-DOCTORS] A single OID for energy and the 3 EMAN MIBs (message to draft-ietf-eman-battery-mib authors)

From: Randy Presuhn <[email-masked]>
Date: Sat, 14 Dec 2013 11:22:50 -0800 (GMT-08:00)

Hi -

>From: Benoit Claise <[email-masked]>
>Sent: Dec 14, 2013 1:13 AM
>To: eman mailing list <[email-masked]>, [email-masked], "MIB Doctors (E-mail)" <[email-masked]>
>Subject: Re: [MIB-DOCTORS] [eman] A single OID for energy and the 3 EMAN MIBs (message to draft-ietf-eman-battery-mib authors)
>
>Hi Jürgen, MIB doctors,
>
>Jürgen,
>I wish you had reacted when this email was posted: 
>http://www.ietf.org/mail-archive/web/eman/current/msg02064.html, or 
>during the WG meeting where it was discussed (too bad that the meeting 
>minutes didn't cover that level of details).
>
>While I understand that assigning a MODULE-IDENTITY descriptor could be 
>problematic, here it's different: this unique MODULE-IDENTITY descriptor 
>is for related MIB modules, and this happens to be a WG in this case.
>We have 3 MIB documents containing 5 MIB modules, all related to Energy:
>     2 are for Textual Conventions
>     3 are interconnected: the second and third ones require some 
>objects to be implemented in the first one.
...

It's not forbidden, it's just not recommended, due to bad
experiences in the past.  So the question becomes one of
figuring out what would be sufficient reason to disregard
the recommendation.

So what *does* such a registration accomplish?  It means
that the "related" MIB modules have one more leading
subidentifier in common than if they had been registered
conventionally, and that this subidentifier can be used
to distinguish them as a group from other MIB modules.

But what does *that* accomplish?  I can only think of
two possible benefits.

   1) IFF all these MIB modules are implemented in a
      single process by a single logical subagent,
      then only one SMUX or AgentX registration
      request, rather than three, would be needed.
      In the implementations with which I am most
      familiar, the cost of slightly longer OID
      operations would be a wash when compared to
      the increased number of subtrees known to
      the master agent.  In the subagent itself,
      the one-time savings in a smaller number of
      registrations would be eaten up over time
      by the slightly longer OID operations in SMUX,
      less so in Agentx. (However, for purposes of
      maintaining sysORTable, the subagent would
      probably still register all three subtrees,
      thus resulting in a net increase in processing
      cost due to the longer OIDs.)  (Also, the
      subagent code generation tools with which I
      am most familiar do not generate code to support
      registrations "above" a compiled MIB module.)

   2) Similar to the subagent question, the proposed
      registration structure could, for each distinct
      access control policy specifically concerned with
      these MIB modules, reduce the number of entries
      in the vacmViewTreeFamilyTable by as much as
      two, though the vacmViewTreeFamilySubtree and
      vacmViewTreeFamilyMask would be correspondingly
      longer.  Of course, whether one's management
      tools would know to "merge" the policies for
      "lexicographically related" MIB modules is a
      question for the management tool vendors.  I
      suspect that the tools probably *don't* know
      how to do this kind of optimization, and that
      there are too few cases where it happens to make
      such an optimization worthwhile.

In short, I find both of these lines of reasoning entirely
unconvincing as arguments for disregarding registration
conventions.

Perhaps the working group could explain what they thought
they would gain by doing such a registration.

Randy