[midcom] Re: midcom revised mib review

[Juergen Quittek <[e-mail]>]

--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
[e-mail]
https://www1.ietf.org/mailman/listinfo/midcom