[midcom] Re: midcom revised mib review
Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> Wed, 07 June 2006 20:21 UTC
Received: from [127.0.0.1] (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 [10.91.34.44] (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 ([212.201.44.23]) 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 [212.201.44.32]) 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 ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 03839-01; Wed, 7 Jun 2006 21:51:20 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.1]) (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, 07 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@[10.1.1.104]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <53CC5C0AB8F9DD2F421515B0@[10.1.1.104]>
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 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom
- [midcom] midcom revised mib review Juergen Schoenwaelder
- [midcom] Re: midcom revised mib review Juergen Quittek
- [midcom] Re: midcom revised mib review Juergen Quittek
- [midcom] Re: midcom revised mib review Juergen Schoenwaelder
- [midcom] Re: midcom revised mib review Juergen Quittek
- [midcom] Re: midcom revised mib review Juergen Schoenwaelder