Subject: [MIB-DOCTORS] Re: Last Call for the ifType References table (was: RE: IfType re

From: Keith McCloghrie <[email-masked]>
Date: Tue, 1 Aug 2006 10:15:02 -0700 (PDT)

> Keith, finally (after vacation and soime travel) I am getting back to
> this topic. You wrote:

Specific answers below.  Also, I've discovered two other sources of
references:

- RFC 1700 contained an initial set of ifType references which seems
  to have been lost in the process described in RFC 3232.
- http://www.iana.org/assignments/smi-numbers contains references for
  assignments in the transmission subtree.

> > > http://www.ops.ietf.org/IfTypeReferences.html
> > > 
> > > Please answer until Monday, June 12 COB at all time zones on the 
> > > mreview list at the following questions:
> > > 
> > > 1. Do you believe that this table is useful, should be made publicly 
> > > available and maintained on the OPS area Web pages.
> > > 2. If the answer at #1 is positive, please check the content of the 
> > > table and provide feedback concerning the accuracy of the information 
> > > that is included and what information is missing
> > 
> > 
> > Below are corrections and a few additions to the table.  I could
> > probably add more entries, but it would take more time.
> > 
> > If IANA keep records of their submissions, then those records will
> > contain references for at least the more recent assignments.
> > 
> > Keith.
> > ------------------------
> > 
> > 0. Many ifType values do not have corresponding MIB modules or "MIB OIDs".
> > Even when they do, the document containing such a MIB module should be
> > listed as a Reference.
> > 
> > 1. The reference for both regular1822(2) and hdh1822(3) is:
> > 
> >    "Specifications for the Interconnection of a Host and an IMP",
> >    Bolt Beranek and Newman (BBN) Report No. 1822, December 1981.
> > 
> > also known as: NIC 7958, and referenced by RFCs 270, 716, 878.
> 
> So for above, I think we do not know a MIB module or an OID, right?
 
Correct.

> > 2. The reference for ddnX25(4) and rfc877x25(5) is RFC 1382, 
> > which says:
> > 
> >           -- ifType: ddn-x25 or rfc877-x25
> >           --      an interface of type ddn-x25 will use an algorithm to
> >           --      translate between X.121 address and IP addresses.
> >           --      An interface of type rfc877-x25 will use a
> >           --      configuration table to translate between X.121
> >           --      addresses and IP addresses.
> 
> So does that mean that for both, the MIB OID is transmission.5 and 
> the MIB for both is RFC1382-MIB?
> I believe so, but want to check/verify first, before I add it to the table.

Yes, and also:

  miox25(38) -- RFC 1461 & 1382
  x25ple(40)  -- RFC 1382

and perhaps also for:

  x25mlp(121)
  x25huntGroup(122)

> > 5. RFC 1694 is a later (than RFC 1304) reference for 
> > 'sip(31)', and RFC 2325 is needed as a reference if "coffee"
> > is included in the row.
> > I suggest it would be useful to expand the acronym to be: SIP (SMDS
> > Interface Protocol), but perhaps that negates the reference 
> > to "coffee" ??
> 
> Hmmmm 2325 is an April 1st RFC. Should we list it at all?
> Cause I do not think that the sip IfType applies at all, it is more of
> a joke and might confuse people who do not understand the APril 1st RFCs.
> 
> So I'd prefer to just list 1694.
 
So, why aren't/haven't they been confused by:

                   sip(31),            -- SMDS, coffee

in http://www.iana.org/assignments/ianaiftype-mib ??  Shouldn't we
be consistent ??

> > 6. RFC 3592 is the reference for:
> > 
> >            sonet(39)        -- SONET/SDH Medium/Section/Line
> >            sonetPath(50)    -- SONET/SDH Path
> >            sonetVT(51)      -- SONET/SDH Virtual Tributary/Virtual
> > Container
> > 
> > 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).

> > 8. The row for ifType=46 is incorrect.  RFC 2320 is not a 
> > reference for
> > 'hssi'; the closest to a reference I can find for HSSI is RFC 1662.
> 
> I am NOT OK to change it to RFC1662, because I doubt it helps anyone, does it?
> Maybe better to leave it open for now.
 
OK.

> and then add a row for ifType 144 that points to 1662 I think!?
 
Why 1662 ??  The best references for ifType=ieee1394(144) would seem to
be RFCs 2734 & 3146.

> > 9. The row for ifType=49 is incorrect.  RFC 2515 is the reference for
> > both of:
> > 
> >     atm(37)           -- ATM cell layer
> >     aal5(49)          -- ATM AAL5 layer
> > 
> 
> RFC2515 also talks about ifType 53 : propVirtual(53),    

Yes, 2515 describes an ATM switch as having an internal interface with
AAL5 over a propVirtual(53) interface.  This is only one example of the
usage of a propVirtual(53) interface; it can also be used in non-ATM
situations also.

> The MIB in 2515 (ATM-MIB) is registered as mib-2.37
> 
> Mmm... RFC3498 DOES assign transmission.49
> But it is for ifType sonet(39), or at least the APS-MIB seems to say so
> several times.
> Wow... have we screwed up in the past I guess.
 
Right !!  My guess is that someone at IANA assigned a seemingly unused
number, without realising the implications.

> But then, the SONET-MIB (RFC3592) claims to be for ifTypes 
>        sonet (39), sonetPath (50), sonetVT (51)
> 
> and does have as MIB oid: transmission.39
> 
> So I think I need to:
>   add to row for ifType 39 a ptr to RFC3498 in addition to  RFC3592
>   add rows for ifType 50 and 51
>   fix some comments and ptrs
 
I think so.

> > 10. The row for ifType=53 is incorrect.  The SMON-MIB refers to that
> > ifType value, but it is not the reference for it; 
> > specifically, RFC 2613 says:
> > 
> >    The SMON MIB utilizes the propVirtual(53) ifType defined in the
> >    Interfaces Group MIB [22] to provide SMON and RMON with new
> >    dataSources such as VLANs and internal monitoring points. 
> > 
> > and RFC 2515 specifies the use of propVirtual(53) "for proprietary
> > virtual, internal interface[s] associated with [ATM] AAL entities".
> > 
> > So, other uses of propVirtual(53) have been explicitly specified.  Also,
> > other ifType values have since been defined for standards-based VLANs.
> 
> so ifType-53 should point to RFC2515 I guess?
 
Only if you can make it clear that RFC-2515 is a reference for some
but *not* all uses of ifType=53.

> > 11. The reference for ieee80212(55) is RFC 2020, containing the
> > DOT12-IF-MIB.
> 
> ack
> but the MIB oid is transmission.45 no matter how unhappy that may make us
 
See above.

> > 12. RFC 2127 is the reference for:
> > 
> >    The ifType for a Terminal Endpoint can be isdn(63) for ISDN signaling
> >    channels or x25ple(40) for X.25 based packet mode services.  The
> >    ifType for D channel Data Link Layer (LAPD) interfaces is lapd(77).
> >    The ifType for B channels is ds0(81).  The ifType for physical
> >    interfaces is the matching IANA ifType, usually ds1(18) for Primary
> >    Rate interfaces or isdns(75)/isdnu(76) for Basic Rate interfaces.
> > 
> >        isdn(63)        -- ISDN Terminal endpoint (ISDN signaling channel)
> >        isdns(75)       -- ISDN 'S/T' (aka 'Four-wire Basic Access Interface')
> >        isdnu(76)       -- ISDN 'U' (aka 'Two-wire Basic Access Interface')
> >        lapd(77)        -- ISDN D channel Data Link Layer (LAPD)
> > 
> 
> OK, will update
> 
> > 13. The rows for ifType values, basicISDN(20) and primaryISDN(21) are
> > incorrect.  These ifType values are (implicitly) obsoleted by 
> > RFC 2127, because it says:
> >                                           ...  The ifType for physical
> >    interfaces is the matching IANA ifType, usually ds1(18) for Primary
> >    Rate interfaces or isdns(75)/isdnu(76) for Basic Rate interfaces.
> > 
> 
> Well, rfc2127 talks about a lot of ifTypes!!!
> It DOES assign transmission.20 to the ISDN-MIB
> So it seems we need to figure out how to represent that.
> I need to run now... 
> 
> Sending this for now... Will do more follow up later.
> A response to the above would be good for n w.

Bye for now :-).

Keith.

> Bert
> 
> > 14. RFCs 1382 and 2127 are references for:
> > 
> >         x25ple(40)      -- X.25 Packet Level Entity
> > 
> > 15. Both RFCs 2494 and 2127 are references for:
> > 
> >         ds0(81)        -- Digital Signal Level 0
> > 
> > 16. The references for ip(126) are RFCs 2353, 2455 and 2584.
> > 
> > 17. RFC 2662 is the reference for each of these:
> > 
> >        adsl(94)               -- Asymmetric Digital Subscriber Loop
> >        adslInterleave(124)    -- ADSL Interleaved Channel
> >        adslFast(125)          -- ADSL Fast Channel
> > 
> > RFC 3440 is another reference for adsl(94).
> > RFC 3728 is another reference for adslInterleave(124) and 
> > adslFast(125).
> > 
> > 18. It is unnecessarily premature to list an I-D for
> > docsCableMaclayer(127).
> > Instead, RFC 2670 is the reference for:
> > 
> >         docsCableMaclayer(127)     -- CATV MAC Layer
> >         docsCableDownstream(128)   -- CATV Downstream interface
> >         docsCableUpstream(129)     -- CATV Upstream interface
> > 
> > 19. The reference for:
> > 
> >         aflane8023(59)     -- ATM Emulated LAN for 802.3
> >         aflane8025(60)     -- ATM Emulated LAN for 802.5
> > 
> > is:
> >     "LAN Emulation Over ATM, Version 1.0", af-lane0021.000,
> >     ATM Forum, Jan 1995.
> > 
> > 20. RFC 3020 is the reference for:
> > 
> >        frf16MfrBundle(163)    -- FRF .16 Multilink Frame Relay 
> > 
> > 21. RFC 3201 is the reference for:
> > 
> >         frDlciEndPt(193)      -- Frame Relay DLCI End Point
> >         atmVciEndPt(194)      -- ATM VCI End Point
> > 
> > 22. RFC 4319 is the reference for:
> > 
> >         hdsl2(168)            -- High Bit-Rate DSL, 2nd generation
> >         shdsl(169)            -- Multirate HDSL2
> > 
> > 23. RFCs 1990 and 3371 are partial references for:
> > 
> >         pppMultilinkBundle(108)    -- PPP Multilink Bundle
> > 
> > 24. RFC 3591 is the reference for:
> > 
> >      opticalChannel(195)  --  Optical Transport Network (OTN) Optical
> > Channel
> >      opticalTransport(196) -- Optical Transport Network (OTN) Optical
> >                            -- Transmission Section/Optical Multiplex
> > Section 
> >      opticalChannelGroup(219) -- Optical Transport Network 
> > (OTN) Optical
> >                               -- Channel Group
> > 
> > 25. RFC 3606 is the reference for:
> > 
> >         atmLogical(80)     -- ATM Logical Port
> > 
> > 26. RFC 3635 specifies that fastEther(62), fastEtherFX(69) and
> > gigabitEthernet(117) are obsolete.
> > 
> > 27. RFC 3812 is a reference for mpls(166) and mplsTunnel(150).
> > RFCs 3811 and 3813 are also references for mpls(166).
> > 
> > 28. RFCs 3728, 4069 and 4070 are references for vdsl(97).
> > 
> > 29. RFC 4044 is the reference for fcipLink(224).
> > 
> > 30. The row for ifType=230 is incorrect.  The reference for adsl2(230)
> > is draft-ietf-adslmib-adsl2-07.txt
> > 
> > 31. The rows for these ifType values have the wrong reference (I don't
> > know the correct reference):
> > 
> >         47, 95, 146, 228, 229
> > 
> > 32. The reference for ocsCableUpstreamChannel(205) is
> > draft-ietf-ipcdn-docs-rfmibv2-14.txt
> > 
> > 33. Presumably, RFC 1483 is the reference for:
> > 
> >            rfc1483(159)         -- Multiprotocol over ATM AAL5
> > 
> > 34. The row for ifType=48 is incorrect.  RFC 4319 is not for 
> > a "generic
> > modem".
> > 
> > 25. RFC 2320 is a reference for ipOverAtm(114).
> > 
> > 
> 

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

---

From: John Flick <[email-masked]>
Date: Tue, 01 Aug 2006 14:44:19 -0700

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.
> 
>   Decimal   Name          Description                     References
>   -------   ----          -----------                     ----------
>   ...
> 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]
>

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 2 Aug 2006 10:27:14 -0700 (PDT)

> Keith and others. Thanks for all the input sofar.
> 
> We need consistency and make a decision. 
> We found the following (sofar):
> 
>   label(value()    where:
>   ---------------- --------------------------------
>   rfc877x25(5)     http://www.iana.org/assignments/ianaiftype-mib 
>   rfc877-x25(5)    RFC1213
>   rfc887-x25(5)    RFC1392
>   rfc877x25(5)     RFC1573 (the initial IANAifType-MIB)
>   x25(5)           RFC1700
> 
> I understand that RFC 1700 has been obsoleted. 
> So maybe we need/should not worry about that.
> 
> It seems that the original label was rfc877-x25. I guess we (IETF IFMIB WG)
> changed it to comply with the CLR "no hyphens in a label" ??
 
Ok by me.

> In any event, I am inclined to put in our table:
>                
>     http://www.ops.ietf.org/IfTypeReferences02.html     
 
You have two typos (three if one counts "Pls") in the intro text:

   Thanks to Dave Thaler for providing the first cut. MIB doctors, Pls
   check for correctness. This should also align with the
   'ANAifType-MIB. If it does not, then the IANA registry us the
   authoritative source.

> (and comments about this new format is welcome too.
>  I am using cml2rfc with texttable element, which looks as follows:
>   <texttable anchor='table_IfTypeReferences'>
>     <ttcol align='left'>label</ttcol>
>     <ttcol align='center'>ifType</ttcol>
>     <ttcol align='left'>MIB oid</ttcol>
>     <ttcol align='center'>Reference</ttcol>
>     <ttcol align='center'>MIB module</ttcol>
>     <ttcol align='left'>(IANA) comments</ttcol>
> 
>       <!--label-->     <c>other</c>
>       <!--ifType-->    <c>1</c>
>       <!--MIBoid-->    <c>n.a.</c>
>       <!--Reference--> <c><xref target='RFC1213'/></c>
>       <!--MIBmodule--> <c>n.a.</c>
>       <!--comment-->   <c>none of the following</c>
 
It seems to be that "MIB oid" and "MIB module" are inter-dependent columns
and would be better as adjacent columns. 

Also, I think "none known" would be more informative than "?" in the
"MIB module" column for the xxx1822 rows.

>  I find that much easier to maintain than the format I received from
>  Dave Thaler... not complaining Dave. Your format seemed impossible
>  to maintain manually, but I am sure you have/had nice tools)
> 
> The MIB module is (as per RFC1382):
>   x25(transmission.5)  http://www.iana.org/assignments/smi-numbers 
>           under: Prefix: iso.org.dod.internet.mgmt.mib-2.transmission   
> 
> If I understand RFC1382 correctly, then that MIB module is also used
> for ddn-x25(4), as per sect 3.3 of RFC1382. 
> 
>    3.3.  Structure of MIB
> 
>    Instances of the objects defined below represent attributes of an
>    X.25 Packet Layer interface.  At present these interfaces are
>    identified by an ifType object in the Internet-standard MIB-II [5]
>    of:
> 
>                  ddn-x25(4), and
>                  rfc887-x25(5).
> 
>    For these interfaces, the value of the ifSpecific variable in the
>    MIB-II [5] has the OBJECT IDENTIFIER value:
> 
>                  x25    OBJECT IDENTIFIER ::= { transmission 5 }
> 
> Note that also for ddn-x25, we have changed it to ddnX25 in the IANAifType-MIB
> since RFC1573! So I am also using the ddnX25 in our table.

OK.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 3 Aug 2006 05:25:06 -0700 (PDT)

> So the one thing we can still wonder is:
> 
>    should we record errata against the RFCs in error. 
>    Not that it matters that much probably, but it does record that
>    we have seen these and that there is (consensus, at least in MIB
>    doctors land) as to what the correct values are.
 
It would be beneficial if you have the time to do so. 

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 3 Aug 2006 08:31:05 -0700 (PDT)

> Time is always a problem. But I will try.
> FOr each errata mesage I will give MIB doctors a few days to
> comment on my draft text to RFC-Editor.
> 
> So I will not send any for obsoleted or historic RFCs.
> 
>   RFC1382 is PS, so I will prepare an errata message
>   RFC1700 is historic, so no errata
> 
>   RFC1213 is STD and updated by (2011, 2012, 2013).
>           I guess we could ask to add that it is also updated
>           by RFC1573 (for iftable) and by RFC3418 (for the snmp
>           branch)
> 
> Maybe we could ask to update the index for some RFCs
> 
> OLD:
>   1213 Management Information Base for Network Management of
>      TCP/IP-based internets:MIB-II. K. McCloghrie, M. Rose. March 1991.
>      (Format: TXT=142158 bytes) (Obsoletes RFC1158) (Updated by RFC2011,
>      RFC2012, RFC2013) (Also STD0017) (Status: STANDARD)
> 
> NEW:
>   1213 Management Information Base for Network Management of
>      TCP/IP-based internets:MIB-II. K. McCloghrie, M. Rose. March 1991.
>      (Format: TXT=142158 bytes) (Obsoletes RFC1158) (Updated by RFC2011,
>      RFC2012, RFC2013, rfc1573, rfc3418) (Also STD0017) (Status: STANDARD)
 
RFC 1354 says:

   It is proposed that the ipRouteTable defined by MIB-II (RFC 1213) be
   deprecated and replaced with this table. 

and 1354->2096->4292.  Also: 1450->1907->3418 and 1573->2233->2863.

Since the Index presently has 2011, 2012, 2013, it should probably be:

   Updated by RFC1354, RFC1450, RFC1573, RFC2011, RFC2012, RFC2013.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 4 Aug 2006 07:39:45 -0700 (PDT)

I agree that it's not worth trying to get it all sorted out.  Since you
have spent some time on it, you might want to put an "*" on the entries in
your table which depend on/point to inconsistent information, with a
footnote saying something like:

   The reference(s) for this information are inconsistent and/or
   contain suspect data.  If and when the correct information can be
   determined with 100% accuracy, then appropriate RFC errata should be
   generated for them.

Keith.

> Keith responded:
> mmm RFc1461 seems to claim (in my reading) that the ifType is not miox25
> but either ddnX25 or rfc877x25 (well actually it says ddn-x25 or rfc877-x25):
> 
>    3.2.  Structure of MIB objects
> 
>    The objects of this MIB are organized into three tables:  the
>    mioxPleTable, the mioxPeerTable, and the mioxPeerEncTable.  All
>    objects in all tables are mandatory for conformance with this MIB.
> 
>    The mioxPleTable defines information relative to an interface used to
>    carry Multiprotocol Interconnect traffic over X.25.  Such interfaces
>    are identified by an ifType object in the Internet-standard MIB [4]
>    of ddn-x25 or rfc877-x25.  Interfaces of type ddn-x25 have a self
>    contained algorithm for translating between IP addresses and X.121
>    addresses.  Interfaces of type rfc877-x25 do not have such an
>    algorithm.  Note that not all X.25 Interfaces will be used to carry
>    Multiprotocol Interconnect traffic. Those interfaces not carrying
>    such traffic will not have entries in the mioxPleTable.  The entries
>    in the mioxPleTable are only for interfaces that do carry
>    Multiprotocol Interconnect traffic over X.25.  Entries in the
>    mioxPleTable are indexed by ifIndex to make it easy to find the
>    mioxPleTable entry for an interface.
> 
>    The mioxPeerTable contains information needed to contact an X.25 Peer
>    to exchange packets.  This includes information such as the X.121
>    address of the peer and a pointer to the X.25 call parameters needed
>    to place the call.  The instance identifiers used for the objects in
>    this table are independent of any interface or other tables defined
>    outside this MIB.  This table contains the ifIndex value of the X.25
>    interface to use to call a peer.
> 
>    The mioxPeerEncTable contains information about the encapsulation
>    type used to communicate with a peer.  This table is an extension of
>    the mioxPeerTable in its instance identification. Each entry in the
>    mioxPeerTable may have zero or more entries in this table.  This
>    table will not have any entries that do not have correspondent
>    entries in mioxPeerTable.
> 
> The MIB however is MIOX25-MIB and it also requires the RFC1382-MIB
> But do we want to list both MIB modules for the miox25 entry in our
> references? In that case we probably also need to include IF-MIB, because
> that one is also needed ... ? So I am inclined to have an entry that
> says
> 
>       <!--label-->     <c>miox25</c>
>       <!--ifType-->    <c>38</c>
>       <!--MIBoid-->    <c>transmission.38</c>
>       <!--MIBmodule--> <c>MIOX25-MIB</c>
>       <!--Reference--> <c><xref target='RFCR1461'/></c>
>       <!--comment-->   <c>Multiprotocol Interconnect over X.25</c>
> 
> If we feel it helps, I could change the comment to:
> 
>       <!--comment-->   <c>Multiprotocol Interconnect over X.25
>                           Also requires RFC1382-MIB as per
>                           <xref target='RFCR1461'/>
>                        </c>
> 
> >   x25ple(40)  -- RFC 1382
> > 
> 
> Pretty strange stuff (from before I was looking at content of MIB documents)
> Here what I see in RFC2127:
> 
>    3.4.4.  X.25 based packet-mode service in B and D channels
> 
>    X.25 based packet mode service over B channels can be handled using
>    the Dial Control MIB by creating an appropriate peer entry.  The peer
>    entry ifType can then be x25(5), thus providing access to X.25
>    service.
>    X.25 based packet mode service over D channels can be handled by
>    creating an ifEndpointTable entry with an isdnEndpointIfType of
>    x25ple(40).  The upper protocol layers can then be attached to this
>    interface using the ifStack table.
> 
> So it talks about ifType x25(5) !!?? which should read: rfc877X25
> (another erratum!?) In that case, I guess the RFC1382-MIB must be
> implemented as well?
> 
> For x25ple(40), I am not sure where/if ifEndpointTable exists!??
> Do they mean the isdnEndpointTable which is included in the ISDN-MIB
> in RFC2127? (I.e. another erratum !?)
> 
> Looking at the isdnEndpointTable, it seems they are saying:
> 
>   - the ifType in the ifTable is rfc877X25
>   - the ifType in the isdnEndpointTable is x25ple
> 
> Did I interpret that correctly?
> Possibly the ifType in ifTable can also be ddnX25 ??
> 
> By the way, RFC2127 (the only place where I could find the string x25ple)
> does not even reference RFC1382.
> 
> SO I am inclined to put this in the table:
> 
>       <!--label-->     <c>x25ple</c>
>       <!--ifType-->    <c>40</c>
>       <!--MIBoid-->    <c>transmission.20</c>
>       <!--MIBmodule--> <c>ISDN-MIB</c>
>       <!--Reference--> <c><xref target='RFCR2127'/></c>
>       <!--comment-->   <c>Terminal Endpoint for X.25 based packet mode services.
>                          <vspace blankLines='0' />
>                           Also requires RFC1382-MIB as per
>                           <xref target='RFCR2127'/>
>                        </c>
> 
> 
> 
> Wow... to get this all sorted out seems much more work then I thought 
> Is it worth it?
> 
> > and perhaps also for:
> > 
> >   x25mlp(121)
> >   x25huntGroup(122)
> > 
> 
> Any idea where I can get more info?
> I can't find these strings in any MIB module nor in any RFC.
> Trying to find details via Google has not resulted in any help yet.
> Too many hits...
> 
> This is what I have recorded for now:
> 
>       <!--label-->     <c>x25mlp</c>
>       <!--ifType-->    <c>121</c>
>       <!--MIBoid-->    <c>none known</c>
>       <!--MIBmodule--> <c>none known</c>
>       <!--Reference--> <c>none known</c>
>       <!--comment-->   <c>Multi-Link Protocol</c>
> 
>       <!--label-->     <c>x25huntGroup</c>
>       <!--ifType-->    <c>122</c>
>       <!--MIBoid-->    <c>none known</c>
>       <!--MIBmodule--> <c>none known</c>
>       <!--Reference--> <c>none known</c>
>       <!--comment-->   <c>X25 Hunt Group</c>
> 
> Bert
>

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 4 Aug 2006 14:18:34 -0700 (PDT)

I think "maintenance in the future" is the key factor -- not only is it
extra work, but also the best case is likely to be that such extra work gets
done at regular intervals, and within the intervals, the references are
inconsistent (some will include the most recent; others will not).

Keith.
 
> Interesting and strange stuff that I am finding.
> 
> Keith answered:
> So I have for coffee:
>       <!--label-->     <c>coffee</c>
>       <!--ifType-->    <c>132</c>
>       <!--MIBoid-->    <c>transmission 132</c>
>       <!--MIBmodule--> <c>COFFEE-POT-MIB</c>
>       <!--Reference--> <c><xref target='RFC2325'/></c>
>       <!--comment-->   <c>April 1st RFC
>                          <vspace blanklines='0' />
>                           It does mention ifType sip(31) too.
>                        </c>
> 
> So that one does list sip(31), but I think that was a joke
> (e.g. take a sip of coffee).
> 
> The sip(31) SMDS documents (RFC1304 and RFC1694) do not contain the word
> coffee or Coffee. So I'd suggest to the iana to remove coffee from sip(31)
> comment. 
> 
> For sip(31) I now have:
> 
>       <!--label-->     <c>sip</c>
>       <!--ifType-->    <c>31</c>
>       <!--MIBoid-->    <c>mib2.36</c>
>       <!--MIBmodule--> <c>SIP-MIB</c>
>       <!--Reference--> <c><xref target='RFC1694'/> (DS)</c>
>       <!--comment-->   <c>SMDS
>                          <vspace blanklines='0' />
>                           initial: RFC1304-MIB <xref target='RFC1304'/>
>                          <vspace blanklines='0' />
>                           obsoleted by: SIP-MIB <xref target='RFC1407'/> (PS)
>                          <vspace blanklines='0' />
>                           sip OBJECT IDENTIFIER ::= { transmission 31 }
>                        </c>
> 
> 
> Do people think that the it is handy/useful to:
> - have the reference to the most current RFC 
> - include the status (PS, DS...)
> - list the obsoleted RFCs as well
> - add the OID for "sip" (last line) ??
> 
> The reason I ask is that, now that I am going through all this in detail, it is
> easy to add. Problem might be: maintenance in the future.
> 
> I wondered about this when I also composed the data for ds3(30):
> 
>      <!--label-->     <c>ds3</c>
>      <!--ifType-->    <c>30</c>
>      <!--MIBoid-->    <c>transmission.30</c>
>      <!--MIBmodule--> <c>DS3-MIB</c>
>      <!--Reference--> <c><xref target='RFC3896'/> (PS)</c>
>      <!--comment-->   <c>DS3/E3 MIB
>                         <vspace blanklines='0' />
>                          experimental: RFC1288-MIB <xref target='RFC1288'/>
>                         <vspace blanklines='0' />
>                          obsoleted by: RFC1407-MIB <xref target='RFC1407'/>
>                         <vspace blanklines='0' />
>                          obsoleted by: DS3-MIB <xref target='RFC2496'/>
>                         <vspace blanklines='0' />
>                          obsoleted by: DS3-MIB <xref target='RFC3896'/> (PS)
>                         <vspace blanklines='0' />
>                          ds3 MODULE-IDENTITY ::= { transmission 30 }
>                       </c>
> 
> Oh well, comments always welcome.
> 
> The more I poke into this, the more I see that it is a big hodge podge of
> approaches. And I wonder how a NMS can make sense out of it.
> 
> Bert
>

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 4 Aug 2006 14:19:11 -0700 (PDT)

Looks OK to me.
 
Keith.

> 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 
> 
> the row that says:
> 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,
> > 
> > > 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 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)
> > > X-Authentication-Warning: hprnljf.rose.hp.com: Host 
> > johnf@localhost [127.0.0.1] didn't use HELO protocol
> > > To: [email-masked]

---

From: John Flick <[email-masked]>
Date: Fri, 04 Aug 2006 14:20:59 -0700

Me too.

John

---

From: Keith McCloghrie <[email-masked]>
Date: Sat, 5 Aug 2006 04:59:00 -0700 (PDT)

OK.

Keith.

> Keith answers:
> > Why 1662 ??  The best references for ifType=ieee1394(144) 
> > would seem to be RFCs 2734 & 3146.
> 
> Not sure how I got to 1662 either. Makes no sense indeed.
> I am also not sure about 2734 and 3146. They don;t speak
> about the ifType at all. They also have no MIB module.
> 
> So I guess I'll do:
> 
>      <!--label-->     <c>ieee1394</c>
>      <!--ifType-->    <c>144</c>
>      <!--comment-->   <c>IEEE Std 1394-1995, Standard for a High Performance Serial Bus</c>
> 
> Bert
>

---

From: Keith McCloghrie <[email-masked]>
Date: Sat, 5 Aug 2006 05:13:14 -0700 (PDT)

> > > > 8. The row for ifType=46 is incorrect.  RFC 2320 is not a reference for
> I found:
>   http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/hssi.htm
> 
> So is it a Cisco proprietary protocol? 

I know no more than that webpage says, but I don't think it matters.

> Is there a cisco rporpietary MIB for it?
 
I can find two types of references to HSSI in Cisco MIBs.:

1) a few of the enumerated values for a "type of line card" object;
   this object was in a table INDEX-ed by a clone of ifIndex.  These
   would have had ifType=hssi(46).  There is no MIB specific to these
   line cards.
2) a MIB, defined by a company later acquired by Cisco, which has no
   mention of anything to do with the ifTable, and which defines its
   own objects for things like line speed.  I doubt these ever had
   ifTable entries, and so I don't think you should reference this MIB.

> I guess I could point to above web page, no?
 
I guess.
 
Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Sat, 5 Aug 2006 05:20:11 -0700 (PDT)

If you think IANA might be concerned with "implicitly obsoleted", I suggest
using the phrase "no longer used" which effectively means the same thing
without any implication of usurping IANA's authority.

Keith.

> I have done the above as follows:
> 
> 
>       <!--label-->     <c>isdn</c>
>       <!--ifType-->    <c>63</c>
>       <!--Reference--> <c><xref target='RFC2127'/> (PS)
>                           <xref target='RFC2128'/> (PS)
>                        </c>
>       <!--comment-->   <c>Terminal Endpoint for ISDN signaling channels.
>                           IANAifType-MIB comment: ISDN and X.25
>                        </c>
> 
>       <!--label-->     <c>isdns</c>
>       <!--ifType-->    <c>75</c>
>       <!--Reference--> <c><xref target='RFC2127'/> (PS)</c>
>       <!--comment-->   <c>ISDN 'S/T' (aka 'Four-wire Basic Access Interface')</c>   
> 
>       <!--label-->     <c>isdnu</c>
>       <!--ifType-->    <c>76</c>
>       <!--Reference--> <c><xref target='RFC2127'/> (PS)</c>
>       <!--comment-->   <c>ISDN 'U' (aka 'Two-wire Basic Access Interface')</c>
> 
>       <!--label-->     <c>lapd</c>
>       <!--ifType-->    <c>77</c>
>       <!--Reference--> <c><xref target='RFC2127'/> (PS)</c>
>       <!--comment-->   <c>ISDN D channel Data Link Layer (LAPD) </c>
> 
> I also noted in 2127:
>   -- For primary rate, the media specifics are defined in the Trunk
>   -- MIB and the ifType has a value of ds1(18).
> and
>   -- Each B channel is also represented as an entry
>   -- in the ifTable. The B channels have an ifType value
>   -- of ds0(81).
> 
> So... seems we ought to inform IANA about that too. 
> Not sure they will easily accept "implicitly obsoleted".
> Anyway, can we (MIB-Doctors) agree with:
> 
>       <!--label-->     <c>basicISDN</c>
>       <!--ifType-->    <c>20</c>
>       <!--comment-->   <c>(implicitly) obsoleted by <xref target='RFC2127'/></c>
> 
>       <!--label-->     <c>primaryISDN</c>
>       <!--ifType-->    <c>21</c>
>       <!--comment-->   <c>(implicitly) obsoleted by <xref target='RFC2127'/></c>
> 
> So I also now have:
>       <!--label-->     <c>ds1</c>
>       <!--ifType-->    <c>18</c>
>       <!--MIBoid-->    <c>transmission.18</c>
>       <!--MIBmodule--> <c>DS1-MIB</c>
>       <!--Reference--> <c><xref target='RFC3895'/> (PS)</c>
>       <!--comment-->   <c>
>                          <vspace blanklines='0'/>
>                           Initial: <xref target='RFC1403'/> (PS)
>                          <vspace blanklines='0'/>
>                           obsoleted by: <xref target='RFC2495'/> (PS)
>                          <vspace blanklines='0'/>
>                           obsoleted by: <xref target='RFC3895'/> (PS)
>                        </c>
> 
>       <!--label-->     <c>e1</c>
>       <!--ifType-->    <c>19</c>
>       <!--MIBoid-->    <c>transmission.18</c>
>       <!--MIBmodule--> <c>RFC1406-MIB</c>
>       <!--Reference--> <c><xref target='RFC1407> (PS)</c>
>       <!--comment-->   <c>Obsoleted see DS1-MIB in <xref target='RFC2495'/></c>
> 
>       <!--label-->     <c>ds0</c>
>       <!--ifType-->    <c>81</c>
>       <!--MIBoid-->    <c>transmission.81</c>
>       <!--MIBmodule--> <c>DS0-MIB</c>
>       <!--Reference--> <c><xref target='RFC2494'/> (PS)</c>
>       <!--comment-->   <c>Digital Signal Level 0</c>
> 
>       <!--label-->     <c>ds0Bundle</c>
>       <!--ifType-->    <c>82</c>
>       <!--MIBoid-->    <c>transmission.82</c>
>       <!--MIBmodule--> <c>DS0BUNDLE-MIB</c>
>       <!--Reference--> <c><xref target='RFC2494'/> (PS)</c>
>       <!--comment-->   <c>group of ds0s on the same ds1</c>
> 
> Hope I have figured out rfc2127 (and some related stuff) now.
> 
> 
> Anyway, comments and review, again are welcome.
> 
> Bert
>

---

From: Keith McCloghrie <[email-masked]>
Date: Sat, 5 Aug 2006 05:43:43 -0700 (PDT)

>       <!--label-->     <c>aal5</c>
>       <!--ifType-->    <c>49</c>
>       <!--MIBoid-->    <c>mib-2.37</c>
>       <!--MIBmodule--> <c>ATM-MIB</c>
>       <!--Reference--> <c><xref target='RFC2515'/> (PS)</c>
>       <!--comment-->   <c>ATM AAL5 layer
>                          <vspace blanklines='0'/>
>                           transmission.49 has been assigned to the APS-MIB
>                           in <xref target='RFC3498'/>.
>                           It is for ifType sonet(39). The SONET-MIB
>                           in <xref target='RFC3592'/> also claims to be for
>                           ifType sonet(39).
>                           This is weird, but a fact of life.
>                        </c>
 
The SONET-MIB is a media-specific extension for ifTable rows with
ifType=39.  The APS-MIB intruments the Automatic Protection Switching
mechanism by which some/all of the ifTable rows with ifType=39 can be
grouped together, where a group consists of some lines which are active
and others which are backups in case an active line goes down.

So, I don't think it's weird that they both refer to sonet(39).  The thing 
which is weird is that they don't refer to each other.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Sat, 5 Aug 2006 05:49:17 -0700 (PDT)

> I have changed the entry to:
> 
>       <!--label-->     <c>propVirtual</c>
>       <!--ifType-->    <c>53</c>
>       <!--comment-->   <c>proprietary virtual/internal
>                          <vspace blanklines='0'/>
>                           RFC-2515 is a reference for some but not all uses of ifType=53.
>                        </c>
> 
> Let me know if more changes are needed.
 
I suggest adding RFC 2613 as a reference for another example usage
of ifType=53.
 
Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 7 Aug 2006 04:48:24 -0700 (PDT)

>   !--label-->     <c>hssi</c>
>   !--ifType-->    <c>46</c>
>   !--MIBoid-->    <c>none known</c> 
>   !--MIBmodule--> ><c>none known</c>
>   !--Reference--> <c><eref target='http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/hssi.htm>
>                    Cisco HSSI?</eref>.
>                   </c>
>   !--comment-->   <c>High Speed Serial Interface
>                      We do not know of any standards-based use of this ifType.
>                   </c>
 
To be picky, I believe that an ifTable row with ifType=46 qualifies as
a "standards-based use of this ifType", i.e., that the reference #1 that
I listed (below) is/was a "standards-based use of this ifType", because
it did have an ifTable row with ifType=46 (sorry if I didn't make that
clear before).  I think what you're trying to say is:

     "No known media-specific (extension) MIB for this ifType value."

But I don't see why you need to add this as a comment because it means
the same as:
 
    !--MIBmodule--> ><c>none known</c>

and if it's needed as a comment for ifType=46, then it's probably needed
as a comment for many other ifType values.  So, I would just delete it.

[Note: I put "(extension)" in parenthesis as a means to try to refer to
both RFC-2863/section 4's term: "media-specific MIB", and to make it clear
that it's reference to a MIB extending the ifTable.]

Keith.

> Unless I hear other updates/suggestions, that is what it will be.
> 
> Bert
> > From: Keith McCloghrie [mailto:[email-masked]]
> > Sent: Saturday, August 05, 2006 14:13
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: IfTypeReferences - iftype=46 - hssi
> > 
> > 
> >