Subject: RE: [Diffserv] comments from Dave Perkins regarding RowPointers

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 27 Sep 2001 13:51:38 +0200

Inline

Juergen answers Fred:
>              |
> Fred> Is that what you mean? And is that a good approach for us?
> 
> I think the agent should return an inconsistentValue error in both
> cases. I also think that this is inline with RFC 2579 note (7) on page
> 10. Not returning an error means that the manager has to poll again
> each time it tries to delete a row.
> 
> Otherwise, the text covers pretty much what I had in mind.
> 

I agree with Juergen that an error should be returned and that
'inconsistentValue' is the best error code to return. And I think
this should then be added to all the description clauses of RowPointers
and RowStatus objects.

Bert

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Fred Baker <[email-masked]>
Date: Thu, 27 Sep 2001 05:54:53 -0700

>Date: Wed, 26 Sep 2001 12:26:45 -0700 (PDT)
>From: "David T. Perkins" <[email-masked]>
>X-Sender: [email-masked]
>To: Fred Baker <[email-masked]>
>cc: [email-masked]
>Subject: Re: comments from Dave Perkins regarding RowPointers
>
>HI,
>
>If the following makes sense to send to others, then please
>forward...
>
>One of the big questions for me is can/would the MIB be used
>in
>  1) a MIB browser? (I don't think so)
>  2) by a simple management app (it doesn't remember any config
>     info, so when someone wants to do some configuration, then
>     it must muck around with MIB objects) (If so, then adding
>     "helper objects" (such as the nextIndex and the reference
>     counts (a gauge)), are helpful. And maybe other objects would
>     be helpful, but don't have a good feel until I've worked
>     on developing an application).
>  3) by sophisticated management apps (for these, they create
>     data structs that mirror the MIB information, and monitor
>     config changes to keep their data structs in synch)
>     (For such apps, there is no need for helper objects,
>      since any needed helper objects are in the manager's
>      data structs)
>
> From my limited knowledge/experience, I believe that really
>only type #3 applications for configuration will be created.
>If someone does #1 or #2, they will really be toy apps.
>(Debugging/testing with a MIB browers could be done, but it
>would be painful.)
>
>Now, for monitoring counters, as long as the configuration
>is unchanged, this would be easy to do with #1 or a #2-like
>application.
>
>For a management app that reports configuration, I can't see
>the use of any helper objects. But again, someone that has
>more domain knowledge/experience than I should try to
>do this with the current objects. (Oh, there are one
>type of helper objects that could be useful for reporting
>apps, and those are "number of table entry" objects. They would be
>used to help with creating optimal GETBULK requests.
>For each table, get the current number of table entries.
>Then do a GETBULK for that number. Of course, you need
>some timestamp or serial number that you check before
>and after retrieving all table data to make sure nothing
>has changed.)
>
>Regards,
>/david t. perkins

---

From: "Robert Moore" <[email-masked]>
Date: Thu, 27 Sep 2001 10:13:15 -0400

I agree with Joel here.  There's nothing about
RowPointers, RowStatus, use counts, clean-up, etc.
that's in any way unique to DiffServ or the DiffServ
MIB.  Sometimes it's useful for a particular MIB /
WG to advance the state of the art relative to
general issues such as these, with the hope that
their good example will be picked up across the
rest of the SNMP world.  But I don't think this
is one of those times, because the issues require
more thought than the DiffServ WG is going to be
able to give them at this stage of the MIB's
development.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

"Joel M. Halpern" <[email-masked]>@ietf.org on 09/27/2001 09:29:05 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: [Diffserv] comments from Dave Perkins regarding RowPointers

It seems to me that this is a general SNMP problem that was introduced and
ignored when row pointers were introduced into SNMP.  (Quite possibly
properly ignored.  It may well be that the right answer is "do nothing".)
As such, I really think it is NOT the diffserv working groups job to craft
and introduce a solution to this problem.  The proposed solutions have
signficant impact if used as a model for other MIBs, and I think that if
this problem is to be address, EoS would be the place to discuss it, not
diffserv.  This was not a fatal flaw in other MIBs that have row pointers,
so I conclude that we have merely surfaced a general issue by putting more
weight on an existing mechanism.

Yours,
Joel M. Halpern

> >>>>> Fred Baker writes:
>
>Fred> I have a usability concern in the RowStatus case,
>Fred> however. Suppose that I wanted to remove a classifier. That
>Fred> classifier consists of:
>
>Fred>          one classifier entry N classifier element entries N
>Fred> MultiField filter descriptions.
>
>Fred> So the logical thing for me to do is send a single SET with
>Fred> 2*N+1 RowStatus variables, all set to "destroy".
>
>Fred> Suppose, however, that N/2 of the MultiField filter descriptions
>Fred> were re-used by someone else. Since I don't know that, as I
>Fred> understand SNMP processing, each time I send the SET I will get
>Fred> back an error and a pointer to the offending VarBind. I will
>Fred> therefore send the SET N/2 times, getting back that error and
>Fred> removing the indicated RowStatus variable, and then finally send
>Fred> a SET that takes effect.
>
>Fred> This seems to me a colossal waste. Wouldn't it be better to
>Fred> swallow those errors, and simply remove the rows that could be
>Fred> removed at the time?
>
>Perhaps. I was concerned about rows that hang around without any other
>rows pointing to them anymore and where the manager(s) think the row
>has already been successfully deleted. This basically requires that
>managers implement a kind of garbage collection mechanism which
>destroys rows which have already been destroyed but still hang around
>in the agent.
>
>Another option: If a manager sends a destroy but the agent can not
>remove the row since it still is being referenced, then it reports
>success and sets a flag which causes the agent to destroy the row as
>soon as the reference count comes down to 0. So it becomes the agent's
>job to clean things up and the 'destroy' more or less becomes as
>'release' operation.
>
>/js
>
>Archive:
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html