Subject: RE: draft-ietf-hubmib-etherif-mib-05.txt

From: Andrew Smith <[email-masked]>
Date: Wed, 20 May 1998 17:47:59 -0700

John,

<soapbox on>
I think all this stuff about "easier to understand" and "an easy way to
determine" is missing the point. It is not humans but other computers
that have to "understand" MIBs. The MIB is an interface between two
computers: it is much more important to have things defined precisely
than in a human-friendly manner. And as soon as there is more than one
way to report or configure the same information, it gets way more
complex to define precisely the interactions betweren the various
methods.
<soapbox off>

Having said that, I'm all for providing generic interface objects when
they perform exactly the function required, are meaningful for most
interface types and do not just perform some sort of subset of the
functions of a more specific object. In my opinion, a writable
"ifDuplexMode" object in the IF-MIB definitely does not meet these
criteria. A writable object in the Ethernet-MIB may just squeeze in but
I think we'd have to fix up the MAU MIB version to remove the
duplication of function.

Andrew

> -----Original Message-----
> From:	John Flick [SMTP:[email-masked]]
> Sent:	Wednesday, May 20, 1998 5:33 PM
> To:	Andrew Smith
> Cc:	[email-masked]
> Subject:	RE: draft-ietf-hubmib-etherif-mib-05.txt
> 
> Andrew Smith writes:
>  > John,
>  > 
>  > Sounds like you are proposing quite a radical re-write of the MAU
> MIB
>  > here: do you have a proposal?
> 
> I would rather avoid a radical rewrite.  (Brian's suggestions for
> ifMauType and ifMauTypeList were a bit more radical.)  I would think
> my ideal would be adding a read-only duplex-mode object to ifXTable,
> and adding a settable config object, and possibly a cabability object,
> to the Ethernet MIB.  The config object would be an enumeration to
> allow force half-duplex, force full-duplex, or negotiate to either.
> This wouldn't necessarily have to change the MAU MIB, as long as we
> were clear how sets to the MAU MIB objects and the above config object
> 
> interact.  The rationale for having the status object in IF-MIB and
> the config object in the Ethernet MIB is that duplex mode is a pretty
> generic concept, whereas not many media types can change between
> half-duplex and full-duplex on the fly.  A WAN interface would just
> always say full-duplex for its duplex mode.  An interface that has no
> concept of duplex (like propVirtual or softwareLoopback), would report
> 
> "other".
> 
> As a data point, it seems like several vendors have added a duplex
> config object to their private MIBs.  This is easier to understand
> than having to twiddle the ifMauAutoNegCapAdvertised to change duplex
> for auto-negotiating interfaces, but change ifMauDefaultType for
> non-auto-negotiating interfaces or interfaces where auto-negotiation
> has been disabled.
> 
> By the way, I would also like to see something similar for PAUSE -
> i.e. an easy way to determine what mode it is in now, and an easy way
> to turn it off.
> 
> John
> 
>  > 
>  > Andrew
>  > 
>  > > -----Original Message-----
>  > > From:	John Flick [SMTP:[email-masked]]
>  > > Sent:	Wednesday, May 20, 1998 4:01 PM
>  > > To:	Andrew Smith
>  > > Cc:	[email-masked]
>  > > Subject:	RE: draft-ietf-hubmib-etherif-mib-05.txt
>  > > 
>  > > 
>  > > The feedback I have heard from developers, both of apps and
> agents, is
>  > > 
>  > > that they hate the current scheme in the MAU MIB.  I guess I'm
> saying
>  > > that we need to be open to feedback from implementors if we
> expect to
>  > > see apps actually use these MIBs.  Otherwise, we wind up with
> vendors
>  > > continuing to do their management and config thru private MIBs,
> only
>  > > usable by their own apps.
>  > > 
>  > > John

---

From: John Flick <[email-masked]>
Date: Wed, 20 May 1998 18:31:05 -0700 (PDT)

> complex to define precisely the interactions betweren the various

In general, I agree.  However, in this specific case, we are talking
about expecting a management platform that is managing a network with
a mixture of different LAN types and WAN types and everything else
imaginable to know every possible ifType, including ones that haven't
been defined yet, and know whether each is half or full-duplex, or if
it needs to go groveling thru one of 40 different
transmission-specific MIBs to make that determination, and in this
case have to interpret an OID which it may or may not recognize, all
in order to correctly interpret the generic IF-MIB counters.  When we
could very easily return a simple flag to tell the application whether
the interface is half or full-duplex.

Keep in mind that "easier to understand" means that it would be more
likely that an application developer will be able to successfully use
it.  I realize that a MIB is not a user interface.  It is more the
"assembly language" of network management.  But keep in mind that the
typical programmer working on a management app is a GUI expert, not
necessarily an expert in every possible networking technology.  My
guess is that the folks working on OpenView don't really have time to
learn every possible transmission-specific MIB for every possible
ifType just to get their graphs to work.  Not to mention knowing what
to do with an unrecognized ifType, or in the case of Ethernet, an
unrecognized ifMauType.

We can't continue to whine about the lack of multi-vendor
applications using standard MIBs, then not listen to feedback from app 
developers when they tell us we've made their lives too difficult.

 > functions of a more specific object.

I think a duplex flag fits this description, since most kinds of
interfaces have some concept of duplex mode, even if it is fixed.

 > In my opinion, a writable
 > criteria.

Which is why I proposed making ifDuplexMode read-only.

 > A writable object in the Ethernet-MIB may just squeeze in but

I don't like deprecating existing objects unless they are really
broken.  I'm looking for the minimum amount of change to get the
desired functionality.  I'd need to think about how the new settable
object would interact with ifMauDefaultType and
ifMauAutoNegCapAdvertisedBits.  I'd probably rather give up the
settable object than change the MAU MIB objects, as long as I can have 
the read-only IF-MIB object to report the current mode.

John

---

From: "Brian O'Keefe" <[email-masked]>
Date: Thu, 21 May 1998 07:45:16 -0600

> the interface is half or full-duplex.

I also agree with the soap box; but I also agree with John's assessment
here.  Point is, if the semantics of the ifMIB counters differ based on
ifType or some characteristic like duplex mode that isn't even
represented
in the generic ifMIB, then it's nearly impossible to write "generic
interface" applications that work correctly in the scenario John
describes
above.  I know.  I'm wrestingly with this right now.

I probably need to move some of this discussion to the ifMIB WG because
the need for ifDuplexMode is not alone.  With the "expansion" of the
semantics of some ifMIB counters (e.g., ifIn/OutErrors,
ifIn/OutDiscards)
to handle both packet and non-packet oriented interfaces, a lot of the 
old assumptions and mib expressions used to turn the SNMP "assembly
code" 
into actual application (e.g., meaningful graphs) no longer work for 
either byte- or fixed-length oriented interfaces.  Either, further work
is
needed to enable the *same* mib expression to work for both types of
interfaces
(i.e., revise ifIn/OutUCastPkts to be defined for non-packet interfaces
as
the number of transmission units sent/receivedand and allow the
"redundant" 
information); or add a new ifTUType (transmission unit type) object so 
appliations can *generically* determine which interfaces are of what
type, 
and which counters apply and don't apply, and thus determine which
flavor of
the multiple expressions should be used to compute such things as
%Errors.  
My expreience says that the former would be less intrusive and would
better 
enable existing generic interface applications to work with all types of
interface types, both old and new.

> to do with an unrecognized ifType, or in the case of Ethernet, an

I believe, as an application developer, that I need to have some level
of knowledge about the interface types I'm trying to manage.  However,
I certainly cannot become "expert" in every type.  There are 117
different
ifType values currently defined in IANAifType MIB.  Most of which aren't
even referenced or described in any RFCs, let alone interface-specific
MIBs!
When the application is focussing on interface-specific stuff, then more
knowledge is obviously needed; but when dealing with the high level
stuff for 
"generic interfaces", expertise in every interface type or the N
variations
of a given interface type should not be needed to make the application
work
correctly.

> developers when they tell us we've made their lives too difficult.

Thank you!

> Which is why I proposed making ifDuplexMode read-only.

This works for me.  

As far as the standard-track status of RFC 2233, The Interfaces Group
MIB.
I too want to see it move the Draft ASAP (as well as all the if-specific 
MIBs that depend upon it).  One observation... it looks like the Frame 
Relay MIB added new objects when it moved from Proposed (RFC 1315) to 
Draft (RFC 2115); or was this a rare case where the same RFC originally
published as Proposed was advanced to Draft without any document edits
or new RFC publication.  As long as there's two independent
interoperable 
implementation of a revised ifMIB, including ifDuplexMode, why wouldn't 
it be allowed to advance?

> the read-only IF-MIB object to report the current mode.

Ditto... at least w.r.t. John's sentence 1,2 and 4.  I don't have the
expertise to assess sentence 3.

bok