RE: Revising RFC 1264

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

W.r.t.
> 2. MIBs. The document introduces a dependency between the MIB
>    and the protocol specs:
>     PS : MIB written in an I-D
>     DS : MIB is at PS level
>     STD: MIB goes together with the spec
> 
>    The first thing would be to make the MIB optional for extensions
>    and use common sense to make sure the charter includes the MIB work
>    if needed.
> 
>    For base protocol specs, the meta question is whether we really
>    want to sync these two so much. Are we doing this for other specs?
>    If not, maybe we shouldn't for routing either, and just use common
>    sense too. (Data point: 2026 does not require this)
> 
Well... 
- My view is that protocols/technologies should be manageable
- So it should be considered from the beginning and not as
  an afterthought
- We've seen too many times that various WGs do not care about 
  writing MIB documents... and so that is why we get VERY BAD
  ones... because they are always done after the fact, the real
  skilled people rarely contribute and some side-people tend to
  write the MIB docs and those get very little (if any) review
  by the technology experts.
- So I would rather even have a MIB go out as PS at the same time 
  that the base doc gets out as PS. That will make the technology
  experts pay attention.
- Given the report from the last 2 years of OPS and NM people and
  also the report from the IAB NM Workshop, we could relax the
  requirements for MIB modules in that if the WG decides they
  only want to write one for monitoring, that that is OK.

Bert