Subject: [MIB-DOCTORS] IfTypeReferences - v35(45) and dot12MIB

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 4 Aug 2006 22:13:08 +0200

Thanks John, I think this helps explain how things went wrong.

Dan, pls read, because I bet IANA may want an AD approval if we do
request this update to their online pages/registries.

All, 
So it seems to me then that we cannot change the value as listed 
in the RFC2020. So we'd have to try to get IANA to change the
assignment in the smi-numbers (i.e., remove it from mib-2 list)
that is, change under 

  Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)	

the row that says:

     45   dot12MIB      IEEE 802.12                      [RFC2020]

into

     45   reserved      (do not reassign, was incorrectly listed as
                          dot12MIB IEEE 802.12  [RFC2020])

We then can keep dot12MIB under transmission (since that is what is 
in the MIB module in the RFC, and since that has been implemented).

It does not byte at the moment, because RFC1659 states:

   The RS-232-like MIB is relevant for ifType values rs232(33), v35(45),
   and perhaps others.

and the MIB module in there (RS-232-MIB) does have transmission.33
So the v35(45) in fact is captured in transmission.33 MIB.

I have these entries now:

      <!--label-->     <c>rs232</c>
      <!--ifType-->    <c>33</c>
      <!--MIBoid-->    <c>transmission.33</c>
      <!--MIBmodule--> <c>RS-232-MIB</c>
      <!--Reference--> <c><xref target='RFC1659'/> (DS)</c>
      <!--comment-->   <c></c>

      <!--label-->     <c>v35</c>
      <!--ifType-->    <c>45</c>
      <!--MIBoid-->    <c>transmission.33</c>
      <!--MIBmodule--> <c>RS-232-MIB</c>
      <!--Reference--> <c><xref target='RFC1659'/> (DS)</c>
      <!--comment-->   <c>note: transmission.45 OID is used by dot12MIB
                          <xref target='RFC2020'/>. This was probably
                          assigned in error, but that is what it is and
                          since implementations exist, we cannot change it.
                       </c>

     <!--label-->     <c>ieee80212</c>
     <!--ifType-->    <c>55</c>
     <!--MIBoid-->    <c>transmission.45</c>
     <!--MIBmodule--> <c>dot12MIB</c>
     <!--Reference--> <c><xref target='RFC2020'/> (PS)</c>
     <!--comment-->   <c>100BaseVG
                        <vspace blanklines='0'/>
                         transmission.55 OID was probably intended
                         but <xref target='RFC2020'/> has transmission.45
assigned.
                         This was probably assigned in error, but
implemenations
                         most probably have used what is in RFC2020.
                      </c>

John, Keith, Dan and others, do we agree?

Bert
> -----Original Message-----
> From: John Flick [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2006 23:44
> To: Keith McCloghrie
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MIB-DOCTORS] Re: Last Call for the ifType 
> References table
> 
> 
> Keith, Bert,
> 
> I was the editor of RFC 2020.  When the internet-draft was submitted
> for publication, it had { transmission XXX }, and the number was
> assigned during publication.  I remember questioning the assignment
> at the time.  Here is a copy of an e-mail that I sent to IANA when
> I noticed the problem.  I believe the "fixed" the problem by adding
> the assignment under the transmission branch to smi-numbers.
> 
> Hope this helps,
> John
> 
> > Received: from cnri by ietf.org id aa23735; 16 Apr 97 18:02 EDT
> > Received: from palrel1.hp.com by CNRI.Reston.VA.US id aa23808;
> >           16 Apr 97 18:02 EDT
> > Received: from hprnd.rose.hp.com ([email-masked] 
> [15.29.43.139]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id 
> OAA03839; Wed, 16 Apr 1997 14:50:25 -0700 (PDT)
> > Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP
> > 	(1.37.109.20/15.5+ECS 3.3) id AA007587402; Wed, 16 Apr 
> 1997 14:50:02 -0700
> > Received: from localhost (johnf@localhost [127.0.0.1]) by 
> hprnljf.rose.hp.com with SMTP (8.7.5/8.7.3) id OAA02255; Wed, 
> 16 Apr 1997 14:50:23 -0700 (PDT)
> > Message-Id: <[email-masked]>
> > X-Authentication-Warning: hprnljf.rose.hp.com: Host 
> johnf@localhost [127.0.0.1] didn't use HELO protocol
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Conflict between smi-numbers and RFC 2020
> > Date: Wed, 16 Apr 1997 14:50:23 -0700
> > From: John Flick <[email-masked]>
> > 
> > On the IANA web page, under:
> > 
> >     ftp://ftp.isi.edu/in-notes/iana/assignments/smi-numbers
> > 
> > there is a listing for dot12MIB under the mib-2 branch showing it
> > as mib-2.45.
> > 
> >   Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)
> > 
> >   Decimal   Name          Description                     References
> >   -------   ----          -----------                     ----------
> >   ...
> >        45   dot12MIB      IEEE 802.12                      [RFC2020]
> > 
> > However, RFC 2020 has this assignment under the transmission branch:
> > 
> >     dot12MIB MODULE-IDENTITY
> >         LAST-UPDATED "9602220452Z"  -- February 22, 1996
> >         ORGANIZATION "IETF 100VG-AnyLAN MIB Working Group"
> >         CONTACT-INFO
> >                 "       John Flick
> > 
> >                 Postal: Hewlett Packard Company
> >                         8000 Foothills Blvd. M/S 5556
> >                         Roseville, CA 95747-5556
> >                 Tel:    +1 916 785 4018
> >                 Fax:    +1 916 785 3583
> > 
> >                 E-mail: [email-masked]"
> >         DESCRIPTION
> >                 "This MIB module describes objects for
> >                 managing IEEE 802.12 interfaces."
> >         ::= { transmission 45 }
> > 
> > Since it is a MIB for managing a particular interface type, 
> it belongs
> > under the transmission branch, so I believe the assignment 
> in RFC 2020
> > is the correct one.  Also, fielded implementations use the RFC 2020
> > assignment, not the one in smi-numbers.
> > 
> > As a side note, this assignment does not appear to follow 
> the conventions
> > for assignments under the transmission branch.  Since the ifType for
> > dot12 interfaces is 55, this should probably have been { 
> transmission 55 }.
> > However, changing this now would break fielded 
> implementations.  So I
> > guess we just have to hope that we won't need a V.35 
> transmission MIB.
> > 
> > Please correct this listing in smi-numbers.
> > 
> > Thanks,
> > John Flick
> > vgmib working group editor
> > [email-masked]
> > 
> 
> Keith McCloghrie wrote:
> >>> 7. The row for ifType=45 is incorrect.  RFC 1659 says:
> >>>
> >>>    The RS-232-like MIB is relevant for ifType values 
> >>> rs232(33), v35(45),
> >>>    and perhaps others.
> >> Mmm... RFC2020 claims:
> >>
> >>   Instances of these object types represent attributes of 
> an interface
> >>   to an IEEE 802.12 communications medium.  At present, IEEE 802.12
> >>   media are identified by one value of the ifType object in the
> >>   Internet-standard MIB:
> >>
> >>      ieee80212(55)
> >>
> >>   For this interface, the value of the ifSpecific variable 
> in the MIB-
> >>   II [5] has the OBJECT IDENTIFIER value:
> >>
> >>      dot12MIB    OBJECT IDENTIFIER ::= { transmission 45 }
> >>
> >> Could that be wrong and maybe it needs to be transmission 55 ?
> >> But the MIB MODULE itself DOES use transmission 45.
> >  
> > Yes, see below.
> > 
> >> My proposal is:
> >>
> >>   add a row for ifType 55, and let have transmission.45 
> and point to RFC2020.
> >>
> >>   change row 45 to be transmission.33 and let it point to RFC1659
> >>
> >>   add a comment to row 33: transmission.33 also used for v35(45)
> >>
> >> Sounds OK?
> >  
> > Not quite.  I agree that RFC 1659 is the correct reference 
> for v35(45).
> > 
> > I think the source of the problem is that
> > http://www.iana.org/assignments/smi-numbers  says:
> > 
> >   Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)	
> > 
> >      45   dot12MIB      IEEE 802.12                      [RFC2020]
> > 
> >   Prefix: iso.org.dod.internet.mgmt.mib-2.transmission 
> (1.3.6.1.2.1.10)
> > 
> >      45   dot12MIB      IEEE 802.12                      [RFC2020]
> > 
> > but it can't be both.  I think dot12MIB is in the mib-2 subtree
> > and { transmission 45 } is supposed to match ifType=v35(45).
> 

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

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 6 Aug 2006 13:43:22 +0300

> Dan, pls read, because I bet IANA may want an AD approval if 
> we do request this update to their online pages/registries.

I am following all the  IfTypeReferences threads and will jump in if I
have doubts on something. 

So far so good, including this one. 

Dan

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Friday, August 04, 2006 11:13 PM
> To: John Flick; Keith McCloghrie; Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: IfTypeReferences - v35(45) and dot12MIB 
> 
> Dan, pls read, because I bet IANA may want an AD approval if 
> we do request this update to their online pages/registries.
> 
> All,
> So it seems to me then that we cannot change the value as 
> listed in the RFC2020. So we'd have to try to get IANA to 
> change the assignment in the smi-numbers (i.e., remove it 
> from mib-2 list) that is, change under 
> 
> We then can keep dot12MIB under transmission (since that is 
> what is in the MIB module in the RFC, and since that has been 
> implemented).
> 
> and the MIB module in there (RS-232-MIB) does have 
> transmission.33 So the v35(45) in fact is captured in 
> transmission.33 MIB.
> 
>                          but <xref target='RFC2020'/> has 
> transmission.45 assigned.
>                          This was probably assigned in error, 
> but implemenations
> > Subject: Re: [MIB-DOCTORS] Re: Last Call for the ifType References 
> > table
> > 
> > 
> > Keith, Bert,
> > 
> > assigned during publication.  I remember questioning the 
> assignment at 
> > the time.  Here is a copy of an e-mail that I sent to IANA when I 
> > noticed the problem.  I believe the "fixed" the problem by 
> adding the 
> > assignment under the transmission branch to smi-numbers.
> > 
> > Hope this helps,
> > John
> > 
> > > there is a listing for dot12MIB under the mib-2 branch 
> showing it as 
> > > mib-2.45.
> > > 
> > > but it can't be both.  I think dot12MIB is in the mib-2 
> subtree and 
> > > { transmission 45 } is supposed to match ifType=v35(45).
> > 
>