Subject: Reasons why we need better control over IANAifType...

From: sdurham <[email-masked]>
Date: Fri, 12 Jun 1998 13:56:38 -0700

coffee (132),       -- coffee pot

do we really need a coffee pot sublayer in the interfaces mib?

I think it was perkins who brought up an old issue - how we have really
not a clue what some of these ifTypes refer to. Is there any way we can
limit requests to IANA for ifType assigments so that they only come from
the IFMIB working group chair, or some duly appointed stuckees? That way
we can mandate that a descriptor document go along with all ifTypes so
we at least have a reference to whether or not said coffee pot must
support only IfGeneralInformationGroup...

...and now we have not only the problem of determining duplex speeds
from some other mibs, we have to figure out  caf/decaf from someplace
outside the ifmib too...

sandra
ps  digitalPowerline (138), -- IP over Power Lines ??

---

From: Jeff Johnson <[email-masked]>
Date: Fri, 12 Jun 1998 15:30:53 -0700

>do we really need a coffee pot sublayer in the interfaces mib?

Although this enumeration is not specificially mentioned, at least the
assignment of { transmission 132 } to the COFFEE-POT-MIB is in an RFC (RFC
2325) and hence there is at least some accountability.  Others are for
proprietary interfaces.  But I do agree that for non-proprietary interfaces
there needs to be policing and accountabilty mechanisms.

/jeff

---

From: Gary Hanson <[email-masked]>
Date: Fri, 12 Jun 1998 15:44:44 -0700 (PDT)

Hi Sandra,

> do we really need a coffee pot sublayer in the interfaces mib?

Who knows?  It does sound awfully application-specific, although I
would have to read the spec (and its MIB) to be sure.  I'm sure that
at least two people wanted it to be on the list, however, otherwise
the IANA would certainly have rejected the request to add it....

> support only IfGeneralInformationGroup...

This issue DOES arise now and again.  The enumeration seems to be
filled with many interfaces that are likely to be implemented by
relatively small subsets of vendors (perhaps sometimes only by a
single vendor).  I sometimes think that ifType would have been more
useful had it been defined as an OBJECT IDENTIFIER (or better yet,
as an AutomomousType, had that textual convention existed then).
That way, the values would HAVE to be registered via somebody's MIB,
and the struggle would only have been to FIND those MIBs.

As it currently stands, there is no guarantee that a spec or a MIB
exists for interfaces as they are added to the list.  In some cases,
there appear to be duplicates, such as cctEmul(61) and ces(133),
both of which have got to be referring to the same ATM Forum Circuit
Emulation Service interfaces.  If so, there certainly was no need
for such duplication.

Other duplication exists due to vagaries of our implementation
experience, such as the deprecation of e1(19) and g703at2mb(67).  At
least in these cases the MIB shows that they are obsolete.  (Hear,
hear!!)  Supposedly, v35(45) and hssi(46) are also candidates for
being listed as obsolete, since rs232(33) and its RS-232-MIB would
cover them equally well.  However, you might run into implementors,
such as myself, who LIKE to use v35(45) and hssi(46) separately from
rs232(33), because it is more informative.  That, and the existence
of the EtherLike-MIB which explicitly applies to ethernet-csmacd(6),
iso88023-csmacd(7), AND starLan(11) reveals that there are at least
two philosophies of whether multiple interfaces should be allowed to
map to the same MIB: yes and no.

Then there are standard interfaces (e.g., J2) that have thus far not
been represented at all, other than by other(1).  [The hitch for
adding J2 was (believe it or not!), that a MIB would have to be
defined for it.  When I suggested that the ds1(18) and its DS1-MIB
could be used, the DS1-MIB was then summarily edited to explicitly
announce its non-support of J2, even though it had already been
extended to provide support for DS2 and E2.  (I suppose there just
wasn't enough interest in adding J2, apparently....)]

Then there are the interfaces for which the comments appear to be
wrong, such as ipOverAtm(114), shown as "IBM ipOverAtm" when it was 
really intended for optional usage by the IPOA-MIB.  Things like
that ought to be fixed as they are pointed out, although it hasn't
happened yet.

Finally, there are the interfaces for which it is completely unclear
where to look for a MIB, let alone a spec.  Where would you look,
for example, to find out how to manage a channel(70) interface when
it is helpfully defined to be applicable to "channel" interfaces?
Some are more obvious than others, but for many, it would help to
provide (up-to-date) pointers to the relevant specs and/or MIBs.

I would have to assume that someone at the IANA has a record (even
if only on paper) of who requested each of these interfaces.  On the
assumption that many of these people are still alive (in 1998),
maybe it would be possible to contact them and ask them to fill in
some sort of informative questionnaire, from which more complete
info for the enumeration could be filled in (pointers to specs,
MIBs, home addresses/phonenumbers, number of fluid ounces, etc.).

> ps  digitalPowerline (138), -- IP over Power Lines ??

Don't laugh until you've seen the MIB....assuming it exists.

Regards,
Gary