RE: [ipcdn] Re: WG last call ondraft-ietf-disman-remops-mib-v2-01.txt Part1
"Eduardo Cardona" <[email protected]>
| Newsgroups | gmane.ietf.disman,gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
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
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 ( 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.
- also does "sucessive" means consecutive?
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)
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.
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:
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
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."
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."
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
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
a) Will the compliance statement should say that a 'notReady' is
automatically set to 'active' when all fields (specially when
pingCtlTargetAddress is set?) would that be valid request? -not included
in the state diagram of RowStatus TC-
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
SYNTAX RowStatus { notReady(3), active(1)}
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
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)}
>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)
- 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.
DISMAN-NSLOOKUP-MIB
No issues.
Thanks
Eduardo
-----Original Message-----
From: Juergen Quittek [mailto:[email protected]]
Sent: Wednesday, June 16, 2004 3:47 PM
To: Randy Presuhn; [email protected]
Cc: [email protected]
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 [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.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" <[email protected]>
>> To: "Eduardo Cardona" <[email protected]>; "Randy Presuhn"
>> <[email protected]>; <[email protected]>
>> Cc: "Ipcdn List (E-mail)" <[email protected]>
>> 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 [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.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 basicPingGroup OBJECT-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:[email protected]]
>> > Sent: Monday, March 01, 2004 6:44 PM
>> > To: [email protected]
>> > Subject: RE: [Disman] WG last call on
>> > draft-ietf-disman-remops-mib-v2-01.txt
>> >
>> >
>> >
>> > Hi -
>> >
>> >> From: Eduardo Cardona <[email protected]>
>> >> Sent: Mar 2, 2004 9:25 AM
>> >> To: Randy Presuhn <[email protected]>, [email protected]
>> >> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn