Subject: Re: [manet] [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04

From: Randy Presuhn <[email-masked]>
Date: Mon, 20 Apr 2015 11:14:50 -0700 (GMT-07:00)

Hi -

>From: "Cole, Robert G CIV USARMY CERDEC (US)" <[email-masked]>
>Sent: Apr 20, 2015 6:29 AM
>To: Randy Presuhn <[email-masked]>, "[email-masked]" <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04
...
>If OK with you, I would first like to address your question
>on the utility of the module.  If that question cannot be answered
>in the positive, the rest of my efforts on fixing the module would
>be moot.

Don't give too much weight to my comments, but I'd hope
this sort of question would be worked through by any working
group considering the development of any MIB module.  I think
a single, fully-worked-through example of how this would be
used with an implementation of RFC 2981 to do something
useful would be sufficient.  If the intent is to provide
detailed history of samples resulting in a DISMAN-EVENT-MIB
trigger, I think you need some additional magic to somehow
synchronize the sampling performed by this module and that
performed by DISMAN-EVENT-MIB.  If it's to provide other
context (i.e., the data recorded here is for some object
other than the one causing the trigger), the issue of
potential timing skew should be made explicit.

>I'll write up a justification for the module, to be placed
>in the introductory text.

There's some already there, but it seems to be the rationale
for DISMAN-EVENT-MIB rather than for *this* module.  AFAICT,
this module isn't really going to reduce polling traffic or
permit operation with intermittant connectivity.  Rather, it
*looks* like its function is to record a sampling history to
provide debugging/contextual information for a trigger notification.

> Only when it passes (on not) your approval and that of the WG,
> then I'll proceed with the rest of the comments and modifications.
> Does this seem reasonable?

The WG's voice is the one that matters.  If the WG is convinced
it's useful after working through the details of a use case,
I'll be happy.

Randy

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 21 Apr 2015 12:19:05 -0700 (GMT-07:00)

Hi -

>From: Benoit Claise <[email-masked]>
>Sent: Apr 21, 2015 1:07 AM
>To: Randy Presuhn <[email-masked]>, [email-masked]
>Cc: [email-masked], [email-masked]
...
>This is inappropriate to ask for a MIB doctor review for a MIB module 
>that doesn't even compile.
...

I wrote:

>> This is *not* a full MIB doctor review; in my opinion some
...

Sorry if that misled anyone.
The reasons I CC-ed the [email-masked] list as well as
the [email-masked] list were:

  1) to let folks outside of [email-masked] know that *someone*
     had looked at this

  2) to make sure that no one had a problem with my suggestions
     regarding how the work could fit in with disman infrastructure
     and accepted MIB practice.

I think the timestamping issues in particular are of general
concern, so if there is consensus among practitioners regarding
the best way to deal with those issues beyond what we did with 
the Log MIB (the nlmLogTime and nlmLogDateAndTime hack)
it would be good to be able to make a specific recommendation to
the manet folk.  That would be a lot more helpful than my comments,
which amount to "this is busted."

Kinda tangentially...
   (3) Given the current emphasis on Netconf, and this module
       is primarily about configuring functionality, is anyone
       prepared to argue that this MIB module should instead be
       a Yang module and managed via Netconf protocol?

I think it would be a terrible fit, but that's not my problem.

Randy