RE: 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-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:[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
>
>
>