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

Keith McCloghrie <kzm@cisco.com> Tue, 01 August 2006 18:37 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7z7W-0003Xf-7f; Tue, 01 Aug 2006 14:37:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xqY-000812-VU for mib-doctors@ietf.org; Tue, 01 Aug 2006 13:15:58 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7xqW-0004IL-1W for mib-doctors@ietf.org; Tue, 01 Aug 2006 13:15:58 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Aug 2006 10:15:55 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k71HFsN2001507; Tue, 1 Aug 2006 10:15:54 -0700
Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k71HFsJi024846; Tue, 1 Aug 2006 10:15:54 -0700 (PDT)
Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA25591; Tue, 1 Aug 2006 10:15:02 -0700 (PDT)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200608011715.KAA25591@cisco.com>
To: bwijnen@lucent.com
Date: Tue, 01 Aug 2006 10:15:02 -0700
In-Reply-To: <no.id> from "Wijnen, Bert (Bert)" at Aug 01, 2006 02:06:24 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=13205; t=1154452554; x=1155316554; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kzm@cisco.com; z=From:Keith=20McCloghrie=20<kzm@cisco.com> |Subject:Re=3A=20Last=20Call=20for=20the=20ifType=20References=20table=20(was=3A= 20RE=3A=20IfType=20re; X=v=3Dcisco.com=3B=20h=3DnEzoDwfQ7MjVH5zZ7OLLB6cE5+U=3D; b=uDydUB5uYT1R0o/Fs4QqneHgHUelfWUJrZTbkRyNdtReENedwXnyE2YQUgjkFt9d3Og989gF WAwVhTah/7tBOtPeTCFrIJS3vnFKfNMKOmwZf4tAoSMbW37eu7uwQ6yO;
Authentication-Results: sj-dkim-3.cisco.com; header.From=kzm@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86
X-Mailman-Approved-At: Tue, 01 Aug 2006 14:37:32 -0400
Cc: Keith McCloghrie <kzm@cisco.com>, mib-doctors@ietf.org
Subject: [MIB-DOCTORS] Re: Last Call for the ifType References table (was: RE: IfType re
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mib-doctors>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
Errors-To: mib-doctors-bounces@ietf.org

> 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
MIB-DOCTORS@ietf.org
https://www1.ietf.org/mailman/listinfo/mib-doctors