Re: midcom revised mib review

On Wed, Jun 07, 2006 at 03:38:49PM +0200, Juergen Quittek wrote:
 
> Martin and I went through your comments and fixed the draft.
> Please find our replies inline below.
> Please have a look at issues h), m), n), and s).

[...]
 
> >h) p29: I am wondering why the document does not suggest to use
> >        snmpSetSerialNo to solve the idempotency problem.
> 
> Actually, we did not find any MIB module using this feature.
> Therefore, we do not expect big support form implementations.
> 
> Also, its DESCRIPTION clause
> 
>           "An advisory lock used to allow several cooperating
>           command generator applications to coordinate their
>           use of the SNMP set operation. ...
> 
> says that it is to be used for coordinating between multiple
> command generators.  Our idempotency problem is rather related
> to re-sent requests from a single command generator.

I believe that using snmpSetSerialNo in the set requests solves the
idempotency problems, don't you think so? 

All I am asking for is a statement which essentially says "if you
include snmpSetSerialNo in the set requests, the idempotency problem
is solved".

> >m) p42: Should 0 not be excluded from midcomRuleIndex? You have done
> >        this for the midcomGroupIndex.
> 
> In an earlier version we had a special semantics for references to groups
> with index 0.  therefore, we excluded 0 from the set of values for
> midcomGroupIndex.  When we removed this feature, we forgot to include value
> 0 again.
> 
> Consequently, the suggestion is allowing 0 also for midcomGroupIndex.
> 
> Would there be a problem with using index 0 for midcomRuleIndex and
> midcomGroupIndex?

We learned over time that it is valuable if number spaces exclude zero
so that it can be used as a special value later on (e.g. when you need
a pointer to a rule which may be null or when you want to refer to all
rules). Hence my suggestion to exclude 0 from both midcomRuleIndex and
midcomGroupIndex.
 
> >n) p44: The description of midcomRuleOperStatus says that setting(2)
> >        indicates that no request was made. I am not sure how this can
> >        actually happen since midcomRuleAdminStatus is either
> >        reserve(1) or enable(2) and hence during row creation it has
> >        to take on one of these values. Perhaps a cleaner way to deal
> >        with this would be to add another state off(3) or whatever you
> >        want to call it which can be used when a row is created
> >        without already setting reserve(1) or enable(2). The other
> >        option would be to be very clear that a midcom client has to
> >        set either reserve(1) or enable(2) while creating a row in
> >        which case the state setting(2) does not make much sense to
> >        me.
> 
> We added value notSet(3) to this object and the following paragraph to
> the DESCRIPTION clause.
> 
>         When created an midcomRuleEntry is created without
>         explicitly setting this object, its value will be notSet(3).
>         However, a set request can only set this object to either
>         reserve(1) or enable(2).  Attempts to set this object to
>         notSet(3) will always fail with an inconsistentValue error.

Remove the first "created" and the solution seems fine.

> >s) p63: How does midcomConfigPersistentRules interact with the
> >        StorageType objects? In the light of StorageType, the term
> >        "persistent" is probably wrong and should be "nonVolatile".
> 
> In all discussions of related issues on the mailing list, the term
> "persistent" was used instead of "nonVolatile".  Therefore, we used
> it for naming this object.  If you insist we can change it to
> midcomConfigNonVolatileRules, but we prefer the current name.
> 
> Anyway, we appended the folowing paragraph to the DESCRIPTION clause.
> 
>         A value of true(1) indicates that there may be
>         entries in the midcomRuleTable with object
>         midcomRuleStorageType set to value nonVolatile(3).

Fine with me.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany