Subject: [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: Fri, 13 Dec 2013 23:31:23 +0100

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 14 Dec 2013 09:39:30 +0100

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.
> 
> 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
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

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

---

From: Thomas D Nadeau <[email-masked]>
Date: Sat, 14 Dec 2013 09:05:14 -0500

FYI we followed a single OID model with the MPLS, CCAMP, and PWE3 MIBs and over time have had no issues around the OID.  It was actually convenient to have the grouped that way.

--Tom

> On Dec 14, 2013, at 3:39 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Hi,
>

---

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

---

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