Subject: [MIB-DOCTORS] double allocation in the IEEE 802.1 OID tree

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sat, 16 Mar 2013 23:58:44 +0000

Glenn Parsons requested advice on correcting a mistake made by the IEEE when allocating OIDs for their IEEE 802.1 MIB modules. They discovered that a recently approved document performed an allocation on an already used OID. 

Of course they need to change immediately the allocated value. 

Do they also need to rename the objects in the MIB module - i.e. use a different prefix? 

Dan

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Sun, 17 Mar 2013 03:01:46 -0400

Not sure I understand exactly what the question is.

Did they do this:

- there was an assignment/allocation of:          xxxx = { some-root nnn }
- they then assigned/allocated at a later point:  yyyy = { some-root nnn }

And now want to fix that incorrect assignment for yyyy ??
I.e. do something aka:   yyyy = { some-root mmm } ?

Depending on how long this situation has been existing (published), I would
consider:
- if it was a (very) short period, I would just correct the public docs.
- if it has been around for a longer time, then the safest might be to
   indeed rename xxxx and yyyy and give them both new OID values.

I wonder how such a thing could have happened. I thought that IEEE 802 had
established a good procedure to administer the assignments?

Bert Wijnen

On 3/16/13 7:58 PM, Romascanu, Dan (Dan) wrote:
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 17 Mar 2013 13:54:52 +0000

If I understand right (and Glenn can correct me if I am wrong): 

xxxx is an older assignment 
yyyy is a recent assignment

The solution would be to correct yyyy (by changing the root and renaming yyyy). 

The situation is described in a maintenance request (which is the IEEE 802 process for such changes)

http://www.ieee802.org/1/files/public/maint/requests/maint_0104.pdf

Dan

> -----Original Message-----
> From: Bert Wijnen (IETF) [mailto:[email-masked]]
> Sent: Sunday, March 17, 2013 9:02 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; Glenn Parsons
> Subject: Re: [MIB-DOCTORS] double allocation in the IEEE 802.1 OID tree
> 
> I wonder how such a thing could have happened. I thought that IEEE 802
> had established a good procedure to administer the assignments?
> 
> Bert Wijnen
> 
> > Glenn Parsons requested advice on correcting a mistake made by the
> IEEE when allocating OIDs for their IEEE 802.1 MIB modules. They
> discovered that a recently approved document performed an allocation on
> an already used OID.
> >

---

From: Glenn Parsons <[email-masked]>
Date: Sun, 17 Mar 2013 18:59:30 +0000

Thanks for your feedback.

This happened because the editor of the document made a mistake in the OID assignment allocated to the MIB module, and nobody noticed during the sponsor ballot.   We will need to ensure this does not happen again...

The 802.1Qbf amendment made the mistake:
http://www.ieee802.org/1/files/public/MIBs/IEEE8021-TEIPS-MIB-201108170000Z.txt

By using the OID --  { ieee802dot1mibs 24 } -- already allocated to 802.1Qbg:
http://www.ieee802.org/1/files/public/MIBs/IEEE8021-EVB-MIB-201202150000Z.txt

The 802.1 OID assignment is tracked here:
http://www.ieee802.org/1/pages/OIDS.html

Unfortunately, this is only now being noticed as part of the 802.1Q revision underway.  This mistake was made about a year ago.

So you recommend changing the MIB module name and OID.  For example,  they are now:

  ieee8021BridgeEvbMib  MODULE-IDENTITY
    ::= { ieee802dot1mibs 24 }

  ieee8021TeipsMib MODULE-IDENTITY
     ::= { iso(1) org(3) ieee(111)
         standards-association-numbers-series-standards (2)
         lan-man-stds (802) ieee802dot1 (1) ieee802dot1mibs (1) 24 }

And we could change to:

  ieee8021NewBridgeEvbMib  MODULE-IDENTITY
    ::= { ieee802dot1mibs 27 }

  ieee8021NewTeipsMib MODULE-IDENTITY
    ::= { ieee802dot1mibs 28 }

But do we also need to deprecate the old table and object names? And use new table and object names within the MIB modules?

Cheers,
Glenn.

-----Original Message-----
From: Bert Wijnen (IETF) [mailto:[email-masked]] 
Sent: March-17-13 3:02 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]; Glenn Parsons
Subject: Re: [MIB-DOCTORS] double allocation in the IEEE 802.1 OID tree

Did they do this:

I wonder how such a thing could have happened. I thought that IEEE 802 had established a good procedure to administer the assignments?

Bert Wijnen

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 18 Mar 2013 11:00:09 +0100

Inline

Bert Wijnen

> This happened because the editor of the document made a mistake in the OID assignment allocated to the MIB module, and nobody noticed during the sponsor ballot.   We will need to ensure this does n…
Happens I guess....:-(

> But do we also need to deprecate the old table and object names? And use new table and object names within the MIB modules?

I think to do it properly you would also have to rename all the "descriptors" or "names" of the
underlying objects/tables/conformance statements etc.
E.g. prefix them all with ieee8021New instead of the current ieee8021
And indeed deprecate (i think I would even obsolete) the old ones.

But do you have any info on how widely the two modules are implemented and deployed?

Renaming is a lot of work, and also causes trouble on current usage.

Depending on implementations/deployment,
doing a quick (and dirty, not according to normal procedure) fix the
 >           lan-man-stds (802) ieee802dot1 (1) ieee802dot1mibs (1) 24 }
into
 >           lan-man-stds (802) ieee802dot1 (1) ieee802dot1mibs (1) 27 }
might be an option if that TeipsMib module is not yet (widely) implemented
or deployed.

My fellow MIB-doctors may disagree with me. So I would love to see some
comments from them too.

Bert

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 18 Mar 2013 10:43:37 -0500

Hello,

Since the MIBs being discussed are from a  standard's body, then my 
preference would be to be more cautious and do the fix as completely as 
possible which entails renaming by adding to the prefix (such as "New")  and 
deprecating/obsoleting the old MIB modules as Bert outlines with the 
"proper" fix  below.

Thanks,
 -Joan

----- Original Message ----- 
From: "Bert Wijnen (IETF)" <[email-masked]>
To: "Glenn Parsons" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, March 18, 2013 5:00 AM
Subject: Re: [MIB-DOCTORS] double allocation in the IEEE 802.1 OID tree

>> This happened because the editor of the document made a mistake in the 
>> OID assignment allocated to the MIB module, and nobody noticed during the 
>> sponsor ballot.   We will need to ensure this does not happen again...
>>
> Happens I guess....:-(
>
>> Unfortunately, this is only now being noticed as part of the 802.1Q 
>> revision underway.  This mistake was made about a year ago.
>>
>> But do we also need to deprecate the old table and object names? And use 
>> new table and object names within the MIB modules?
>>
>
>>> Glenn Parsons requested advice on correcting a mistake made by the IEEE 
>>> when allocating OIDs for their IEEE 802.1 MIB modules. They discovered 
>>> that a recently approved document performed an allocation on an already 
>>> used OID.
>>>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 18 Mar 2013 22:59:51 +0000

> Sent: Monday, March 18, 2013 12:00 PM
> To: Glenn Parsons
> Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> OID assignment allocated to the MIB module, and nobody noticed during
> the sponsor ballot.   We will need to ensure this does not happen
> again...
> >
> Happens I guess....:-(
> 

[[DR]] The lesson to be learned here is that task should NOT be left to document editors. The IEEE 802 should implement the same mode of work as in the IETF (also recommended by RFC 4181) i.e. no allocations in the MIB module just 

::= dot1mibs xxxx

-- xxxx to be allocated at Sponsor Ballot

and leave the task of the allocation to an independent body (maybe to the RAC). 

Regards,

Dan

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 19 Mar 2013 09:53:00 +0100

Strongly agree with Dan's comment

Bert Wijnen

---

From: Tony Jeffree <[email-masked]>
Date: Tue, 19 Mar 2013 12:24:34 +0000

Guys.

There WAS and IS a process in place. The problem was that it wasn't
followed; that is unfortunately not going to be fixed by messing with the
process, but it IS getting fixed by educating the editors.

Please don't try to over-engineer this.

Regards,
Tony

On 19 March 2013 11:38, Benoit Claise <[email-masked]> wrote:

> On 18/03/2013 23:59, Romascanu, Dan (Dan) wrote:
>
>>
>>
>>>  [[DR]] The lesson to be learned here is that task should NOT be left to
>> document editors. The IEEE 802 should implement the same mode of work as in
>> the IETF (also recommended by RFC 4181) i.e. no allocations in the MIB
>> module just
>>
>> ::= dot1mibs xxxx
>>
> Exactly.
> I'm not a process guy, but should we, in this case, put a process in place
> so that it doesn't happen in the future?
>
> Regards, Benoit (as OPS AD)
>
>>
>> Regards,
>>
>>
>> Dan
>>
>> ______________________________**_________________
>> MIB-DOCTORS mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/mib-doctors<https://www.ietf.org/mailman/listinfo/mib-doctors>
>>
>>
>>
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 19 Mar 2013 12:38:10 +0100

> and leave the task of the allocation to an independent body (maybe to the RAC).
Exactly.
I'm not a process guy, but should we, in this case, put a process in 
place so that it doesn't happen in the future?