Subject: [Isis-wg] correct parent branch of isisMIB

From: Alberto Rubio <[email-masked]>
Date: Fri, 27 May 2005 12:04:45 +0200

Hi,

I have a question on the MIB module:

What's the correct parent branch of isisMIB?

According to 
http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.txt

    isisMIB MODULE-IDENTITY
        ....
    ::= { mib-2 XXX }

-- RFC Editor - please replace with proper IANA Value

However according to IANA
 http://www.iana.org/assignments/smi-numbers

Prefix: iso.org.dod.internet.experimental (1.3.6.1.3.)
37   ISIS-MIB      Integrated ISIS protocol MIB

Thanks,
Alberto
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: "Parker, Jeff" <[email-masked]>
Date: Fri, 27 May 2005 09:06:13 -0400

The MIB is not yet an official document.  When it becomes one, it will be
given an official ID.

I was encouraged not- to use the experimental ID, for excellent reasons
that I have long since forgotten.

- jeff parker
- mib scribe

On 5/27/05 6:04 AM, "Alberto Rubio" <[email-masked]> wrote:

> According to http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.txt
> 
>     isisMIB MODULE-IDENTITY
>         ....
>     ::= { mib-2 XXX }
>

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 31 May 2005 10:16:00 -0700 (PDT)

>>>>> On 5/27/05 6:04 AM, "Alberto Rubio" <[email-masked]> wrote:
Alberto> I have a question on the MIB module:
Alberto> 
Alberto> What's the correct parent branch of isisMIB?
Alberto> 
Alberto> According to http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.txt
Alberto> 
Alberto>     isisMIB MODULE-IDENTITY
Alberto>         ....
Alberto>     ::= { mib-2 XXX }
Alberto> 
Alberto> -- RFC Editor - please replace with proper IANA Value
Alberto> 
Alberto> However according to IANA
Alberto>  http://www.iana.org/assignments/smi-numbers
Alberto> 
Alberto> Prefix: iso.org.dod.internet.experimental (1.3.6.1.3.)
Alberto> 37   ISIS-MIB      Integrated ISIS protocol MIB

>>>>> On Fri, 27 May 2005, Parker, Jeff replied:
Jeff> The MIB is not yet an official document.  When it becomes one,
Jeff> it will be given an official ID.
Jeff> 
Jeff> I was encouraged -not- to use the experimental ID, for excellent
Jeff> reasons that I have long since forgotten.

This is done to comply with the policy set forth in RFC 2578 Section 4,
which says:

   The mgmt(2) subtree is used to identify "standard" objects.

   The experimental(3) subtree is used to identify objects being
   designed by working groups of the IETF.  If an information module
   produced by a working group becomes a "standard" information module,
   then at the very beginning of its entry onto the Internet standards
   track, the objects are moved under the mgmt(2) subtree.

Since this MIB module is being moved to the standards track, the objects
need to be registered under the mgmt subtree.  The traditional place is
under mib-2, which is { mgmt 1 }.

The reason for this split is that we enforce rather strict standards on
backward compatibility once an object is defined in a published RFC.  We
can't do that (and don't want to do that) for stuff that is still under
development (i.e., still in the Internet-Draft stage).  OIDs under the
experimental subtree can be assigned so that people can experiment with
pre-standard implementations.  It would be OK to continue to use the
{ experimental 37 } node for pre-standard implementations of the
ISIS-MIB provided that they were strictly experimental and were not
targeted for deployment in an operational environment.

See also draft-ietf-ops-mib-review-guidelines-04.txt Section 4.3.

Hope this helps.

Mike Heard