RE: Updating the MIB boilerplate

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

Juergen answers me:

> 
> Bert> Well, I have had many many complaints that the extensive
> Bert> boilerplate we have used for the last few years is "just
> Bert> bureaucratic overhead".
> 
> Yes. And I would agree with that.
> 
Good to hear that we're at least "in sync" on this one.

> Bert> Now... was you question intended to ask if that ref to 2570bis
> Bert> should be normative?
> 
> Bert> Or is the question intended to ask if we should add the SNMPv3
> Bert> documents in the boiler plate (with normative references)?
> 
> I just wanted to point out that we previously regarded documents as
> being normative which we now do not consider normative anymore. This
> again raises the question what "normative" really means.
> 
> There are two options. First, our previous interpretation of what is a
> normative reference for a MIB was broken and we now fix it. The other
> option is that I just to not understand what normative versus
> informative really means. ;-)
> 
Well, first we just had "references". 
The RFC-editor, when ready to publish a new RFC, and when seeing a ref
to an I-D, would often ask: is I-D-xxx a normative ref or informative.
In case of normative, the RFC-to-be would be kept hostage till the
I-D that was referenced in a normative way was also ready to be
published as an RFC.
For informative references, the RFC-Editor just puts "work in progress"
in the rfc-to-be and publishes.

So The RFC-Editor then started to ask if the references could be split,
for various reasons, some of which I understood to be:
- the authors should think about what is and is not normative
- the rfc-editor will have an easier time to make the disctiction
  when in the editing process
- normative refs MUST be stable.
- normative references are those references that point to another doc
  that MUST be (at least partially) be understood (or implemented)
  in order to understand (implement) the doc that makes the reference.
as a byproduct, we find some interesting things in our process
- can a doc in fact advance to say STD when some normative refs are
  still at a lower level on the stds track.
- how easy is it to actaully decide if some reference is normative or
  not?  

So when we first needed to tell MIB editors/authors to make the
split, we tried to come to a split of the references we all had. We
did this in fact on this mailing list (if I remember well).
And we had some interesting dicussions did we not. And it seems
we're still having them.

I think the split we made for the "old" boiler plate is fine.
I also think it is OK to discuss if we indeed still need all that
boiler plate. One can probably argue for either side. 
I would like the SNMP/MIB community to come to sonsensus as to
what we want to do as soon as we see the new SNMPv3 RFCs.

Seems we're growing to a consensus to limit the boiler-plate.

> BTW, we all know that some MIB design decisions are influenced by the
> target protocol and not the SMI. The most typical example are message
> size constraints and their implications. But since dealing with this
> is more a MIB writers fun, one can argue that the boilerplate might a
> bit oversimplify the world by just claiming the SMIv2 to be normative.
> 
> Summary: Now that I had my fun, I can live just fine with your
> proposed new short boilerplate.
> 
Hope the above explains a bit how we got here and helps us get to
consensus soon.

Bert
> /js
> 
> -- 
> Juergen Schoenwaelder    
<http://www.informatik.uni-osnabrueck.de/schoenw/>