Re: partial comments on section 5 of ibif

Hi -

> From: "Vandana Rao" <[email protected]>
> To: "Randy Presuhn" <[email protected]>; <[email protected]>
> Cc: "'Bert Wijnen'" <[email protected]>
> Sent: Thursday, October 09, 2003 12:17 PM
> Subject: Re: [Ipoverib] partial comments on section 5 of ibif
...
> >If by "left as defined" you mean what's in RFC 2863, I agree.
> >If you mean what's in draft-ietf-ipoib-ibif-mib-05.txt, then I disagree.
>
> I meant left as defined in draft-ietf-ipoib-ibif-mib-05.txt.
>
> >If multicast is defined for this interface type, it seems  clear
> >that ifInMulticastPkts must be incremented each time such
> >a packet is delivered to a higher sub-layer.  Same reasoning
> >goes for the Out and HC counters.
>
> Since IBTA did not define counters for multicast, it is not possible to
> provide this data always in ifInMulticastPkts, and as the ibif draft

I don't understand the logic here.  If system processes multicast packets,
it certainly should know that it is doing so.  Whether the IBTA defined such a
counter is irrelevant, as far as I can see.  What am I missing?

> suggested, this counter should be set to 0. If a device vendor provides a
> proprietary (non-IBTA standard) counter for multicast, it should be
> reflected in ifInMulticastPkts.

The behaviour of a standard object such as ifInMulticastPkts shouldn't
vary from vendor to vendor.  If vendor claims they're implementing
the interfaces MIB and instantiates this object, but doesn't count
multicast, that vendor is lying, both in the advertising and the
implementation.  I can't condone language in the ibif i-d to let them
off the hook.

> This is why I suggested that what is defined currently is right.

I simply am not able to read 2863 in a way that would support such
a practice, and, as a MIB reviewer, believe that defining a counter
that may or may not count a meaningful protocol event, depending
on which chipset was used, is contrary to the whole point of writing
a MIB module in the first place.

> > >   as it is possible for implementations to provide proprietary counters
> > > which count multicast packets.
> >...
> >
> >Putting this information in a vendor-specific MIB, and mandating an
> >incorrect implementation of the IF-MIB standard, would seem to me
> >to be the worst possible solution.
>
> This was not what I said above. I said that if the device vendor provides a
> proprietary (non-IBTA standard) mechanism for the IF-MIB implementor (it is
> possible that these are different entities) to obtain the multicast
> specific counters, then it should be reflected in ifInMulticastPkts.
...

I misunderstood what you (and the document)  meant by "proprietary counters".

The document should not be talking about implementation decisions at that
level.   Whether a counter is implemented in hardware, firmware, software,
or some combination is not normally relevant to the MIB definition.  It
may be helpful, in *non-normative text* to provide implementation hints
that would alert a developer to IBTA-defined interfaces which can provide
the basis for a (sub-)agent to maintain the values for various objects, or
via REFERENCE clauses as a source of further information.

Randy