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

["Randy Presuhn" <[e-mail]>]

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