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

[Juergen Quittek <[e-mail]>]

Eduardo,

Many thanks for your comments.
Please find some replies inline.

--On 22.06.2004 11:42 Uhr -0600 Eduardo Cardona wrote:

> Thanks Jurgen for adding the Minimal compliance in the new draft
>
> Few comments:
>
> Draft is not indicating in upper header that is obsoleting RFC 2925

I think the RFC editor will take care of this issue.  I did not dare
yet using an "Obsoletes:" entry in the header while having an "Expires:"
entry in the line below :-)

> DISMAN-PING-MIB
>
> Since the objects are carried from a previous RFC, The extra comments I
> got for objects are not critical, although I went to the exercise of
> understanding and may worth for direct clarifications to me if I
> misunderstood them
>
> Please pay special attention to the new minimum compliance modules
> comments (under ****)
>
>
> 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?

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

> - also does "sucessive" means consecutive?

Let's replace "sucessive" by "consecutive".
Any objection from native English speakers?

> If Filter is set to 3
> 1)timeout, 2)timeout, 3)reply, 4) timeout, 5) timeout, 6) timeout, 7)
> reply
> Means ProbeFailure happen between  4) and 6)

As far as I understand the current DESCRIPTION clause,
the notification is triggered by 6).

> I think the testFailure(1) BIT  should indicate that a Test Failure is
> reached by the threshold of pingCtlTrapProbeFailure rather than
> pingCtlTrapTestFailure. Moreover the definitions of
> pingCtlTrapGeneration and
> pingCtlTrapProbeFailureFilter/pingCtlTrapTestFailureFilter are
> overlapping and probably redundant.

The bit testFailure(1) does not indicate that any failure happened,
it indicates that generation of notification in such a case is enabled.

As far as I understood the descriptions so far, a test is failed only
if all probes failed. I must admit that this is not explicitly specified.
Any comment from an implementer?

> A possible wording to illustrate the comment could be:
> "...
> For
> pingCtlTrapGeneration
> DESCRIPTION
>           "The value of this object determines when and if
>            to generate a notification for this entry:
>
>            probeFailure(0)   - Generate a pingProbeFailed
>                notification subject to the value of
>                pingCtlTrapProbeFailureFilter.
>            testFailure(1)    - Generate a pingTestFailed
>                notification. A Test Failure condition is defined
>                if within a test the number of probe failures
>                reaches the value of pingCtlTrapProbeFailureFilter
>            testCompletion(2) - Generate a pingTestCompleted
>                notification.
>
>            By default, no bits are set, indicating that
>            none of the above options are selected."
>
> pingCtlTrapProbeFailureFilter/TestFailureFilter
> the description of  pingCtlTrapProbeFailureFilter is not Clear to me if
> after the # of probe failures of the ProbeFailureFilter object are
> reached a notification is sent and if the counter is cleared
>
> e.g.
> pingCtlTrapProbeFailureFilter  = 5
> pingCtlProbeCount = 15
> Supposed all ping probes timed out,
> Will it send notification after attempts 5, 10 and 15
> or
> After attempts 5,6,7,....15
> A possible wording could be ( only sending notifications after attempts
> 5, 10 and 15:

You are right. This case is not well specified.

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

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

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

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

> a) Will the compliance statement should say that a 'notReady'  is
> automatically set to 'active' when all fields (specially when
> pingCtlTargetAddress is set?)

No, it will automatically be set to 'notInService'.

> would that be valid request? -not included
> in the state diagram of RowStatus TC-

>From 'notInService', transitions to 'active' can only be reached
by setting pingCtlAdminStatus.
(as specified in the DESCRIPTION clause of pingCtlRowStatus).
Note, that setting pingCtlTargetAddress and pingCtlAdminStatus
should still be possible with just a single SNMP PDU.

> Or
> b) more general the pingCtlAdminStatus should indicate an error when
> attempting to start (enabled(1) the test and the entry is notReady(2) /
> notInService(1) ?
>
> And probably the MinumimCompliance may need a SYNTAX clause like

Yes, this is missing.

> SYNTAX RowStatus { notReady(3), active(1)}

It should look like

  SYNTAX RowStatus { active(1), notInService(2), notReady(3)}

Probably it would be a good idea to explain the state transitions
(as described above) in the corresponding DESCRIPTION clause.

> Object Compliances
> pingCtlFrequency r-o; last sentence "A value zero means... " may not be
> needed any case, the test is not repeated and 0 value already defined In
> the object description

I agree that the sentence is redundant.  I thought it would help understanding
the compliancy more quickly, but I have no strong feeling about keeping or
removing the sentence.

Any further opinions?

> Normalization of SYNTAX sub-typing as in other objects. -- Just a
> comment Up to MIB doctor for style normalization in the compliances..
> pingCtlStorateType can have a SYNTAX clause
> SYNTAX StorageType { volatile(2)}

I think this is more strict.  I did not intend to exclude. for example,
'permanent' entries.

>> From RFC 2925 the Compliance statement has under pingGroup the objects
> of Ctl, Results, History and the Notification Group
>
> Since the minimal compliance has only Ctl, Results objects I think is
> better to define a MANDATORY-GROUP pingMinGroup including Ctl and
> Results Objects. So the original group is left intact (unless specific
> compliances are needed as pingComplianceV2 (if there are important
> differences with the original Compliance)

What about just renaming the new pingGroup to pingMinimumGroup?

> - Will be ok with MIB doctor perception of this compliances
> ramifications
>
>
>
> DISMAN-TRACEROUTE-MIB
>
>
> MinumumCompliance
> *****************
> Same as ping Compliances From RFC 2925 and new draft the
> traceRouteGroup has originally Ctl, Results and Probehistory Objects.
>
> The minimal compliance will just have a traceReouteMinimumGroup with Ctl
> and Results objects and leave the original group (fully compliant)
> intact.
>
>
> Same comments for traceRouteCtlFrequency and traceRouteCtlStorageType as
> for the PING minimum compliance.

OK, however we decide on the PING MIB, I will change the TRACEROUTE MIB
analogously.

Thanks,

    Juergen

>
> DISMAN-NSLOOKUP-MIB
> No issues.
>
>
> Thanks
>
> Eduardo
>
>
> -----Original Message-----
> From: Juergen Quittek [mailto:[e-mail]]
> Sent: Wednesday, June 16, 2004 3:47 PM
> To: Randy Presuhn; [e-mail]
> Cc: [e-mail]
> Subject: [ipcdn] Re: [Disman] WG last call
> ondraft-ietf-disman-remops-mib-v2-01.txt
>
>
> Dear all,
>
> I just posted a new version of the remote operation MIB modules.
> Following Eduardo's suggestion I added Minimum Compliancy statements in
> addition to the existing full compliancy statements to each of the three
> MIB modules.
>
> I also had to (syntactically) modify the existing compliancy statements.
> Please have a close look at all six MODULE-COMPLIANCE macros.  Until the
> document becomes available at the I-D repository, you can preview it at
> ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-disman-remops-mib-
> v2-02.txt
>
> There was not much response on my questions on how to define the minimum
> compliance statements.  I preferred leaving read-only objects in place
> to creating non-consecutive numbering of objects in table entries.  I am
> not dogmatic about this and suggestions for changes are very welcome.
>
> For simplifying the review here is a list of objects and groups for
> which the full and minimum compliance statements differ:
>
> pingHistoryGroup,
> pingNotificationsGroup
> pingCtlDataFill
> pingCtlFrequency
> pingCtlMaxRows
> pingCtlTrapGeneration
> pingCtlProbeFailureFilter
> pingCtlTestFailureFilter
> pingCtlDescr
> pingCtlByPassRouteTable
> pingProbeHistoryTime
>
> traceRouteHistoryGroup
> traceRouteCtlByPassRouteTable
> traceRouteCtlDontFragment
> traceRouteCtlInitialTtl
> traceRouteCtlFrequency
> traceRouteCtlDescr
> traceRouteCtlMaxRows
> traceRouteCtlTrapGeneration
> traceRouteCtlCreateHopsEntries
> traceRouteCtlRowStatus
> traceRouteHopsLastGoodProbe
>
> lookupCtlRowStatus
>
> Beyond the compliance statement I just made two changes to the document:
>
> 1. Added new section 3.4 introducing the compliance statement
>
> 2. Extended DESCRIPTION clause of object lookupPurgeTime by one
> sentence:
>
>          "A value of 0 indicates that automatic deletion
>           of entries is disabled."
>
> Thanks,
>
>     Juergen
> --
> Juergen Quittek        [e-mail]        Tel: +49 6221
> 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221
> 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
> http://www.ccrle.nec.de
>
>
> --On 29.04.2004 14:29 h -0700 Randy Presuhn wrote:
>
>> Hi -
>>
>> Are there any objections to proceding as Juergen and Eduardo suggest?
>> I'd like to see comment (pro or contra) on the specific questions
>> Juergen raised below.
>>
>> Randy, disman WG chair
>>
>>> From: "Juergen Quittek" <[e-mail]>
>>> To: "Eduardo Cardona" <[e-mail]>; "Randy Presuhn"
>>> <[e-mail]>; <[e-mail]>
>>> Cc: "Ipcdn List (E-mail)" <[e-mail]>
>>> Sent: Monday, April 26, 2004 1:11 AM
>>> Subject: RE: [Disman] WG last call on
>>> draft-ietf-disman-remops-mib-v2-01.txt
>>>
>>
>>> Eduardo,
>>>
>>> Thank you for raising this issue and my apologies for this very late
>>> reply.
>>>
>>> I ran into similar problems several times where a well designed
>>> technology was too mighty or too general for being implemented at
>>> small devices.
>>>
>>> Your suggestions aim at introducing additional MODULE-COMPLIANCE
>>> clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules
>>> for allowing simpler implementations with smaller footprints.
>>>
>>> I support your proposal, but have a few comments, see below. I am
>>> willing to make suggestions for minimalCompliance clauses for the MIB
>
>>> modules, but first the WG should agree on two issues:
>>>
>>>   - Is it agreed to add such clauses, that definitely require
>>>     less funtionality to be implemented?
>>>
>>>   - what is the preferred procedure for columnar objects that
>>>     are not required for minimal compliancy?  We can either
>>>     allow them to be missing completely.  But this would result
>>>     in non-consecutive numbering of the remaining objects in
>>>     the minimal tables.  Or we require them to be implemented
>>>     as read-only indicating that the feature that they would
>>>     serve in full compliancy is not supported.
>>>
>>> Please find further comments inline.
>>>
>>>     Juergen
>>> --
>>> Juergen Quittek        [e-mail]        Tel: +49 6221
> 90511-15
>>> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221
> 90511-55
>>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
> http://www.ccrle.nec.de
>>>
>>>
>>> --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote:
>>> > Randy,
>>> >
>>> > Few comments,
>>> >
>>> > I review the MIB and appears compelling respect to previous RFC
>>> >
>>> > Just one comment
>>> >
>>> >
>>> > (*) traceRouteCtlMiscOptions
>>> > It appears to me an uncanny object and rather implementations may
>>> > opt to extend the capabilities in the private branch, could leave
>>> > with that to avoid deprecation, of if there are field
>>> > implementations.
>>>
>>> Currently, the MODULE-COMPLIANCE clause traceRouteCompliance requests
>
>>> implementation of this object, but it may be implemented as read-only
>
>>> and returning always a value of zero, if there is not further
>>> semantics defined for it.  Do you suggest to completely remove the
>>> object or to state in the MODULE-COMPLIANCE clause that it does not
>>> need to be implemented?
>>>
>>> > Regardless of the additions to the MIB I apologize for the late
>>> > notice,
>>> >
>>> > Before sending a complete proposal and get your concept of the best
>
>>> > approach, below is the proposal  to add a simplified Compliance
>>> > statement for devices not requiring to keep constant status of
>>> > PING/TRACEROUTE operations, only remote operation per operator
>>> > request.
>>> >
>>> >
>>> > We are looking at your comments about the clear overlap in
>>> > draft-ietf-disman-remops-mib-v2-01.txt
>>> > With IPCDN draft
>>> > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mi
>>> > b-00.
>>> > txt ( currently out of date in IETF drafts site) which is clearly a
>>> > subset of the DISMAN-PING-MIB
>>> > Lectors refer to
>>> >
> http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818.
>>> > html
>>> >
>>> > Should the proposal below being include in the remops MIB or should
>
>>> > we update IPCDN cable gateway Tools MIB module to be just the
>>> > compliance statement outlined below?
>>>
>>> I doubt that it is a good idea to replicate large portions of the
>>> PING-MIB in the IPCDN cable gateway Tools MIB module, as it is done
>>> right now.
>>>
>>> > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null
>>> > named log" default entry for devices not supporting the named log
>>> > Named log is analog to disman remops draft for "OwnerIndex" and
>>> > "TestName"  where default entries are created (null owner, null
>>> > TestName) for a manager requested operation of PING/ TRACEROUTE,
>>> > NSLOOKUP, mostly for small foot-print devices with no network
>>> > monitoring role at the connectivity level as pretended with this
>>> > updated RFC.
>>>
>>> I don't think the remops MIB modules forbid null-named entries in the
>
>>> respective tables.  But currently the support of a read-write
>>> pingCtlRowStatus is mandatory.
>>>
>>> Is your concrete suggestion to add something like
>>>
>>>      OBJECT XXRowStatus
>>>          MIN-ACCESS read-only
>>>          DESCRIPTION
>>>           "Implementations may disallow the creation of named
>>> entries."
>>>
>>> with XX=pingCtl,traceRouteCtl,lookupCtl?
>>>
>>> > In summary A new Compliance Statement for small devices with no
>>> > monitoring capabilities to :
>>> >  1) remove the constant pulling and login information
>>> >  2) remove the test row creation
>>> >      - CTL* Results* tables only default entries (null owner, null
>>> > TestName)
>>> >  3) History* tables not required.
>>> > - New basicGroups to exclude History* objects and other objects
>>> > which are not relevant to the simplified
>>> >         system.
>>> >       - Create an additional set of Compliance statements to
>>> > require the new Groups and other objects Compliance
>>> >         requirements MIN-ACCESS clauses mainly
>>> >
>>> > Schema of the content of the new Compliance statement:
>>> >
>>> >  List of objects not to include in basicPingGroupOBJECT-GROUP
>>> > clause qnd/or hints for OBJECT Compliances:
>>> >   pingMaxConcurrentRequests -- remove
>>>
>>> Could also be read-only returning 1.
>>>
>>> >   pingCtlDataFill           -- remove or MIN-ACCESS read-only
> default
>>> > value is OK
>>> >   pingCtlFrequency          -- remove Only one test
>>>
>>> Could also be read-only returning 0.
>>>
>>> >   pingCtlType               -- remove or MIN-ACCESS read-only
>>> >   pingCtlByPassRouteTable   -- remove or MIN-ACCESS read-only
>>> >   pingCtlDSField            -- MIN-ACCESS read-only
>>> >   pingCtlStorageType        -- remove
>>> >   pingCtlRowStatus          -- SYNTAX RowStatus (notReady(2)
>>> > WRITE-SYNTAX RowStatus (active(1), notInService(3)
>>>
>>> Why don't you consider removing this object?
>>>
>>> >   pingCtlIfIndex            -- not to include
>>> >   pingProbeHistory*         -- not to include.
>>> >
>>> >   List of objects not to include in basicTraceRouteGroup
>>> > OBJECT-GROUP clause and/or hints for OBJECT Compliances:
>>> >   traceRouteMaxConcurrentRequests  -- remove
>>> >   traceRouteCtlType             -- remove or MIN-ACCESS read-only
>>> >   traceRouteCtlDSField          -- MIN-ACCESS read-only
>>> >   traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only
>>> >   traceRouteCtlIfIndex          -- not to include
>>> >   traceRouteCtlMiscOptions      -- not to include
>>> >   traceRouteCtlDontFragment     -- remove or MIN-ACCESS read-only
>>> >   traceRouteCtlInitialTtl       -- remove or MIN-ACCESS
>>> >   traceRouteCtlFrequency        -- remove only one test
>>> >   traceRouteCtlDescr            -- remove
>>> >   traceRouteCtlCreateHopsEntries -- remove HopsEntries not
> required.
>>> >   traceRouteCtlRowStatus        -- SYNTAX RowStatus (notReady(2)
>>> > WRITE-SYNTAX RowStatus (active(1), notInService(3)
>>> >   traceRouteCtlStorageType      -- remove
>>> >   traceRouteProbeHistory*         -- not to include.
>>> >
>>> >   List of objects not to include in basicLookupGroup OBJECT-GROUP
>>> > clause and/or hints for OBJECT Compliances:
>>> >   lookupMaxConcurrentRequests   -- remove
>>> >   lookupPurgeTime               -- remove
>>> >   lookupCtlRowStatus            -- SYNTAX RowStatus (notReady(2)
>>> > WRITE-SYNTAX RowStatus (active(1), notInService(3)
>>> >
>>> >
>>> > Best Regards
>>> >
>>> > Eduardo
>>> >
>>> > -----Original Message-----
>>> > From: Randy Presuhn [mailto:[e-mail]]
>>> > Sent: Monday, March 01, 2004 6:44 PM
>>> > To: [e-mail]
>>> > Subject: RE: [Disman] WG last call on
>>> > draft-ietf-disman-remops-mib-v2-01.txt
>>> >
>>> >
>>> >
>>> > Hi -
>>> >
>>> >> From: Eduardo Cardona <[e-mail]>
>>> >> Sent: Mar 2, 2004 9:25 AM
>>> >> To: Randy Presuhn <[e-mail]>, [e-mail]
>>> >> Subject: RE: [Disman] WG last call on
>>> >> draft-ietf-disman-remops-mib-v2-01.txt
>>> > ...
>>> >> One simple note, I tough last call was March 5th
>>> >
>>> > No, it was supposed to end March 2.  However, I'm not going to hand
>
>>> > it to our AD until I can be reasonably sure that it has received
>>> > adequate review.
>>> >
>>> >> We at Cablelabs are interested in adding a simplified compliance
>>> >> statement for ad-hoc procedure call instead of a user entry
>>> >> schecule entry, so an user can do a one time execution e.g PING
>>> >
>>> > It would have been nice to have learned of this earlier, rather
>>> > than during WG last call.
>>> >
>>> >> The draft we had is almost complete,
>>> >> Would be that an opportunity to add that? I can post that tomorrow
>
>>> >> in the list if compeling
>>> > ...
>>> >
>>> > I'd like to have this discussion sooner rather than later, so
>>> > please make your specific proposal as quickly as you can.  My
>>> > opinion as a technical contributor is that the case for these
>>> > changes would need to be fairly compelling if they would result in
>>> > the remote operations MIB cycling at proposed rather than advancing
>
>>> > to draft standard.  As working group chair, I want to ensure that
>>> > whatever course we take reflects WG consensus.  So, balancing the
>>> > need for bringing this to a conclusion with the need to ensure that
>
>>> > the technical issues are properly considered, I'll entertain
>>> > discussion of this issue ("ad hoc procedure call") until Friday
>>> > noon (Korean Time).  Shortly thereafter I'll make a call on whether
>
>>> > there is consensus to modify the draft regarding this specific
>>> > proposal.
>>> >
>>> > Randy
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
>
> _______________________________________________
> IPCDN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ipcdn
>
>







_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn