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

From: Juergen Quittek <[email-masked]>
Date: Wed, 16 Jun 2004 23:46:59 +0200

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-masked]        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-masked]>
>> To: "Eduardo Cardona" <[email-masked]>; "Randy Presuhn" <[email-masked]>; <[email-masked]>
>> Cc: "Ipcdn List (E-mail)" <[email-masked]>
>> 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-masked]        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-masked]]
>> > Sent: Monday, March 01, 2004 6:44 PM
>> > To: [email-masked]
>> > Subject: RE: [Disman] WG last call on
>> > draft-ietf-disman-remops-mib-v2-01.txt
>> >
>> >
>> >
>> > Hi -
>> >
>> >> From: Eduardo Cardona <[email-masked]>
>> >> Sent: Mar 2, 2004 9:25 AM
>> >> To: Randy Presuhn <[email-masked]>, [email-masked]
>> >> 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
>> >
>> >
>> >
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 17 Jun 2004 11:55:10 -0700

Hi -

As disman WG chair, I'm announcing the start of a two-week working group
last call on the Remote Operations MIBs.  The latest version is available at
http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-02.txt
Our objective is to advance to Draft Standard.  Off-line I've received
word that that we will have at least two implementation reports.  I'm
fairly sure there are more out there, so please speak up if you know of
an implementation.

I'm CC:ing the ipcdn WG mailing list, since we've incorporated some
additional conformance material to meet (I hope) their needs.  Please
send any comments, including "I've read it and don't object" comments,
to the disman WG mailing list at [email-masked].

The last call will end on Friday, July second, 2004.  If anyone is committed
to reviewing it but would need additional time, let me know and I'll see what
we can work out.

Randy