Re: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt

Adrian Farrel <Adrian.Farrel@huawei.com> Sat, 29 August 2009 18:55 UTC

Return-Path: <Adrian.Farrel@huawei.com>
X-Original-To: opsawg@core3.amsl.com
Delivered-To: opsawg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9B93A67F4 for <opsawg@core3.amsl.com>; Sat, 29 Aug 2009 11:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.576
X-Spam-Level:
X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_05=-1.11, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+QvjkahJKA9 for <opsawg@core3.amsl.com>; Sat, 29 Aug 2009 11:55:35 -0700 (PDT)
Received: from lhrga03-in.huawei.com (lhrga03-in.huawei.com [195.33.106.148]) by core3.amsl.com (Postfix) with ESMTP id 06FCF3A684C for <opsawg@ietf.org>; Sat, 29 Aug 2009 11:55:35 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP500KARJ8MC0@lhrga03-in.huawei.com> for opsawg@ietf.org; Sat, 29 Aug 2009 19:55:35 +0100 (BST)
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP5002XGJ8KWU@lhrga03-in.huawei.com> for opsawg@ietf.org; Sat, 29 Aug 2009 19:55:34 +0100 (BST)
Date: Sat, 29 Aug 2009 19:55:26 +0100
From: Adrian Farrel <Adrian.Farrel@huawei.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Message-id: <DFC885C9EB3547D685E78308393963F8@your029b8cecfe>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
Content-type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <20090828130615.GA22962@elstar.local> <052e01ca27f0$2a0e6060$0600a8c0@china.huawei.com> <C931F40537DD4D819257BBE94B042035@your029b8cecfe> <20090829184149.GD24348@elstar.local>
X-Mailman-Approved-At: Mon, 31 Aug 2009 01:31:38 -0700
Cc: draft-ietf-opsawg-syslog-msg-mib@tools.ietf.org, opsawg@ietf.org
Subject: Re: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <Adrian.Farrel@huawei.com>
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Aug 2009 18:55:36 -0000

>> 1.
>> > Do entries ever get removed from this table?
>> Not as I understand it. The index is monotonic increasing and wraps at 
>> the
>> maximum value (defined as the lesser of syslogMsgTableMaxSize and
>> 4294967295).
>
> No, it wraps at 4294967295 always. What makes you believe it maps at
> min(syslogMsgTableMaxSize, 4294967295)?

I'm very sorry. When I wrote this I went back to check on the email thread, 
and copied from my original question and not from your answer. (That's a 
poor excuse, I know.)

So, this impacts Dave's question; Entries *do* get deleted from the table as 
the valid index window slides upwards.

>> > Does rollover just overwrite starting at the beginning of the table?
>> Yes.
>
> Only in the case where the agent has storage for 4294967295 table
> entries, something I consider unlikely implementations will support.
>
>> Yes. And this is what swings it for me.
>> I am just left wondering whether an Agent is more loaded by a bulk read 
>> of
>> 10,000 entries or maintaining a pointer into the table.
>>
>> Clear up this last point, and I'm done.
>
> If you only need the oldest entry in table insertion time, such an
> index is of course handy. The question is what practical value it has
> to be able to retrieve this oldest entry quickly.

If we agree that the management station should read and store the table, 
parse it, and then do whatever it wants to. I agree: none.

Adrian