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

Jurgen, 
Thanks for your reply,

See comments below and inline <edo></edo>


-----Original Message-----
From: Juergen Quittek [mailto:[email protected]] 
Sent: Monday, April 26, 2004 2:11 AM
To: Eduardo Cardona; Randy Presuhn; [email protected]
Cc: Ipcdn List (E-mail)
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.

<edo>
I understand the desire of having normalized process and applications
that may tune themselves by just reading static values (read-write with
read-only compliances) as a subset of the full module compliance

It is also understood that some vendors later may complain of 'static'
requirements as a waist of resources in terms of memory and code. Just
my note in the disjunctive of the implementer vs the  manager
approaches.


I always though the AGENT-CAPABILLITIES is the best tool for minimize
devices implementations plus adding a robust layer in the manager side
to create the vendor, compliance/specific "what if cases", but not very
used I guess by current tools.

We Will be ok with the disman group decision in this matter,  
 
</edo>


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?

<edo>
I see more an augmentation or RowPointer to an enterprise MIB subtree
(from the POV of OPS MIB guidelines, and flexible enough for vendor
extensions); which may imply deprecation and a new object for the
RowPointer case.

I just noted that "opaque" objects are not very common in new MIBs,
Can go either with read-only or deprecation.
</edo>

> 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-0
> 0.
> 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.

<edo>
The question was really if 
The PING-MIB is changed to just define a 'minimalCompliance' for IPCDN
cable Gateway
Or
draft-ietf-disman-remops-mib-v2-01.txt will include the
'minimalCompliance'

Not to continue the MIB module overlapping.
</edo>


> 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?

<edo>
I agree it does not prohibit the nul entry, Just for the minumal
compliance no need to 'create' the null entry any time -  Just a default
entry - , then the read-only complience will be ok

The only question remaining in our side is:
1) If RowStatus NotReady will be an indication that not all needed
parameters ( Dest Addr) are propoerly setup(?)
Or 
2) The pingCtlAdminStatus Description may need an error code for both
Full compliance and minimal compliance to address the SNMP SET when the
entry is 'notReady'.

Something around: 
"... returns error 'inconsistentVelue'/'wrongValue' -Advice?- when
trying to set to 'enabled' if not previously specified a valid
pingCtlTargetAddress"          

The last onr (2) I think will be enough for removing RowStatus in the
minimal Compliance ( not include object in the minimal group) or define
it as read-only SYNTAX

</edo>

> 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.

<edo>
Agree...
</edo>

>   pingCtlDataFill           -- remove or MIN-ACCESS read-only default
> value is OK
>   pingCtlFrequency          -- remove Only one test

Could also be read-only returning 0.

<edo>
Agree...
</edo>

>   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)

<edo>
Agree... See more for pingCtlAdminStatus above           
</edo>
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
>
>
>