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

From: Benoit Claise <[email-masked]>
Date: Sat, 14 Dec 2013 10:13:06 +0100

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.

MIB doctors,
Let us know your advice

Regards, Benoit

> Hi,
>
> in the past such registration spaces led to problems (I think RMON was
> the case) and I think because of that we moved pretty much all
> registrations below mib-2 and transmission. Bert Wijnen might recall
> the details. If we change our strategy, we should probably have strong
> reasons and understand the longer term implications. There is the relvant
> quote from RFC 4181:
>
>     - The value assigned to the MODULE-IDENTITY descriptor MUST be unique
>       and (for IETF standards-track MIB modules) SHOULD reside under the
>       mgmt subtree [RFC2578].  Most often it will be an IANA-assigned
>       value directly under mib-2 [RFC2578], although for media-specific
>       MIB modules that extend the IF-MIB [RFC2863] it is customary to use
>       an IANA-assigned value under transmission [RFC2578].  In the past,
>       some IETF working groups have made their own assignments from
>       subtrees delegated to them by IANA, but that practice has proven
>       problematic and is NOT RECOMMENDED.
>
> /js
>
> On Fri, Dec 13, 2013 at 11:31:23PM +0100, Benoit Claise wrote:
>> Dear all,
>>
>> During the last IETF meeting, there was an agreement to go for a
>> single energyMIB OID under mib-2.
>>
>> energyObjectContextMIB MODULE-IDENTITY
>> (draft-ietf-eman-energy-aware-mib) is under energyMIB.1
>> ianaEnergyRelationMIB MODULE-IDENTITY
>> (draft-ietf-eman-energy-aware-mib) is under energyMIB.2
>> energyObjectMIB MODULE-IDENTITY
>> (draft-ietf-eman-energy-monitoring-mib) is under energyMIB.3
>> powerAttributesMIB MODULE-IDENTITY
>> (draft-ietf-eman-energy-monitoring-mib) is under energyMIB.4
>>
>> For draft-ietf-eman-battery-mib, you can start with energyMIB.5
>> Note that draft-ietf-eman-energy-aware-mib requests:
>>
>>             Descriptor                      OBJECT IDENTIFIER value
>>             ----------                      -----------------------
>>
>>             energyMIB                         { mib-2 XXX }
>>
>>
>> Btw, both draft-ietf-eman-energy-aware-mib and
>> draft-ietf-eman-energy-monitoring-mib are ready for WGLC.
>>
>> Regards, Benoit
>>
>>
>> _______________________________________________
>> eman mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/eman

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 14 Dec 2013 16:27:07 +0100

On Sat, Dec 14, 2013 at 10:13:06AM +0100, Benoit Claise wrote:

> 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.

I think bad experience was made with RMON but I am not 100%
sure. Things may start in one WG but later get out of control. For
stuff below mib-2 and transmission, there is a defined registry.

What do you gain by a single OID? The single walk argument? Well, even
the IF-MIB is in two branches. And who knows what other stuff might be
put under the common OID root in the future. Decent management
applications likely don't walk arbitrary subtrees (but if OID based
MIB browsers is all we have, well then there might be some value).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 14 Dec 2013 08:48:23 -0800

Hi,

I was RMONMIB WG chair and I do remember there was concern
after RMON had done this about 8 times. I think a CLR was created
to prevent any attempt at data organization done by WGs.
I think the reason was that the WG assigned a real OID in an I-D.
People thought it was better to have XXX instead of a
real number.  If the I-D did not get published as an I-D, then
an OID number was wasted. Only IANA can assign XXX to
make sure only published RFCs get real OIDs.

Andy

---

From: Steve Waldbusser <[email-masked]>
Date: Sat, 14 Dec 2013 11:00:09 -0800

Decades ago there were several concerns about what might happen if the 
working group got their IANA assigmnent before Proposed Standard. They 
boiled down to:
1. What if vendors shipped pre-standard versions?
   (To a small degree out of a desire to protect customers and
   to a large degree a desire to protect the control/independence of the 
IETF)
2. What if vendors pressured the working group to call it done so that 
shipped
   code wouldn't be made incompatible?
   (Out of a desire to protect the WG's power to do the job right)

But a WG doesn't have to wait for IANA before extending a MIB. The RMON 
WG extended its MIB many times, using the RMON subtree and not waiting, 
but didn't  experience any of those problems. This is probably because 
the IETF (in contrast to other standards orgs) didn't put a bunch of 
roadblocks and delay to standardization (rough concensus and running 
code) so a big disconnect never materialized. Juergen, what sort of 
problems do you remember?

Solving this "problem" for existing standards means splitting up 
extensions under different subtrees which is confusing. The problem is 
that humans aren't robots and structure helps people understand and 
navigate more easily (especially for customers). Within a MIB, don't we 
all take some care to design the MIB with a reasonable structure? People 
think this is complicated enough already.

If controlling the WG is really viewed as an important problem to solve, 
maybe a win-win would be to tell them they must do their IDs under xxx 
and then later have the RFC-editor replace that with new subtrees under 
their old standard.

Steve

On 12/14/2013 8:48 AM, Andy Bierman wrote:
> On Sat, Dec 14, 2013 at 7:27 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 16 Dec 2013 07:59:42 -0500

Again, the thinking was to just be neat and tidy to keep the OIDs together; nothing more, nothing less. I think the intent is the same here. To address your concern over control of the OID space,  in the examples I cited with the the MPLS, CCAMP or PWE3 MIBs, we did get the root OID assigned from IANA, and IANA was instructed to manage all future OID assignments.  This is from RFC3811 as an example and this is how I recommended the EMAN MIBs do things:

6.  IANA Considerations

   IANA has made a MIB OID assignment under the transmission branch,
   that is, assigned the mplsStdMIB under { transmission 166 }.  This
   sub-id is requested because 166 is the ifType for mpls(166) and is
   available under transmission.

   In the future, MPLS related standards track MIB modules should be
   rooted under the mplsStdMIB subtree.  The IANA is requested to manage
   that namespace.  New assignments can only be made via a Standards
   Action as specified in [RFC2434].

   The IANA has also assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB
   specified in this document.

	So you can see, its merely a nice grouping of OIDs that is going to happen as a result of rooting things under a single OID. 

	--Tom

On Dec 14, 2013:2:00 PM, at 2:00 PM, Steve Waldbusser <[email-masked]> wrote:

> Decades ago there were several concerns about what might happen if the working group got their IANA assigmnent before Proposed Standard. They boiled down to:
>   to a large degree a desire to protect the control/independence of the IETF)
> 2. What if vendors pressured the working group to call it done so that shipped
> But a WG doesn't have to wait for IANA before extending a MIB. The RMON WG extended its MIB many times, using the RMON subtree and not waiting, but didn't  experience any of those problems. This is probably because the IETF (in contrast to other standards orgs) didn't put a bunch of roadblocks and delay to standardization (rough concensus and running code) so a big disconnect never materialized. Juergen, what sort of problems do you remember?
> 
> Solving this "problem" for existing standards means splitting up extensions under different subtrees which is confusing. The problem is that humans aren't robots and structure helps people understand and navigate more easily (especially for customers). Within a MIB, don't we all take some care to design the MIB with a reasonable structure? People think this is complicated enough already.
> 
> If controlling the WG is really viewed as an important problem to solve, maybe a win-win would be to tell them they must do their IDs under xxx and then later have the RFC-editor replace that with new subtrees under their old standard.
> 
> Steve
> 
> 
> 
>> On Sat, Dec 14, 2013 at 7:27 AM, Juergen Schoenwaelder <[email-masked]> wrote:

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 19 Dec 2013 16:31:17 +0000

Hi Benoit,

I don't think it is a big issue to revise this decision in order to be in line with IETF recommendations.
It was anyway only a question of style. 
There was no technical reason to use one OID for all.
As a workaround we can ask IANA for consecutive OIDs for these drafts.

I did not understand a comment you made:
>      3 are interconnected: the second and third ones require some objects to be
I assume the third of the 3 'interconnected' modules is the BATTERY MIB. How is it connected to the others? I do not see any dependency of the BATTERY MIB on the other two modules.

Cheers,
    Juergen

> -----Original Message-----
> From: eman [mailto:[email-masked]] On Behalf Of Benoit Claise
> Sent: Samstag, 14. Dezember 2013 10:13
> To: eman mailing list; [email-masked]; MIB Doctors
> (E-mail)
> Subject: Re: [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,
> 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.
>      3 are interconnected: the second and third ones require some objects to be
> implemented in the first one.
> 
> MIB doctors,
> Let us know your advice
> 
> Regards, Benoit
> 
> > Hi,
> >
> > reasons and understand the longer term implications. There is the
> > relvant quote from RFC 4181:
> >
> >> For draft-ietf-eman-battery-mib, you can start with energyMIB.5 Note
> >> that draft-ietf-eman-energy-aware-mib requests:
> >>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 20 Dec 2013 11:45:06 +0100

Hi Jürgen,
> I don't think it is a big issue to revise this decision in order to be in line with IETF recommendations.
As an author, I will follow whatever advice/consensus the MIB doctors 
will come up with. At this point, I'm not sure about the outcome. 
Practically, I believe that Tom Nadeau, as the MIB doctor for these EMAN 
documents (and EMAN co-chair) should be providing guidance here.
> I assume the third of the 3 'interconnected' modules is the BATTERY MIB. How is it connected to the others? I do not see any dependency of the BATTERY MIB on the other two modules.
No direct dependency, correct.
However, the battery MIB shares the index (entPhysicalIndex) and minimum 
entity4CRCompliance with draft-ietf-eman-energy-aware-mib 
<https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib/>

    Batteries are indexed by the entPhysicalIndex of the entPhysicalTable
    defined in the ENTITY-MIB module [RFC6933].  An implementation of the
    ENTITY-MIB module complying with the entity4CRCompliance MODULE-
    COMPLIANCE statement is required for compliant implementations of the
    BATTERY-MIB module.

Practically, we know that there are two cases:
1. the battery is completely independent and the NMS only wants to 
monitor the battery: only the battery MIB is implemented
2. the battery is part of a device, and the NMS also needs to understand 
the inventory and energy information from that device: both energy aware 
and battery MIBs will be implemented.

I have the feeling that #2>> #1

Regards, Benoit
> .

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Dec 2013 12:02:41 +0100

On Fri, Dec 20, 2013 at 11:45:06AM +0100, Benoit Claise wrote:

> > I assume the third of the 3 'interconnected' modules is the
> > BATTERY MIB. How is it connected to the others? I do not see any
> > dependency of the BATTERY MIB on the other two modules.

> However, the battery MIB shares the index (entPhysicalIndex) and
> minimum entity4CRCompliance with draft-ietf-eman-energy-aware-mib
> 2. the battery is part of a device, and the NMS also needs to
> understand the inventory and energy information from that device:
> both energy aware and battery MIBs will be implemented.
> 

So the point is being made that the battery MIB should be rooted under
the ENTITY-MIB? Perhaps this example makes it clear that attempts to
find a proper logical nesting do not scale up.

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?

/js

---

From: Benoit Claise <[email-masked]>
Date: Mon, 23 Dec 2013 12:30:22 +0100

On 20/12/2013 12:02, Juergen Schoenwaelder wrote:
> the ENTITY-MIB?
Not quite.

Regards, Benoit
> Perhaps this example makes it clear that attempts to

---

From: Steve Waldbusser <[email-masked]>
Date: Mon, 23 Dec 2013 22:09:16 -0800

> 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.

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

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

Steve

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Dec 2013 07:42:17 +0100

On Mon, Dec 23, 2013 at 10:09:16PM -0800, Steve Waldbusser wrote:
> The biggest issue is providing organization to make it easier for
> people to understand.
> 
> 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 thought how the MIB module is rooted not how it is structured
internally.
 
> Further, I don't see any downsides to one mib-2 subtree. And nobody
> has listed any benefits of forcing multiple mib-2 subtrees.

I pointed to RFC 4181 section 4.5:

Perhaps this text is wrong. But until we decide that, I do not see why
this should be ignored. Or let me state it this way, I fail to see the
benefits that justify to ignore a SHOULD.

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

There are other sets of related MIB modules that are registered under
mib-2 (following RFC 4181 section 4.5) and I am not aware that this
caused implementation or interoperability problems.

/js

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 26 Dec 2013 15:45:59 +0000

So, we found there is no dependency of the BATTERY-MIB on other eman MIB modules (except for using the ENTITY MIB which has its own OID already). Hence, we do not have a technical reason to use a common OID prefix for the current eman MIB modules. Rather we are creating a common OID prefix for MIB modules developed by the eman WG. This is a matter of style. Do we want to introduce WG-owned OID prefixes at the IETF?
    Juergen Q. 

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Freitag, 20. Dezember 2013 12:03
> To: Benoit Claise
> Cc: Juergen Quittek; eman mailing list; draft-ietf-eman-battery-
> [email-masked]; MIB Doctors (E-mail)
> Subject: Re: [MIB-DOCTORS] [eman] A single OID for energy and the 3 EMAN
> MIBs (message to draft-ietf-eman-battery-mib authors)
> 
> > > I assume the third of the 3 'interconnected' modules is the BATTERY
> > > MIB. How is it connected to the others? I do not see any dependency
> > > of the BATTERY MIB on the other two modules.
> 
> > monitor the battery: only the battery MIB is implemented 2. the
> > battery is part of a device, and the NMS also needs to understand the
> > inventory and energy information from that device:
> So the point is being made that the battery MIB should be rooted under the
> ENTITY-MIB? Perhaps this example makes it clear that attempts to find a
> proper logical nesting do not scale up.
> 
> 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?
> 
> /js
> 
> --