Subject: [MIB-DOCTORS] Pre-standard MIB modules in product

From: "David Harrington" <[email-masked]>
Date: Wed, 17 Jan 2007 11:14:04 -0500

Hi,

What is the preferred way to use a pre-standard MIB in products?

Huawei wants to implement a MIB module that has not yet been assigned
an OID by IANA.
Should we just put the module as is under our own enterprise tree?
Should we change all the descriptors to have a huawei prefix?

David Harrington
[email-masked] 
[email-masked]
[email-masked]

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jan 2007 09:08:45 -0800

> Should we change all the descriptors to have a huawei prefix?

Hehe -- this came up over and over at Cisco.
I'm afraid I was responsible for some Entity MIB headaches there
because I took the high road, which assumes that tools will actually
follow the SMI rules, and treat descriptors from different modules
as being in different namespaces.  The reality is, not many tools
support this, and all MIB modules share 1 descriptor namespace instead.

Short answer: change both the module name and all the descriptors to be safe.

(Let's see how well NE vendors do wrt/ XML and namespaces...)

> David Harrington

Andy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 17 Jan 2007 12:16:29 -0500

That was my experience when working on the Cabletron NMS products as
well. 

dbh

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Wednesday, January 17, 2007 12:09 PM
> To: David Harrington
> Cc: 'MIB Doctors (E-mail)'
> Subject: Re: [MIB-DOCTORS] Pre-standard MIB modules in product
> 
> David Harrington wrote:
> > Hi,
> >

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 17 Jan 2007 09:32:30 -0800 (PST)

HI,

I thought this issue was covered in RFC 4181, but if
not, I agree with others that the approach that will
always work is to:
  1) rename the module
  2) add a prefix to the descriptors (to make then "globally
     unique")
  3) reroot the OID to the vendor space
  4) extend the DESCRIPTION clause for the module to specify
     exactly what was done
  5) include the Internet Society copyright clause.

Regards,
/david t. perkins

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 17 Jan 2007 19:39:30 +0200

Same here. Moving under the enterprise tree and allocating a company
prefix to names would do in most cases for the name - would make sure
it's not just huawei but rather huaweiIetf so that you avoid having
huaweiInOctets already defined.

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Wednesday, January 17, 2007 7:16 PM
> To: 'Andy Bierman'
> Subject: RE: [MIB-DOCTORS] Pre-standard MIB modules in product
> 
> That was my experience when working on the Cabletron NMS 
> products as well. 
> 
> dbh
> 
> > follow the SMI rules, and treat descriptors from different 
> modules as 
> > being in different namespaces.  The reality is, not many 
> tools support 
> > this, and all MIB modules share 1 descriptor namespace instead.
> > 
> > Short answer: change both the module name and all the 
> descriptors to 
> > be safe.
> >

---

From: "David Harrington" <[email-masked]>
Date: Wed, 17 Jan 2007 12:47:35 -0500

Hi,

Your advice sounds very reasonable.

Actually what RFC4181 says is 
"Note well:  prior to official assignment by the IANA, a draft
   document MUST use a placeholder (such as "XXX" above) rather than
an
   actual number.  If trial implementations are desired during the
   development process, then an assignment under the 'experimental'
   subtree may be obtained from the IANA (cf. Section 4.3).
" 

AND
"  Experience has shown that it is impractical to move objects from
one
   subtree to another once those objects have seen large-scale use in
an
   operational environment.  Hence any object that is targeted for
   deployment in an operational environment MUST NOT be registered
under
   the experimental subtree, irrespective of the standardization
status
   of that object. "

So it seems we provide advice about what NOT to do, but not what to
do.

dbh

> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, January 17, 2007 12:33 PM
> To: David Harrington
> Cc: 'MIB Doctors \(E-mail\)'

---

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 18 Jan 2007 02:33:16 -0500

Hello,

Yes, we also followed the naming convention below and placing
under the enterprise tree at most of the companies
I've been at, including both startups and more established
companies.

In fact there are times when both (the enterprise MIB and the
IETF MIBs) were supported for quite a while in the agent due to
reasons such as NMS development timeframe, SQA
or even customers wanting the enterprise MIB to remain in
place due to tools that the customer had developed.

-Joan

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "David Harrington" <[email-masked]>; "Andy Bierman" 
<[email-masked]>
Cc: "MIB Doctors (E-mail)" <[email-masked]>
Sent: Wednesday, January 17, 2007 12:39 PM
Subject: RE: [MIB-DOCTORS] Pre-standard MIB modules in product

Dan

---

From: "Orly Nicklass" <[email-masked]>
Date: Thu, 18 Jan 2007 11:30:31 +0200

We do the same , add prefix and move to enterprise tree.
Sometimes we keep supporting  of correlated objects for few versions
depending on marketing needs.

Orly

-----Original Message-----
From: Joan Cucchiara [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 09:33
To: Romascanu, Dan (Dan); David Harrington; Andy Bierman
Cc: MIB Doctors (E-mail)
Subject: Re: [MIB-DOCTORS] Pre-standard MIB modules in product

Hello,

Yes, we also followed the naming convention below and placing under the
enterprise tree at most of the companies I've been at, including both
startups and more established companies.

In fact there are times when both (the enterprise MIB and the IETF MIBs)
were supported for quite a while in the agent due to reasons such as NMS
development timeframe, SQA or even customers wanting the enterprise MIB
to remain in place due to tools that the customer had developed.

-Joan

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "David Harrington" <[email-masked]>; "Andy Bierman" 
<[email-masked]>

Dan