RE: [ipcdn] Re: WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1

Juergen, 

I concur with all your comments and proposed actions

Thanks

Eduardo

-----Original Message-----
From: Juergen Quittek [mailto:[email protected]] 
Sent: Thursday, July 15, 2004 2:32 PM
To: Eduardo Cardona; Randy Presuhn; [email protected]
Subject: RE: [ipcdn] Re: [Disman] WG last
callondraft-ietf-disman-remops-mib-v2-01.txt Part1


Eduardo,

Please find comments inline.

--On 09.07.2004 17:44 h -0600 Eduardo Cardona wrote:
>>
 [...]
>>
>> pingCtlTrapGeneration
>> I see a lot of overlapping in between probeFailures and TestFailures 
>> because both are within a ping Test. Making that very punctual for 
>> notification stand point
>>
>> One approach (two layers) could be that TestFailure notification is 
>> only sent after multiple Test Failures
>
> Exactly this is the case, see pingCtlTrapTestFailureFilter. Or did I 
> get something wrong?
>
>  - See next comment
>
>> ( based on the Frequency object may
>> indicate reasonable periods of hosts disconnection) so you can avoid 
>> getting ProbeFailure notification but use this counter for accumulate

>> Test failures, then collect notifications only for Test failures 
>> periods
>> -probeFailure(0) set to '0'. In the other hand setting 
>> probeFailure(0) to '1' will get the time details of the probe 
>> failures that constitute
> a
>> Test failure.
>
> I don't really get this.  We have a counter for probe failures and a 
> counter for test failures.  Both can be switched on and off 
> independently by setting the corresponding bits in 
> pingCtlTrapGeneration.
>
> - I agree that this should be the intention; probably some terms are 
> not used exactly pingCtlTrapTestFailureFilter says
>                       "...a pingTestFailed NOTIFICATION is
>            generated only when the number of ping failures
>            within a test exceed the value of
>            pingCtlTrapTestFailureFilter."
>
> pingCtlFrequency  says:
>            "...
>            A value of 0 for this object implies that the test
>            as defined by the corresponding entry will not be
>            repeated."
>
> "within a test" above seems to be associated to a "test" (a set of 
> ping
> probes) not a consecutive number of tests as per CtlFrequency > 0 will
> imply
>
> Another variant will be that instead of saying
> ProbeFailures =  3
> TestFailures = 4
> Japanesse notation:  O ok X fail ( with your assumption below that all

> probes in test means failure ? ) Test 1: probe1: O, probe2: X, probe3:

> X Test 2: probe1: X, -> TestFailure NOTIFICATION
>
> Test1: O
> Test2: X
> Test3: X
> Test4: X
> Test5: X -> TestFailure NOTIFICATION
>
> I think will be more interested if consecutive N Test Failed:  It also

> remove the otherwise required constrain that TestFailure > 
> probeFailure
>
>                       "...a pingTestFailed NOTIFICATION is
>            generated only when a number of consecutive
>            test failures exceed the value of
>            pingCtlTrapTestFailureFilter. After a NOTIFICATION
>            is generated the test failure counter is reinitialized."
>
>   - it is an internal implicit counter with no MIB representation, 
> which I think is ok

This is the way I understand the current MIB specification. Following
your proposal, I suggest to change the text in the DESCRIPTION clause of
pingCtlTrapProbeFailureFilter to

    "... a pingTestFailed NOTIFICATION is generated only when
           a number of consecutive ping tests equal to the
           value of pingCtlTrapProbeFailureFilter fail.
           After triggering the notification the test failure,
           counter is reset to zero."

> The third alternative is
># probes per test is very long and all TestFailure and ping Probes are

>within a particular test. Which I think  Does not scale well for time 
>intervals flexibility (test vs test  frequency). / different sort of 
>SLA needs.  But if that is the case the definitions are ok but with the

>hiden  constrain that TestFailure > Ping Probe (within a test)

 [...]

>> pingCtlTrapProbeFailureFilter
>>            "The value of this object is used to determine when
>>            to generate a pingProbeFailed NOTIFICATION.
>>
>>            Setting pingCtlTrapGeneration BIT probeFailure(0)
>>            to '1' implies that a pingProbeFailed
>
> I think we can omit "to '1'".
>
> - but what it mean setting BIT probeFailure(0) setting to '1' or 
> setting to '0'?
>   Both values are valid so I do not see that setting BITs means to UP,

> ON or '1'
>   eventually I missed that from SMI but I have been see other MIB 
> MODULES defining setting
>   BIT X to '1' or '0'

A common terminology when talking about bits is 'set' means assigning
the value '1' to the bit, while 'reset' means assigning the value '0' to
the bit.  But your version avoids misunderstandings, so let's take it.

>>            NOTIFICATION is generated only when a number of
>>            successive ping probes equal to the value of
>>            pingCtlTrapPrbefailureFilter fail within
>>            a given ping test. Then a Test failure condition is
>>            reached and the probe failure count is
>>            reset for the following attempts within the
>>            given ping test."
>
> I disagree with the first part of the last sentence "Then a Test 
> failure condition is reached", but I agree to the rest.
>
>  - Ok, aligned with my other clarifications proposed above

Please see my new text suggestion above.

>> Similar for pingCtlTrapTestFailureFilter
>>            "The value of this object is used to determine when
>>            to generate a pingTestFailed NOTIFICATION.
>>
>>            Setting pingCtlTrapGeneration BIT testFailure(1)
>>            to '1' implies that a pingTestFailed NOTIFICATION is
>>            generated only when the number of test failures
>>            within a test exceed the value of
>>            pingCtlTrapTestFailureFilter."
>
> He also need to add a statement on reseeting the test failure counter 
> when the notification is sent.
>
> - as proposed above .... But still unsure if the intention is to keep 
> this "within a test" as commented above (alternative 3)
>
>                       "...a pingTestFailed NOTIFICATION is
>            generated only when a number of consecutive
>            test failures exceed the value of
>            pingCtlTrapTestFailureFilter. After a NOTIFICATION
>            is generated the test failure counter is reinitialized."
>
> - See the proposed
>> Above is also included a small wording for the BIT sets
>>
>> pingCtlSourceAddressType I believe should have DEFVAL 'unknown' to 
>> conform with RFC3291 bis draft 03
>
> Fine with me.
> Any objections from the "Who needs IPv6?" community?
>
>>
>> MinimumCompliance
>> *****************
>>
>> PingCtlRowStatus  has a compliance SYNTAX read-only; some 
>> clarifications in how the minimum compliance default entry All time 
>> with value 'active' ? Regularly a 'notReady' entry when filled all 
>> the
>
>> minimum object sets becomes 'notInService' and need to be set to 
>> 'active'  via SNMP to complete the operation
>
> In read-only mode it has three possible values:
>   - 'notReady' as long as pingCtlTargetAddress is not specified.
>   - 'notInService' starting when pingCtlTargetAddress specified until
>     pingCtlAdminStatus is set to enabled(1).
>   - 'active' after pingCtlAdminStatus has been set to enabled(1)
>     in state 'notInService'.
>   - again 'notInService' after pingCtlAdminStatus has been set to
> disabled(1)
>     in stat 'active'.
>
> - About
> "'active' after pingCtlAdminStatus has been set to enabled(1)
>     in state 'notInService'"
>
> -I do not think that RowStatus TC can transition automatically from 
> 'notInService' to 'active'

You are right.  The TC does not allow to do so.

Now I do not see anymore a clean way of keeping object pingCtlRowStatus
in the minimumCompliance.  So, let's go back to your initial suggestion
and remove the object from the minimumCompliance.  Since this is the
last column of the pingCtlTable, removing this object does not create a
'hole' in the consecutive list of columnar objects.

The same applies to traceRouteCtlRowStatus.

Thanks,

    Juergen
-- 
Juergen Quittek        [email protected]       Tel: +49 6221
90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221
90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
http://www.netlab.nec.de