From midcom-bounces@ietf.org Wed Jun 07 09:39:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnyFV-00057U-Uh; Wed, 07 Jun 2006 09:39:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnyFU-00057O-9P for midcom@ietf.org; Wed, 07 Jun 2006 09:39:04 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnyFQ-0002SL-Ji for midcom@ietf.org; Wed, 07 Jun 2006 09:39:04 -0400 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5C26C1BAC4D; Wed, 7 Jun 2006 15:28:45 +0200 (CEST) Date: Wed, 07 Jun 2006 15:38:49 +0200 From: Juergen Quittek To: j.schoenwaelder@iu-bremen.de, Juergen Quittek , Martin Stiemerling , "P. Srisuresh" Message-ID: <53CC5C0AB8F9DD2F421515B0@[10.1.1.104]> In-Reply-To: <20060531130853.GC4696@boskop.local> References: <20060531130853.GC4696@boskop.local> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: Melinda Shore , Lars Eggert , midcom@ietf.org, Dan Romascanu Subject: [midcom] Re: midcom revised mib review X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Hi Juergen, Many thanks for the review! 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). Thanks, Juergen Q. --On 31.05.2006 15:08 Uhr +0200 Juergen Schoenwaelder wrote: > Hi, > > first of all, I have to apologize for the delay (I will spare you the > reasons you might not be interested in anyway). > > I have read once again carefully. I > think it is generally of high quality and I do not have major problems > with it. Still, I have a few comments I like to share with you and > perhaps some of the things can still be improved without much further > delay. > > a) p6: "sending notification to MIDCOM client" - either "a MIDCOM > client" or "MIDCOM clients" fixed. We chose "MIDCOM clients". > b) p13: "for request message and reply message" -> "for the request > and the reply message" fixed. > c) p17: "For example, it can" -> "For example, they can" fixed. > d) p22: "The values provide" -> "The values provided" fixed. > e) p26: "the idle or" -> "the idle time" fixed. > f) p27: "MIDCOm" -> "MIDCOM" fixed. > g) p29: "For some application" -> "For some applications" fixed. > 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) p30: "below recommended" -> "below are recommended" fixed. > j) p31ff: I am still somewhat concerned about the fact that the text > encourages implementors to potentially do the wrong thing. > You can't rely on notifications. While step 7. in section > 7.3 says the right thing, I would prefer if the text would > actually be moved where it belonts, namely in step 4. So > here is what I propose how step 4 should be written: > > 4. The MIDCOM client awaits a midcomSolicitedRuleEvent notification > concerning the new policy rule in the midcomRuleTable. Waiting > for the notification is timed out after a pre-selected maximum > waiting time. In case of a timeout while waiting for the > notification or if the client does not use notifications, the > MIDCOM client retrieves the status of the midcomRuleEntry by one > or more SNMP get operation. > > By moving the text into this step, you can get rid of step 7 > and make it clearer that you have to write code to poll for > the completion of the operation anyways. > > Note that this change also affects subsequent sections, > namely 7.4, 7.5, 7.6, and 7.10. done for all of them. > k) p33: Step 5 in 7.5 refers to step 5 in 7.3 but I think it should be > step 4 in 7.3. fixed. > l) p42: The description of midcomRuleOwner is a bit confusing. It says: > > This object SHOULD uniquely identify an authenticated > MIDCOM client. It is of type SnmpAdminString, a textual > convention that allows for use of the SNMPv3 View-Based > Access Control Model (RFC 3415, VACM) and allows an > management application to identify its entries." > > This sounds like the SnmpAdminString TC has something special > concerning VACM which is not true. Perhaps less is more: > > This object SHOULD uniquely identify an authenticated > MIDCOM client. This object is part of the table index to > allow for the use of the SNMPv3 View-Based Access Control > Model (RFC 3415, VACM). done. > 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? > 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. > o) p45: "can be retrieved" -> "are meaningful" (twice on that page). > My understanding is that you can always retrieve all columns > but depending of the midcomRuleAdminStatus only some of them > are meaningful. fixed. > p) p46: "rule is expired" -> "rule has expired" fixed. > q) p48: midcomRuleError does not support localization and this seems > to be a string that is likely to be shown to human users. I am > just mentioning this... Thank you. We do not see a straight way to supporting localization here. > r) p54: Is there a reason why you do not use the > InetAddressPrefixLength TC for > midcomRuleInternalIpPrefixLength and > midcomRuleExternalIpPrefixLength? In case you use > InetAddressPrefixLength, make sure you allocate the max value > for the "no wildcarding" semantics and not just 128. replaced SYNTAX Unsigned32 (0..128) with SYNTAX InetAddressPrefixLength for both objects. > 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). > t) p63: First sentence in the DESCRIPTION is missing some words. fixed. Just one word missing. > u) p67: "inteface" -> "interface" fixed. > v) p73: "request. (" -> "request (" fixed. > w) p74: "request. (" -> "request (" fixed. > x) p81: "to managed object" -> "to the managed object" fixed. > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Wed Jun 07 10:20:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnyth-0002O2-Qw; Wed, 07 Jun 2006 10:20:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnyth-0002Nx-3V for midcom@ietf.org; Wed, 07 Jun 2006 10:20:37 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnytg-0007oA-Cr for midcom@ietf.org; Wed, 07 Jun 2006 10:20:37 -0400 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 20B481BAC4D; Wed, 7 Jun 2006 16:10:21 +0200 (CEST) Date: Wed, 07 Jun 2006 16:20:31 +0200 From: Juergen Quittek To: j.schoenwaelder@iu-bremen.de, Juergen Quittek , Martin Stiemerling , "P. Srisuresh" Message-ID: <9A430F9EB7556A66E49BF90A@[10.1.1.104]> In-Reply-To: <53CC5C0AB8F9DD2F421515B0@[10.1.1.104]> References: <20060531130853.GC4696@boskop.local> <53CC5C0AB8F9DD2F421515B0@[10.1.1.104]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: Melinda Shore , Lars Eggert , midcom@ietf.org, Dan Romascanu Subject: [midcom] Re: midcom revised mib review X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Dear all, For your convenience, please find the new version -07 at and a diff to the previous version -06 at Juergen Q. --On 07.06.2006 15:38 Uhr +0200 Juergen Quittek wrote: > Hi Juergen, > > Many thanks for the review! > > 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). > > Thanks, > > Juergen Q. > > --On 31.05.2006 15:08 Uhr +0200 Juergen Schoenwaelder wrote: > >> Hi, >> >> first of all, I have to apologize for the delay (I will spare you the >> reasons you might not be interested in anyway). >> >> I have read once again carefully. I >> think it is generally of high quality and I do not have major problems >> with it. Still, I have a few comments I like to share with you and >> perhaps some of the things can still be improved without much further >> delay. >> >> a) p6: "sending notification to MIDCOM client" - either "a MIDCOM >> client" or "MIDCOM clients" > > fixed. We chose "MIDCOM clients". > >> b) p13: "for request message and reply message" -> "for the request >> and the reply message" > > fixed. >> c) p17: "For example, it can" -> "For example, they can" > > fixed. > >> d) p22: "The values provide" -> "The values provided" > > fixed. > >> e) p26: "the idle or" -> "the idle time" > > fixed. > >> f) p27: "MIDCOm" -> "MIDCOM" > > fixed. > >> g) p29: "For some application" -> "For some applications" > > fixed. > >> 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) p30: "below recommended" -> "below are recommended" > > fixed. > >> j) p31ff: I am still somewhat concerned about the fact that the text >> encourages implementors to potentially do the wrong thing. >> You can't rely on notifications. While step 7. in section >> 7.3 says the right thing, I would prefer if the text would >> actually be moved where it belonts, namely in step 4. So >> here is what I propose how step 4 should be written: >> >> 4. The MIDCOM client awaits a midcomSolicitedRuleEvent notification >> concerning the new policy rule in the midcomRuleTable. Waiting >> for the notification is timed out after a pre-selected maximum >> waiting time. In case of a timeout while waiting for the >> notification or if the client does not use notifications, the >> MIDCOM client retrieves the status of the midcomRuleEntry by one >> or more SNMP get operation. >> >> By moving the text into this step, you can get rid of step 7 >> and make it clearer that you have to write code to poll for >> the completion of the operation anyways. >> >> Note that this change also affects subsequent sections, >> namely 7.4, 7.5, 7.6, and 7.10. > > done for all of them. > >> k) p33: Step 5 in 7.5 refers to step 5 in 7.3 but I think it should be >> step 4 in 7.3. > > fixed. > >> l) p42: The description of midcomRuleOwner is a bit confusing. It says: >> >> This object SHOULD uniquely identify an authenticated >> MIDCOM client. It is of type SnmpAdminString, a textual >> convention that allows for use of the SNMPv3 View-Based >> Access Control Model (RFC 3415, VACM) and allows an >> management application to identify its entries." >> >> This sounds like the SnmpAdminString TC has something special >> concerning VACM which is not true. Perhaps less is more: >> >> This object SHOULD uniquely identify an authenticated >> MIDCOM client. This object is part of the table index to >> allow for the use of the SNMPv3 View-Based Access Control >> Model (RFC 3415, VACM). > > done. > >> 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? > >> 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. > >> o) p45: "can be retrieved" -> "are meaningful" (twice on that page). >> My understanding is that you can always retrieve all columns >> but depending of the midcomRuleAdminStatus only some of them >> are meaningful. > > fixed. > >> p) p46: "rule is expired" -> "rule has expired" > > fixed. > >> q) p48: midcomRuleError does not support localization and this seems >> to be a string that is likely to be shown to human users. I am >> just mentioning this... > > Thank you. > We do not see a straight way to supporting localization here. > >> r) p54: Is there a reason why you do not use the >> InetAddressPrefixLength TC for >> midcomRuleInternalIpPrefixLength and >> midcomRuleExternalIpPrefixLength? In case you use >> InetAddressPrefixLength, make sure you allocate the max value >> for the "no wildcarding" semantics and not just 128. > > replaced > SYNTAX Unsigned32 (0..128) > with > SYNTAX InetAddressPrefixLength > for both objects. > >> 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). > >> t) p63: First sentence in the DESCRIPTION is missing some words. > > fixed. Just one word missing. > >> u) p67: "inteface" -> "interface" > > fixed. > >> v) p73: "request. (" -> "request (" > > fixed. > >> w) p74: "request. (" -> "request (" > > fixed. > >> x) p81: "to managed object" -> "to the managed object" > > fixed. > >> /js >> >> -- >> Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, 28725 Bremen, Germany > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Wed Jun 07 16:21:42 2006 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, 7 Jun 2006 21:51:15 +0200 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20060607195115.GA361@boskop.local> Mail-Followup-To: Juergen Quittek , Juergen Quittek , Martin Stiemerling , "P. Srisuresh" , Melinda Shore , Magnus Westerlund , Lars Eggert , Dan Romascanu , 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 , Melinda Shore , "P. Srisuresh" , Juergen Quittek , midcom@ietf.org, Dan Romascanu , Lars Eggert 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: , List-Post: List-Help: List-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 P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Thu Jun 08 04:54:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoGHU-0003q7-9u; Thu, 08 Jun 2006 04:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoGHT-0003q2-1a for midcom@ietf.org; Thu, 08 Jun 2006 04:54:19 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoGHS-0006uR-Dp for midcom@ietf.org; Thu, 08 Jun 2006 04:54:19 -0400 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id D64BE1BAC4D; Thu, 8 Jun 2006 10:43:59 +0200 (CEST) Date: Thu, 08 Jun 2006 10:54:10 +0200 From: Juergen Quittek To: j.schoenwaelder@iu-bremen.de Message-ID: In-Reply-To: <20060607195115.GA361@boskop.local> References: <20060531130853.GC4696@boskop.local> <53CC5C0AB8F9DD2F421515B0@[10.1.1.104]> <20060607195115.GA361@boskop.local> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: Martin Stiemerling , Melinda Shore , "P. Srisuresh" , midcom@ietf.org, Dan Romascanu , Lars Eggert Subject: [midcom] Re: midcom revised mib review X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org --On 07.06.2006 21:51 Uhr +0200 Juergen Schoenwaelder wrote: > > 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". OK. Are you fine with the modifications below? OLD: 4.2.4.4. Lifetime Change Transactions For the policy Rule Lifetime Change (RLC) transaction and the Group Lifetime Change (GLC) transaction atomicity is maintained. They both have very few parameters for the request message and the reply message. The request parameters can be transmitted by a single SNMP set request message and the reply parameters can be transmitted by a single SNMP notification message. In order to prevent idempotency problems by retransmitting an SNMP request after a lost SNMP reply, it is RECOMMENDED that the value of the SNMP retransmission timer is lower than the smallest requested lifetime value. The same recommendation applies to the smallest requested value for the midcomRuleStorageTime. MIDCOM client implementations MAY completely avoid this problem by configuring their SNMP stack such that no retransmissions are sent. NEW 4.2.4.4. Lifetime Change Transactions For the policy Rule Lifetime Change (RLC) transaction and the Group Lifetime Change (GLC) transaction atomicity is maintained. They both have very few parameters for the request message and the reply message. The request parameters can be transmitted by a single SNMP set request message and the reply parameters can be transmitted by a single SNMP notification message. In order to prevent idempotency problems by retransmitting an SNMP request after a lost SNMP reply, it is RECOMMENDED that either snmpSetSerialNo (see [RFC3418]) is included in the corresponding SNMP SET request or the value of the SNMP retransmission timer is lower than the smallest requested lifetime value. The same recommendation applies to the smallest requested value for the midcomRuleStorageTime. MIDCOM client implementations MAY completely avoid this problem by configuring their SNMP stack such that no retransmissions are sent. OLD: 6.5. Avoiding Idempotency Problems As already discussed in section 4.2.4.4, the following recommendation is given for configuring the SNMP retransmission timer at the MIDCOM client (acting as SNMP Command Generator). In order to prevent idempotency problems with setting midcomRuleLifetime and midcomRuleMaxIdleTime when retransmitting an SNMP SET request after a lost SNMP reply, it is RECOMMENDED that the value of the SNMP retransmission timer of a MIDCOM client is lower than the smallest requested value for any rule lifetime or rule idle time. NEW 6.5. Avoiding Idempotency Problems As already discussed in section 4.2.4.4, the following recommendation is given for avoiding idempotency problems. In general, idempotency problems can be solved by including snmpSetSerialNo (see [RFC3418]) in SNMP SET requests. In case this feature is not used, it is RECOMMENDED that the value of the SNMP retransmission timer of a MIDCOM client (acting as SNMP Command Generator) is lower than the smallest requested value for any rule lifetime or rule idle time in order to prevent idempotency problems with setting midcomRuleLifetime and midcomRuleMaxIdleTime when retransmitting an SNMP SET request after a lost SNMP reply. >> > 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. Fine. Done. >> > 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. Fixed. Also replaced the following "an" with "a". >> > 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. Thanks, Martin & Juergen Q. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Thu Jun 08 08:06:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoJHZ-0000xx-KL; Thu, 08 Jun 2006 08:06:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoJHZ-0000x0-3y for midcom@ietf.org; Thu, 08 Jun 2006 08:06:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoHuX-000223-CR for midcom@ietf.org; Thu, 08 Jun 2006 06:38:45 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoHls-00042I-By for midcom@ietf.org; Thu, 08 Jun 2006 06:29:52 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 246AC560C4; Thu, 8 Jun 2006 12:29:47 +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 23824-03; Thu, 8 Jun 2006 12:29:45 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 3C423560C3; Thu, 8 Jun 2006 12:29:45 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 790B7746B3D; Thu, 8 Jun 2006 12:29:43 +0200 (CEST) Date: Thu, 8 Jun 2006 12:29:43 +0200 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20060608102943.GA4666@boskop.local> Mail-Followup-To: Juergen Quittek , Martin Stiemerling , "P. Srisuresh" , Melinda Shore , Magnus Westerlund , Lars Eggert , Dan Romascanu , midcom@ietf.org References: <20060531130853.GC4696@boskop.local> <53CC5C0AB8F9DD2F421515B0@[10.1.1.104]> <20060607195115.GA361@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: -2.2 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Martin Stiemerling , Melinda Shore , "P. Srisuresh" , midcom@ietf.org, Dan Romascanu , Lars Eggert 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: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org On Thu, Jun 08, 2006 at 10:54:10AM +0200, Juergen Quittek wrote: > OK. Are you fine with the modifications below? [...] yes /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Thu Jun 08 16:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRK7-0004pE-Oe; Thu, 08 Jun 2006 16:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRK6-0004nL-AF; Thu, 08 Jun 2006 16:41:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoQw7-0005Qk-Tw; Thu, 08 Jun 2006 16:16:59 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoQW2-00064t-1J; Thu, 08 Jun 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k58Jo1WR007603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FoQW1-0003hV-L0; Thu, 08 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Jun 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: midcom@ietf.org Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-07.txt X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Definitions of Managed Objects for Middlebox Communication Author(s) : J. Quittek, et al. Filename : draft-ietf-midcom-mib-07.txt Pages : 87 Date : 2006-6-8 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 3989. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-8130012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-8130012.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom --NextPart-- From midcom-bounces@ietf.org Fri Jun 09 04:42:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FocZV-00028n-JV; Fri, 09 Jun 2006 04:42:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FocZT-0001xu-Pn; Fri, 09 Jun 2006 04:42:23 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FocZS-0003fa-6m; Fri, 09 Jun 2006 04:42:23 -0400 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id DAC6B1BAC4D; Fri, 9 Jun 2006 10:31:55 +0200 (CEST) Date: Fri, 09 Jun 2006 10:42:15 +0200 From: Juergen Quittek To: Internet-Drafts@ietf.org, i-d-announce@ietf.org Subject: Re: [midcom] I-D ACTION:draft-ietf-midcom-mib-07.txt Message-ID: <0B5A0B9AB6C662D16DCC2F2B@[10.1.1.104]> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: midcom@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Dear all, This version incorporates the changes suggested by our MIB doctor Juergen Schoenwaelder. Please find changes to the previous version -06 marked at . Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 08.06.2006 15:50 Uhr -0400 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Middlebox Communication Working Group of the IETF. > > Title : Definitions of Managed Objects for Middlebox Communication > Author(s) : J. Quittek, et al. > Filename : draft-ietf-midcom-mib-07.txt > Pages : 87 > Date : 2006-6-8 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes a set of managed objects that allow > configuring middleboxes, such as firewalls and network address > translators, in order to enable communication across these devices. > The definitions of managed objects in this documents follow closely > the MIDCOM semantics defined in RFC 3989. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-07.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-midcom-mib-07.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-midcom-mib-07.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom