[midcom] Re: midcom revised mib review

Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> Wed, 07 June 2006 20:21 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4X7-0005Yn-Ii; Wed, 07 Jun 2006 16:21:41 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4X6-0005Yg-23 for midcom@ietf.org; Wed, 07 Jun 2006 16:21:40 -0400
Received: from hermes.iu-bremen.de ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4X4-0004oZ-Ej for midcom@ietf.org; Wed, 07 Jun 2006 16:21:40 -0400
Received: from localhost (demetrius.iu-bremen.de []) by hermes.iu-bremen.de (Postfix) with ESMTP id 5578955E5F; Wed, 7 Jun 2006 21:51:22 +0200 (CEST)
Received: from hermes.iu-bremen.de ([]) by localhost (demetrius.iu-bremen.de []) (amavisd-new, port 10024) with ESMTP id 03839-01; Wed, 7 Jun 2006 21:51:20 +0200 (CEST)
Received: from boskop.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id C39CF55E45; Wed, 7 Jun 2006 21:51:19 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501) id 0E3BD744595; Wed, 7 Jun 2006 21:51:15 +0200 (CEST)
Date: Wed, 7 Jun 2006 21:51:15 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Juergen Quittek <quittek@netlab.nec.de>
Message-ID: <20060607195115.GA361@boskop.local>
Mail-Followup-To: Juergen Quittek <quittek@netlab.nec.de>, Juergen Quittek <quittek@ccrle.nec.de>, Martin Stiemerling <stiemerling@netlab.nec.de>, "P. Srisuresh" <srisuresh@yahoo.com>, Melinda Shore <mshore@cisco.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Lars Eggert <lars.eggert@netlab.nec.de>, Dan Romascanu <dromasca@avaya.com>, midcom@ietf.org
References: <20060531130853.GC4696@boskop.local> <53CC5C0AB8F9DD2F421515B0@[]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53CC5C0AB8F9DD2F421515B0@[]>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: Martin Stiemerling <stiemerling@netlab.nec.de>, Melinda Shore <mshore@cisco.com>, "P. Srisuresh" <srisuresh@yahoo.com>, Juergen Quittek <quittek@ccrle.nec.de>, midcom@ietf.org, Dan Romascanu <dromasca@avaya.com>, Lars Eggert <lars.eggert@netlab.nec.de>
Subject: [midcom] Re: midcom revised mib review
X-BeenThere: midcom@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: midcom.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=subscribe>
Errors-To: midcom-bounces@ietf.org

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
> >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.


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

midcom mailing list