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: Thu, 26 Dec 2013 10:50:50 -0800 (GMT-08:00)

Hi -

>From: Juergen Quittek <[email-masked]>
>Sent: Dec 26, 2013 7:45 AM
>To: Juergen Schoenwaelder <[email-masked]>, Benoit Claise <[email-masked]>
>Cc: "MIB Doctors (E-mail)" <[email-masked]>, eman mailing list <[email-masked]>, "[email-masked]" <[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)
>
>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?

1) Doing so would increase the likelihood of implementations
using WG-issued OIDs escaping into the wild prior to
publication of the RFC.  It's not merely a matter of the
WG maintaining the discipline of not making the assignments
until, say, AUTH-48.  Because the subidentifier values
would be easily guessed, folks will very likely implement
using anticipated values.

2) There is a dimly-remembered incident in the past of
WGs giving the same subid to two different modules.  I
don't think anyone wants a replay of that.  

3) WGs are (we hope) relatively short-lived entities.
After a WG is dead and buried, what would be the criteria
for locating new work within the defunct WG's tree?
After all, by giving a WG a tree to play with, we'd
be assuming there must be something meaningful or
useful reason for doing so.

Consequently, for me the answer to Juergen Q.'s question
is "no."

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Dec 2013 11:42:00 -0800

Hi,

responses inline

On Thu, Dec 26, 2013 at 10:50 AM, Randy Presuhn <
[email-masked]> wrote:

> >Cc: "MIB Doctors (E-mail)" <[email-masked]>, eman mailing list <
> [email-masked]>, "[email-masked]" <
> [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)
> >

Some people call that "escaping into the wild" early implementation
experience.
We should be doing all we can to encourage early implementation experience.

This has always been a problem in SNMP.
First you have to pick a tool-dependent MIB file suffix .
Then you have to edit the file and change XXX in the root OID to something
else.
The IETF just punted the problem to the vendor with the XXX approach.
We never developed any guidelines on how vendors should re-root I-D MIB
modules
in their enterprise OID space.

NETCONF gets around this problem by advertising module revision dates in
the <hello>.

> don't think anyone wants a replay of that.

That would be my bad in RMONMIB WG, right? ;-)
It took awhile before a cut-and-paste error from 1 RMON draft to another
was caught.

> useful reason for doing so.
There is the risk that the I-D will not get published as an RFC.
Since the OID does not really matter, it should be possible to
have IANA assign a temporary OID, under a
different OID root (ala /tmp directory :-)  IANA could assign
a real OID and replace the temporary OID when the RFC is published.

My experience several times over is that reviewing a technical spec
and writing code to do what the spec says are much different tasks.
It is usually very easy for an developer to identify where the spec
is silent or just plain wrong.  This helps the WG fix the bugs and
identify the interoperability limits.

> Consequently, for me the answer to Juergen Q.'s question

Andy