Subject: Re: [MIB-DOCTORS] [eman] 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

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 23 Dec 2013 23:50:08 -0800 (GMT-08:00)

Hi -

>From: Steve Waldbusser <[email-masked]>
>Sent: Dec 23, 2013 10:09 PM
>To: [email-masked]
>On 12/20/2013 3:02 AM, Juergen Schoenwaelder wrote:
>> Are we optimizing for applications that do blind MIB walks in order to
>> find information for managing certain functions or do we expect
>> sligthly more advanced applications?
>>
>Juergen,
>
>The biggest issue is providing organization to make it easier for people 
>to understand.
>
>For example, in your last IETF MIB, the Syslog-Msg-MIB, all the 
>assignments could have been made under the root in one big flat mess. 
>Instead you grouped the scalars in their own subtree and grouped 
>notifications and conformances into their own subtrees. The organization 
>made the whole thing easier to follow.

I hope no one is using the OID hierarchy as a tool for
explaining the logical structure of the MIB.  As Juergen
has already commented, the OID structure has very little
to do with the logical structure of a system.

Where it *does* make sense to collect things into common
subtrees are cases where any of the following apply:
   1) the pieces of information are likely to be implemented
      in a particular subagent (thus simplifying registration)
   2) the pieces of information are likely to be treated in
      the same way by an access control policy (thus
      reducing the number of entries needed in VACM tables)

>Further, I don't see any downsides to one mib-2 subtree. And nobody has 
>listed any benefits of forcing multiple mib-2 subtrees.

A very small disadvantage to rooting these below a single
mib-2 subtree is a slight increase (due to longer OIDs) in
both VACM and subagent processing costs.  For the implementations
with which I am familiar, there would be no subagent
registration savings (a small saving is theoretically possible
if all these MIB modules were implemented in a single subagent,
but the code generator I know best will not take advantage
of the theoretical savings opportunity, which would be offset
by increased per-operation costs anyway.

A small advantage to forcing multiple mib-2 subtrees is that
it reduces the likelihood of screwups due to "experiments"
in future I-Ds escaping into the wild.

>I think a body of work containing 5 MIB modules in three documents is 
>going to be complex enough without us making it worse.

I think the registration structure has nothing to do with
the complexity of the documents.  We should work to educate
folks that the registration structure is largely meaningless,
reflecting standards-administration, rather than operational/
management requirements.

Randy