RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.txt

"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Tue, 27 July 2004 10:31 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03501 for <ipcdn-archive@ietf.org>; Tue, 27 Jul 2004 06:31:34 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpPGl-0004qN-5o for ipcdn-archive@ietf.org; Tue, 27 Jul 2004 06:33:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpPEZ-00007v-JZ; Tue, 27 Jul 2004 06:30:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpPDk-0008Qq-Kf for ipcdn@megatron.ietf.org; Tue, 27 Jul 2004 06:30:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03442 for <ipcdn@ietf.org>; Tue, 27 Jul 2004 06:30:06 -0400 (EDT)
Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpPFL-0004o9-3r for ipcdn@ietf.org; Tue, 27 Jul 2004 06:31:47 -0400
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i6RATZV3008365 for <ipcdn@ietf.org>; Tue, 27 Jul 2004 05:29:36 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <NTS11BVV>; Tue, 27 Jul 2004 12:29:34 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79AAF@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: 'Eduardo Cardona' <e.cardona@CableLabs.com>, ipcdn@ietf.org
Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.txt
Date: Tue, 27 Jul 2004 12:29:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: DOCSIS OSS Majordomo List <docsis-oss@CableLabs.com>
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Sender: ipcdn-bounces@ietf.org
Errors-To: ipcdn-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0

As a follow up to this, there was this comment from me:
> 
> Mmm, in your response I see:
> 
>    "Discontinuities of this counter are indicated by sysUpTime and
>     ifCounterDiscontinuityTime for the associated ifIndex."
> 
> Not sure I understand this.
> Checking with other MIB doctors.
> 
The first thing we found is that it is not so clear what the text means,
but it probably menas the same things as for other IF-MIB related counters,
i.e. (as also used in IF-MIB, RFC2863), it means:

            Discontinuities in the value of this counter can occur at
            re-initialization of the management system, and at other
            times as indicated by the value of
            ifCounterDiscontinuityTime.

And if that is indeed the case, then this new text would be MUCH better.

Now, when you added the text about discontinuities, it also makes it
more visible that one could really question if the use of ZeroBasedCounter32
makes sense and if a regular Counter32 would not be much much better.

Have you read the ZeroBasedCounter32 TC and the text that explains what this
type of counter was meant for?

One comment from another MIB doctor is:
   A ZeroBasedCounter32 in a conceptual row which can experience
   discontinuities as part of its normal operational behaviour
   just seems a bit odd to me. I fail to see what the advantage of
   a ZeroBasedCounter32 in such a situation is.

Another comment (in relation to ifCounterDiscontinuityTime) is that it would
be very good to add some text (somewhere early on in the draft) that points
to RFC2863, page 12, which has some good text about that object. As per
the comment of another MIB Doctor:
  I think it would be extremely helpful to have a discussion what this
  means somewhere in the introductionary text together with a pointer to
  the relevant text in the IF-MIB RFCs (which has some paragraphs about
  this subject that are interesting to know for implementors).

  Looking at the MIB, the question that I have is the interaction of
  discontinuities with these ZeroBasedCounter32 objects. Does a
  discontinuity couse these counters to be reset to zero? The TC says
  that a zero based counter is set to zero(0) on creation and it has
  additional text that the intended usage is in tables where the index
  space is constantly changing. Does this apply here?

Of course you have clarified (but in some prose early on in the draft may
want to re-emphasize) that the ZeroBasedCounter32 only MUST be set to zero
at row creation. But some additional discussion seems usefull.

Bert

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn