RE: partial comments on section 5 of ibif

Randy, (let me take my WG Chair hat off)

I don't want to disagree with your opinion of many of the interesting
objects that are giving us fits (multicast packet counting)

Let me try to change specification and implementation issues - we should
specify multicast packets in/out whatever.  Then it is up to the
implementation to provide a value for the counter - not implement the
object (NO SUCH INSTANCE, NO SUCH OBJECT for V1) or return 0 - on an
implementation decision.  I realize the IETF does not specify
implementations, or provide conformance testing (This implementations
fully supports RFC X)

Your objections are that we are specifying implementation behavior,
rather than what an ideal specification.  It is then up to the
implementations to implement these counters in some way

Bill
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Randy Presuhn
Sent: Thursday, October 09, 2003 9:46 PM
To: [email protected]
Cc: 'Bert Wijnen'
Subject: Re: [Ipoverib] 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 9:15 PM
> Subject: Re: [Ipoverib] partial comments on section 5 of ibif
...
> The "correct" behavior for those counters in the context of IB would 
> be to be set to 0. Looking at the ibif draft some more, I think that 
> would be the right choice as the draft specifies that the
> mcast and unicast packets are counted in the unicast counters as is
done in IB.
...

That's another problem; thanks for catching it.

We're going in circles here.  I've done my job by informing the WG that
I believe that what's in the ibif -05- i-d isn't going to fly.  You can
try to find someone else to review it, but I'm confident that any other
MIB reviewer will tell you just what I've told you: instantiating a
counter from RFC 2863 and not adhering to the semantics of that object
definition simply isn't an option.  The references in a document to the
various objects in the interfaces MIB are supposed to *elaborate* on
what they mean in the context of a particular interface type, not
contradict them.

Randy



_______________________________________________
IPoverIB mailing list
[email protected] https://www1.ietf.org/mailman/listinfo/ipoverib