RE: partial comments on section 5 of ibif

At 11:20 PM 10/9/2003 -0700, bill wrote:
>Ok,
>
>Now I REALLY understand what Randy is saying...
>
>I think the answer is that we will specify that we will report 64 bit
>octet/packet counters as is required.  We will also specify the
>multicast counters.
>
>If an implementation is not capable of reporting these values out - the
>implementation can return NOSUCHINSTANCE from snmpv2 and beyond or
>NOSUCHOBJECT for v1.
>
>What are the objections to this - can you please get your objections to
>this by the end of Last Call, or this will be concensus.

As long as we clearly specify that unicast and multicast counters require 
to adhere to the object definitions of RFC 2863
without any exceptions, I'm fine with this. Basically, what we are saying 
here is that for IB implementations all the unicast/multicast counters will 
return  "no support"
-Vandana



>Bill
>
>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On Behalf
>Of Randy Presuhn
>Sent: Thursday, October 09, 2003 11:10 PM
>To: [email protected]
>Subject: Re: [Ipoverib] partial comments on section 5 of ibif
>
>
>Hi -
>
> > From: "bill" <[email protected]>
> > To: "'Randy Presuhn'" <[email protected]>
> > Cc: <[email protected]>
> > Sent: Thursday, October 09, 2003 10:31 PM
> > Subject: RE: [Ipoverib] 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)
>
>so far, I am in total agreement with you.
>
> >                                                  or return 0 - on an
>
>No, returning a constant zero is *NOT* an option.  If multicast can
>happen, then the choice is between implementing a counter that actually
>counts, or not implementing it at all.  A counter that doesn't count the
>events it is supposed to count is a bug, with the unfortunate potential
>of misleading management systems to draw false conclusions about the
>network's operation or performance.
>
> > implementation decision.  I realize the IETF does not specify
> > implementations, or provide conformance testing (This implementations
> > fully supports RFC X)
>
>You're right that we don't do the actual conformance tests. However, we
>*do* define what it means to conform to a MIB module. That's what RFC
>2580  is all about.
>
> > 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
>...
>
>Agreed.  Thanks for restating my point so clearly.
>
>Randy
>
>
>
>_______________________________________________
>IPoverIB mailing list
>[email protected] https://www1.ietf.org/mailman/listinfo/ipoverib
>
>
>
>_______________________________________________
>IPoverIB mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/ipoverib