Subject: [MIB-DOCTORS] Volunteers for MIB review

From: Benoit Claise <[email-masked]>
Date: Tue, 22 May 2012 00:21:37 +0200

Dear all,

[restricting the email to just mib-doctors]

First of all, my apologies for not following up the email from Adrian on 
March 29th, subject "Heads-up MIB review impending".
This concerns the MIB doctor review of 
https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/

Now, how do we share the load amongst MIB doctors?
- round robin?
- we keep track of history and ask a specific person (like Tina Tsu does 
for OPS-DIR). I could do that job
- I just an email to the list, asking for a volunteer?
- something else?

Please let me know.
Also, we really need a reviewer for 
https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/

Regards, Benoit.

---

From: David Harrington <[email-masked]>
Date: Tue, 22 May 2012 01:43:43 -0400

Hi Benoit,

I will try to help you understand how the MIB Doctors work, so you know.
You might also ask Dan and Bert how they handled this.

I am a member of the secdir, opsdir, tsvdir, and MIB Doctors directorates.
Secdir reviews are pretty easy; you check whether they have documented
considerations of authentication, authorization, integrity,
confidentiality, and replay. Occasionally there is something a bit more in
depth about specific vulnerabilities, but not often.
Opsdir is pretty easy; you check whether external operational needs have
been addressed, such as DNS, network management, and so on have been
mentioned.
Tsvdir is pretty easy; you check whether congestion has been addressed
(TCP good; UDP bad), whether timers and message replay and port
assignments have been discussed appropriately.

A MIB review is huge in comparison; You might know all this already, but
I'll mention it just for comparison with other review team requirements.
You need to check the MIB module syntax using tools like libsmi.
Then the real work starts. You need to check for database design
anomalies, such as deletion anomalies, addition anomalies, fate-sharing
between tables, persistence, etc.
You need to study the technology being managed to determine whether
appropriate counters have been defined, and tables of relevant
information, etc.
You need to consider implementation issues, such as whether the
information is readily available to put into a MIB; Fast-track switching
can have a big effect. You need to consider whether updating counters will
impact performance of the managed technology; you need to consider code
footpriint, and so on.
You need to consider the guidelines for review that discuss how to check
boilerplates, type expansions, naming conventions, security
considerations, textual conventions, proper handling of references, etc.
A solid MIB review can take days, and the MIB Doctor stays assigned to the
document while it goes through the approval process.

The Directorates wiki page shows nineteen MIB Doctors.
For nine of the names, I don't remember the last time I saw them at an
IETF or an email from them to an IETF list (Frank Strauss? Glenn Waters?
Steve Waldbusser? Dave Perkins? Sharon Chisholm? Harrie? Mike Heard?)
Another four or five are still active in IETF, but almost never do MIB
reviews because they're focused on other work (Andy, John Flick, Shawn, me)
I don't know why we keep the list of nineteen on this page.

So realistically, you have an active MIB Doctor review team of about six
people (Bert, Juergen, Mike MacFaden, Randy, Joan, and Orly)
And they realistically need to pick and choose which modules they review
because they are so time-intensive.

I am not volunteering for this MIB module, since I don't have the time to
learn about manet.
I recommend trying to grow the MIB Doctors, but I expect this will be very
hard.
You might try to recruit some operators who use SNMP tools to provide a
"usefulness" design review.

I don't know if there is anyway to reduce the burden of a MIB review.
Tools seem a likely approach.
The libsmi tools are good, but can only analyze fairly static features
(syntax). 
Maybe another round of tools usable by MIB writers could help analyze
table relationships and check for counter persistence text.
If you can get agreement from the MIB Doctors to formalize some additional
guidelines, further checking might be able to be automated.
But part of the problem of MIB reviews is that there are already so many
rules to follow and review.
Getting tools like libsmi accepted by the tools team, worked on during
code sprints, or adding automated MIB review to datatracker functionality
might help.
(There are other syntax checkers/process checkers that could also be good
added to tools team responsibility, such as mime type registration syntax
and completeness.)

I know I haven't helped solve the problem of a lack of volunteer for the
nhdp mib, but hopefully you better understand why nobody is stepping
forward.

-- 
David Harrington
[email-masked]
+1-603-828-1401

On 5/21/12 6:21 PM, "Benoit Claise" <[email-masked]> wrote:

>_______________________________________________
>MIB-DOCTORS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 22 May 2012 09:17:48 +0200

Hi Benoit.

Last week, and also coming weeks I am pretty busy, so I could
not step up. Yet I did a very quick browse through the document,
but this was basically to do a first assessment if the MIB is
in really bad state (in which case there will be a lot of work
and a long period during which the work may come back) or in
reasonable shape, in which case the work is far less and may not
take too long to come to closure.
This MIB document seems quite reasonable at first sight.
But still it will take some time to do a proper review.

I also saw DBH comments/explanation.
I think it would be good if we could do such in depth reviews as
Dave suggests, but at the other hand, I feel that it is subject
matter experts that need to worry about a lot of the topics
about design and impact on the technology.
I know that when I do a review, that I often dive somewhat into the
documents that describe the technology, and then sometimes that raises
questions that I will pose and that causes follow up etc.

When I was AD, and when/if I couldn't get reviewers (although at the
time we had a larger base of *active* MIB doctors), then I would do
the basic checks myself, make sure SYNTAX was OK, make sure there
were no gaping holes. That sometimes (actually often) took quite some
time. Yep... I understand.

But even if you get to this stage, I am not sure you absolutely have to
go into as much details as Dave suggests. There are (after all) so many
different technologies in IETF that it is kind of impossible to
understand them all in great detail.
I guess that is up to you to decide.

Maybe Dan has some perspective here as well.

Bert

On 5/22/12 12:21 AM, Benoit Claise wrote:
> First of all, my apologies for not following up the email from Adrian on March 29th, subject "Heads-up MIB review impending".
> This concerns the MIB doctor review of https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/
>
>
> - we keep track of history and ask a specific person (like Tina Tsu does for OPS-DIR). I could do that job
> Also, we really need a reviewer for https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/
>
> Regards, Benoit.
>
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 May 2012 10:17:12 +0200

Hi Benoit, 

My perspective is very close to Bert's and David's. Indeed, proper MIB
Doctor review requires good understanding or fast learning of the
technology that is supposed to be managed, and this takes time. I would
argue that you need this also for a proper security or OPS review, but
the argument is marginal for what we discuss here. For that reason while
I was on the IESG I asked my fellow ADs to require MIB doctor review
BEFORE the IETF LC, so that the search for a MIB Doctor starts earlier
than the moment the Last Call sand-clock (typically two or four weeks)
is runing. You may want to do the same. 

Concerning the MIB Doctors team composition. I did a clean-up a few
years ago and the remaining members were those who committed to continue
to be active with a couple of exceptions - Frank Strauss was never an
active reviewer but he contributed the libsmi, Mike Heard and Andy
Bierman said that they did not have the time for reviews but would stay
on the list and answers questions occasionally, which they did now and
then and this was useful. You may want to do another round of questions,
see who wants to stay active, who opts out. Harrie actually answered at
least one call for reviewers in the last year, you can also add my name
to the list, with eight active reviewers the situation is not that bad,
this will lead to 2-3 reviews each year. You can of course try to
recruit new participants. 

You may move from a asking for volunteers model to a round-robin
assignment, or at least use such an algorithm if a volunteer does not
show up after a few days. 

Concerning the style of the reviews, I am again agreeing to what Bert
and David say, and I would add that in my reviews I also ask about the
need to reduce complexity hence the number of objects so that the agent
code can be implemented and the manager can access easily the objects
essential to the day-to-day operations. 

Concerning this MIB module - Bob Cole consulted with me, maybe also with
other MIB doctors while in design phase, so there was some level of
exposure and discussions prior to the MIB module hitting the IESG. 

I hope this helps. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:mib-doctors-
> [email-masked]] On Behalf Of Bert Wijnen (IETF)
> Sent: Tuesday, May 22, 2012 10:18 AM
> To: Benoit Claise
> Cc: MIB Doctors (E-mail); Ron Bonica
> Subject: Re: [MIB-DOCTORS] Volunteers for MIB review
> 
> Hi Benoit.
> 
> > First of all, my apologies for not following up the email from
Adrian
> on March 29th, subject "Heads-up MIB review impending".

---

From: Benoit Claise <[email-masked]>
Date: Tue, 22 May 2012 12:25:27 +0200

Dan, Bert, Dave,

Thanks for your feedback.
Let me try to decompose the problem into multiple smaller ones.

1. Require MIB doctor review BEFORE the IETF LC.
I'll take that action item to stress this my fellow AD.
This would allow some more time for planning the review,.

2. Finding a volunteer earlier on the process.
I'll take the action item to follow up sooner in the process.

3. Learning a new technology, specifically from IETF RFCs and drafts, is 
time consuming (I've been learning that these days ;-) ), and could be a 
blocking factor to volunteer to review MIB modules.
Let me propose something: let's request, part of the MIB doctor, a 
transfer of information webex, with the document authors and/or WG 
chairs and/or responsible AD. Basically, the message would be: "you want 
to benefit from the MIB-doctors expertise, teach them first your 
technology, and how you would like to manage it!"
Personally, when I received a 1/2h introduction on a new technology, the 
documents were way more easier and time-consuming to read. I could 
enforce this new rule.

4. MIB doctor team composition: clean-up required?
It would be ideal to only have active reviewers on the list. However, if 
all the participants are contributing one way or the other (libsmi, 
answering questions occasionally), we should keep everybody in the list.
If someone would like to opt-out, let me know.

5. Growing the MIB doctor team.
If you have some names or mailing list in mind, let me know.
I will send this request internally in my company: we have our internal 
MIB-police team. Maybe, we'll get one extra person...

6. Fair distribution of load
I could keep a history of the distribution, if that helps.

Please share your thoughts.

Regards, Benoit.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 May 2012 12:57:21 +0200

Hi Benoit, 

See in-line. 

Regards,

Dan

> From: Benoit Claise [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2012 1:25 PM
> To: Romascanu, Dan (Dan)
> Cc: Bert Wijnen (IETF); MIB Doctors (E-mail); Ron Bonica
[[DR]] I would be cautious to ask too much upfront, people may be
discouraged, we do not want that to happen. Rather work on a
case-to-case mode, some people will already have some knowledge, other
need to ask, some may get help without bothering you, let us use AD
escalation only when requests for private transfer of information are
not answered.

> If someone would like to opt-out, let me know.
[[DR]] Maybe you should ask folks who did not participate in any
discussion in the last few years whether they are still interested to be
on the list. I did not see any contribution from Steve Waldbusser or
Sharon Chisholm for many years. If you send them such messages either a.
the address bounces and you take them out, or b. they say they opt out,
the same, or c. they say they want to stay and maybe even get a review
from time to time.

> MIB-police team. Maybe, we'll get one extra person...
 [[DR]] Maybe Bob Cole could be recruited. Is Randy Presuhn a MIB
Doctor? Worth asking him if he is not. 

> >> But even if you get to this stage, I am not sure you absolutely
have
> > to
> >>> - we keep track of history and ask a specific person (like Tina
Tsu
> >> does for OPS-DIR). I could do that job

---

From: Benoit Claise <[email-masked]>
Date: Wed, 23 May 2012 00:59:03 +0200

> Steve Waldbusser? Dave Perkins? Sharon Chisholm? Harrie? Mike Heard?)
Sharon Chisholm <[email-masked]>, Mike Heard <[email-masked]>, and 
Shawn Routhier <[email-masked]> are actually not part of 
the MIB-doctor mailer.
So the http://www.ietf.org/iesg/directorate/mib-doctors.html is another 
thing I'll have to change.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 23 May 2012 00:25:23 +0200

Hi Dan,

See in-line.
> escalation only when requests for private transfer of information are
Understood. Let's not formalize the process, but let's keep that as an 
option.

> Sharon Chisholm for many years.
Let me follow up.
> If you send them such messages either a.
>   [[DR]] Maybe Bob Cole could be recruited.
Bob kindly accepted.
> Is Randy Presuhn a MIB
And Randy is already a MIB doctor.

We now have three new MIB doctors, and I'm still waiting for an answer 
from Chris Elliott.
I believe that the "Growing the MIB doctor team" is now solved unless 
you have some other people in mind.

Regards, Benoit.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 May 2012 07:43:17 +0200

> [email-masked]] On Behalf Of Benoit Claise
> Sent: Wednesday, May 23, 2012 1:59 AM
> To: David Harrington

...

> thing I'll have to change.

[[DR]] Mea culpa, I forgot about that page and did not update it for
ages. Probably three years at least, as Bert is no longer with AL for
quite a while, and Nortel does not exist for quite a while. Shawn agreed
to continue on MIB Doctors last time I exchanged mails with him, you may
want to confirm this. I did not communicate with Glenn and Sharon for a
while, I do not know if the Nortel addresses work any longer. 

Congratulations for the successful recruiting campaign, and welcome to
the new members!

Regards,

Dan

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 23 May 2012 08:12:36 -0400

Guys,

	A process question.  How do we get access to SmicNG?  Is there a
web-based version we can use or are MIB Doctors given a license to run it
locally?

	Also, do we keep some internal web page of who is reviewing what to keep
track of review status?

	Finally, what is the process for how reviews are assigned, processed and
released? Forgive me for asking. If there is a FAQ, please point me at it.
*)

	--Tom

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 23 May 2012 14:25:46 +0200

The author of SMICng, David Perkins, is to be asked.
I would think that it would in fact be great for him
to make it at least available for MIB doctors to do
IETF MIB review/checking.

I have asked him several times in the past (when I was AD,
but also later). I believe Dan has asked him too.

But as far as I know, he has not done so yet.

Last email address I have for him: [email-masked]
Bert

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 23 May 2012 08:31:22 -0400

I guess the next logical question then would be to ask, if there is such
reluctance to let this community use SMICng gratis (which his clearly
non-profit organization), should we standardize on a different (more
readily available) MIB compiler for our checks?  Apologies if this has
been already discussed here. I am just trying to sort this out so I don't
have to figure it out after I am assigned something to review, and
discover that I cannot compile it - or that we are all using different MIB
compilers and get slightly different results.

	--Tom

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 May 2012 14:53:59 +0200

> compilers and get slightly different results.

smilint (part of the libsmi package) is open source, packaged for many
Unix distributions, some people even run a Windows cross-compiled
version. There is also a web frontend:

http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/

There are certain things smicng warns about that smilint does not
detect and vice versa. Since smilint is open source, if something
important is missing, there is a way to add it.

The libsmi package also has a tool smidiff that compares to revisions
of a MIB modules. This is needed less frequently but once you have to
look at a revision, it is neat to have a tool that checks whether many
of the SMIv2 update rules have been followed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 May 2012 06:45:52 -0700

> compilers and get slightly different results.

I have not used SMICng in 10 years.
I like smilint much better.
It is easier to use and it is open-source code.

> 	--Tom

Andy

>
> On 5/23/12 8:25 AM, "Bert Wijnen (IETF)"<[email-masked]>  wrote:
>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 23 May 2012 09:49:22 -0400

>It is easier to use and it is open-source code.

	I personally agree with you. I really like Smilint. However, is this the
consensus of MIB doctors, and is what we should use then for reviews?

	--Tom

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 May 2012 10:57:48 -0700

Hi -

> From: "Thomas Nadeau" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: "MIB Doctors (E-mail)" <[email-masked]>
> Sent: Wednesday, May 23, 2012 6:49 AM
> Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use
...
> consensus of MIB doctors, and is what we should use then for reviews?

I think *not* standardizing on a particular toolset is the right way to go.
The differences in what the various tools "catch" (rightly or wrongly)
keep us honest, especially about the greyer parts of the specifications.

(And yes, on those rare occasions when I do a review, I generally use
Smilint.)

Randy

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 23 May 2012 15:53:44 -0400

>(And yes, on those rare occasions when I do a review, I generally use

	I appreciate your point about coverage, but the issue is getting
access to SmicNG for all of us. Unless reviews are divided up so that at
least one person 
has access to it, then it will be difficult to get that coverage.

	One thing that might be useful even if we can't get access to running
SmicNG locally, is perhaps a web-based version that is restricted to just
IETF MIB Doctors. That way we install it once, but only this closed user
group gets access to run it.  That might be acceptable to the author?

	--Tom

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 May 2012 17:33:02 -0700

Hi -

...
> has access to it, then it will be difficult to get that coverage.

Just as I don't see a need to standardize on *a* tool, I also don't see
a need to *require* reviewers to use multiple tools.  The technology is
mature enough that, for purposes of a review, whatever tool the reviewer
happens to choose should be sufficient.  From my perspective, compiler
coverage isn't a significant issue here.

Randy

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 24 May 2012 11:24:42 +0900

Hi,
   It is not really a need to standardize on *a* tool. The RFC
editors use SmicNG. So, at some stage, generally the final
stage, questions on errors/warnings from SmicNG do arise. These
require some extra cycles of processing among editors/authors/
ADs.

Glenn
PS. One instance of warning not caught in smilint, but caught
     in SmicNG and not suppressible by using -C0F and option "Z"
     of SmicNG is:
     W: f(rfc6475b.mi2), (435,8) Sequence"PMip6MagHomeNetworkPrefixEntry"
     and Row "pmip6MagHomeNetworkPrefixEntry" should have related
     names.

(2012/05/24 9:33), Randy Presuhn wrote:
> Hi -
>
>> From: "Thomas Nadeau"<[email-masked]>
> ...

---

From: David Harrington <[email-masked]>
Date: Wed, 23 May 2012 22:30:54 -0400

Smilint is my preferred checker.
I used to use smicng as a secondary, but stopped when I changed computers.
Smicng DOES provide slightly different warnings, not all of which reflect
MIB Doctor consensus.

-- 
David Harrington
[email-masked]
+1-603-828-1401

On 5/23/12 9:49 AM, "Thomas Nadeau" <[email-masked]> wrote:

>>>>> web-based version we can use or are MIB Doctors given a license to
>>>>>run
>>>>> it
>>>>> locally?
>>>>>
>>>>> released? Forgive me for asking. If there is a FAQ, please point me
>>>>>at
>>>>> it.
>>>>> *)
>>>>>
>>>>> 	--Tom
>>>>>

---

From: David Harrington <[email-masked]>
Date: Thu, 24 May 2012 03:41:25 -0400

Hi,

DaveP gave me a license for my MIB Doctor review work a few years ago.
I think he is willing to give licenses to any MIB Doctor that requests it.
I am not sure what his email is currently.

SMICng has not been updated in years.
I wouldn't hold your breath waiting for Dave to produce a web-based
version.
I have a vague recollection that Dave sold the product to somebody (Chris
Wellens??), so Dave might be constrained in what he can offer.

Maybe Dave can be convinced to grant a license to MIB Doctors.
Maybe we can convince the tools team to produce a web front-end restricted
to MIB Doctors, or a locked web-front-end can be produced during a code
sprint.
If the RFC Editor uses SMICng, maybe we can get that made accessible to
MIB Doctors (with appropriate licensing from Dave).

-- 
David Harrington
[email-masked]
+1-603-828-1401

---

From: David Harrington <[email-masked]>
Date: Thu, 24 May 2012 03:56:55 -0400

Hi,

I agree with Randy that which tool you use is not that important.
What is important is that reviewers are fairly consistent.

The new recruits should be aware of RFC4181 (and RFC4841).
Those are the basic criteria we expect all incoming MIB modules to meet.
To a degree, these guidelines were produced to prevent "reviewer pet
peeves" from causing vastly different review requirements from different
reviewers.
The MIB Doctors need some consistency in what is required.
Smilint captures many of these guidelines.
SMICng is a good tool, but was produced before the MIB Doctors agreed to
these guidelines, and some SMICng warnings do not represent MIB Doctor
consensus.

I recommend the recruits look at these guidelines from early MIB modules:
"To be consistent with IAB directives and good engineering practices,
   an explicit attempt was made to keep this MIB module as simple as
   possible.  This was accomplished by applying the following criteria
   to objects proposed for inclusion:

   1. Start with a small set of essential objects and add only as
      further objects are needed.

   2. Require that objects be essential for either fault or
      configuration management.

   3. Consider evidence of current use and/or utility.

   4. Limit the total number of objects.

   5. Exclude objects that are simply derivable from others in this or
      other MIB modules.

   6. Avoid causing critical sections to be heavily instrumented.  The
      guideline that was followed is one counter per critical section
      per layer.
"

The MIB Doctors have not produced guidelines on a bunch of issues we look
for, such as database normalization and object/table persistence.
I recommend the recruits look over past reviews to see the types of
problems that are found, and corrected.

-- 
David Harrington
[email-masked]
+1-603-828-1401

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 May 2012 10:11:23 +0200

On Thu, May 24, 2012 at 03:41:25AM -0400, David Harrington wrote:
 
> SMICng has not been updated in years.  I wouldn't hold your breath
> waiting for Dave to produce a web-based version.

My usage of SMICng dates back to last century ;-) and back then I
found SMICng difficult to use because I had to produce files to tell
SMICng how to compile a MIB module properly. If this is still the
case, I likely would not use it even if I would get a free license or
a web frontend because writing those files was something I really
disliked doing.

/js

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 24 May 2012 08:39:04 -0400

>to MIB Doctors, or a locked web-front-end can be produced during a code

	That'd be ideal.

>MIB Doctors (with appropriate licensing from Dave).

	Yes. That is what I was thinking; just extend the license. Although it
would seem that its already appropriate for us to use it on behalf of the
RFC Editor IMHO, and making it web-accessible but in a locked/restricted
manner to this closed list of people is also appropriate.

	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 May 2012 10:12:10 -0700

> a web frontend because writing those files was something I really

+1

The reason I pushed so hard to standardize the .yang and .yin file extensions
in YANG was based on all the tedious renaming I had to do with MIB modules.
Just about every MIB tool expects a different file naming convention.

Andy

---

From: Michael MacFaden <[email-masked]>
Date: Thu, 24 May 2012 22:03:10 -0700

I forwarded this email to David, will find out shortly.

Mike
On May 24, 2012 12:41 AM, "David Harrington" <[email-masked]>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 25 May 2012 15:02:00 +0200

Hi,

Note that [email-masked] 
<https://www.ietf.org/mailman/options/mib-doctors/dperkins--at--dsperkins.com> 
is subscribed to this mib-doctors.
A few days ago, I have asked Dave, on that email address, if he still 
wants to help with mib-doctors. No answer so far...

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 25 May 2012 15:07:37 +0200

Thanks Dave for that email.

One more thing I would add is that the MIB-doctors email archives are 
available online.
We should advertise this. That's a great source of information for 
anybody who wants to write a MIB module.

Regards, Benoit.

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Fri, 25 May 2012 15:13:08 +0200

Inline

----- Original Message ----- 
From: "Benoit Claise" <[email-masked]>
To: "David Harrington" <[email-masked]>
Cc: "MIB Doctors (E-mail)" <[email-masked]>
Sent: Friday, May 25, 2012 3:07 PM
Subject: Re: [MIB-DOCTORS] some advice to the new recruits

> anybody who wants to write a MIB module.

I guess it is. BUT.....
would you ever try to go through such an archive if you are 
writing a MIB module??? I doubt many (any?) people will
have the patience to do that.

Nevertheless, sure we can advertise it.

And, I'd like to be pleasantly surprised.

Bert

---

From: David Harrington <[email-masked]>
Date: Fri, 25 May 2012 10:36:01 -0400

Hi,

I don't agree this would be a good archive for people wanting to learn to
write a MIB.

This email list is for MIB Doctors.
The discussion tends to be about reaching agreement amongst the MIB
Doctors on some esoteric point.
This is where MIB Doctors go when they need help finding/interpreting the
rules (such as the maximum value of a PEN).
This is where MIB Doctors go if they don't like a design choice in a MIB
module and want to know if other MIB Doctors agree, or to get alternate
design suggestions.
A person trying to learn to write a MIB will be totally lost and confused
by these discussions.
I think making the MIB reviews public could be a learning experience, but
readers would need to sift through a lot of irrelevant stuff to find
relevant nuggets. RFC4181 already gives them most of the nuggets we'll
find in a MIB Doctor review.
A MIB Doctor wiki might be a good way to capture additional nuggets from
new reviews.
Compare, for example,
http://trac.tools.ietf.org/area/app/trac/wiki/TypicalAppsAreaIssues, and
http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues.

The [email-masked] might be a better archive to check.
This is where people writing a MIB are encouraged to seek help, so the
focus is on advising MIB writers.
But it does tend to be about solving problems MIB writers run into, rather
than a from-scratch tutorial on how to write a MIB.

Offering a Sunday tutorial on MIB writing, and/or producing a
MIB-Doctor-written design guide would be far more helpful.
Templates for writing MIB documents are already available on the tools
page and from the RFC Editor.
We've had quite a few discussions of a design guide (for things like table
normalization, persistence, etc.) but haven't reached a point where
somebody was willing to volunteer to hold the pen.
A MIB design wiki might be a good way to start such a design guide,
without demanding dedicated authorship from a MIB Doctor.

There are multiple books available on MIBs; I find Dave Perkins' book
"Understanding SNMP MIBs" most useful as a MIB Doctor (available on
Amazon).
 
-- 
David Harrington
[email-masked]
+1-603-828-1401

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 25 May 2012 10:47:55 -0700

Hi -

> From: "David Harrington" <[email-masked]>
...
...

Very much agreed.  I also think we need to be very careful about well-intended
efforts to provide more general guidance.  What might seem in the abstract to
be sound advice can sometimes for specific use cases produce  bad results.
For example, a lofty-sounding recommendation to normalize can be counter-
productive if the design goal is to minimize round-trips for multiple query types
and the available mechanism is GetNext / GetBulk.  The work of a conscientious
MIB Doctor involves careful judgement and knowledge of the "bags of tricks"
used in the Rube Goldberg world of MIB design, not just following checklists.

Randy

---

From: David Harrington <[email-masked]>
Date: Fri, 25 May 2012 14:16:44 -0400

Agreed. 
I am using "normalize" very loosely in this discussion. I really mean
fate-sharing, et al.

-- 
David Harrington
[email-masked]
+1-603-828-1401