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

Hi -

I still haven't heard any comments on the proposals below.
*Please* let me know what you think, so we can wrap this up!

Randy

> From: "Randy Presuhn" <[email protected]>
> To: <[email protected]>
> Cc: "Ipcdn List (E-mail)" <[email protected]>
> Sent: Tuesday, March 02, 2004 5:11 PM
> 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
>