[ipcdn] Re: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt

[Juergen Quittek <[e-mail]>]

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: [phone]
NEC Europe Ltd.,       Network Laboratories        Fax: [phone]
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: [phone]
>> NEC Europe Ltd.,       Network Laboratories        Fax: [phone]
>> 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-mib-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:[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