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

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. 


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? 

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.


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
  pingCtlDataFill           -- remove or MIN-ACCESS read-only default
value is OK
  pingCtlFrequency          -- remove Only one test
  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)  
  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