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

Thanks for the comments, 
I will wait as you for hearing from authors
One note below

...
> (*) 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. 

any suggested changes?

In the revision history : ( if option is deprecation), something like 
The MIB object traceRouteCtlMiscOptions is being deprecated,
implementations willing to extend the traceRoute functionality with
proprietary parameters can follow standard procedures of extending entry
tables (e.g. AUGMENTS  [RFC2578])

If willing to have a direct parameters reference in the CTL entry,
similar to the existing traceRouteCtlMiscOptions, uses a new object with
RowPointer syntax or an ID pointing to a private table entry,
( in some cases it may simplify the configuration model if the vendor
feature is just a flag or a common parameter set for all
owners/testNames, pointing the test to the same parameter definition,
policy, etc.
  
As I said, it seems to me to be quite unusual object definition, Due the
already RFC status could be left as is, or change it for one of the
above options or any other alternative. 

Eduardo


-----Original Message-----
From: Randy Presuhn [mailto:[email protected]] 
Sent: Tuesday, March 02, 2004 5:12 PM
To: [email protected]
Cc: Ipcdn List (E-mail)
Subject: RE: [Disman] WG last call on
draft-ietf-disman-remops-mib-v2-01.txt


Hi -

> From: Eduardo Cardona <[email protected]>
> Sent: Mar 3, 2004 2:04 AM
> To: Randy Presuhn <[email protected]>, [email protected]
> Cc: "Ipcdn List (E-mail)" <[email protected]>
> Subject: RE: [Disman] WG last call on 
> draft-ietf-disman-remops-mib-v2-01.txt
...

Thanks for the comments!

...
> (*) 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. 

any suggested changes?

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

Both seem reasonable.  If we can include a "basic" compliance statement
to suit your needs without jeopardizing progression, that seems like an
option that I would prefer as a technical contributor, though I admit
that it is not a strong preference and would like to hear other
opinions.

> 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 have no problem with this in principle, and think it would be really
nice if we can verify that the MIB definitions do not preclude operating
this way.

> In summary A new Compliance Statement for small devices with no 
> monitoring capabilities to :
...

I'd phrase it a bit differently.  Rather than "remove" information, I
think the proposal is to ensure that it can function meaningfully using
a small subset of the objects.

I'd like to hear from Juergen (and others) regarding the details of the
proposed compliance material, especially with regard to whether there
are any details in the current object definitions that would prevent
this usage.

Randy