RE: MIB OID assignement

["C. M. Heard" <heard@pobox.com>]

On Mon, 28 Nov 2005, Wijnen, Bert (Bert) wrote:
> So the question we are faced with (I think) is if we stop at
> criterion 2 above, or if we believe that ultimately something
> may get developed in IETF based on experience with this doc, in
> case we are at criterion 3 above.
> 
> I think the doc does not provide the items listed in criterion 4.

Sounds fair.

I was thinking that the situation was similar to the SMIng stuff:

3780 SMIng - Next Generation Structure of Management Information. F.
     Strauss, J. Schoenwaelder. May 2004. (Format: TXT=141049 bytes)
     (Status: EXPERIMENTAL)

3781 Next Generation Structure of Management Information (SMIng)
     Mappings to the Simple Network Management Protocol (SNMP). F.
     Strauss, J. Schoenwaelder. May 2004. (Format: TXT=112267 bytes)
     (Status: EXPERIMENTAL)

which are an archival record of a proposal that did not ultimately
lead to a standards-track document.  That's also what
draft-glenn-mo-aggr-mib-07.txt does.

It is admittedly rather unlikely that either RFCs 3780/3781 or
draft-glenn-mo-aggr-mib-07.txt will actually lead to a
standards-track spec, but it is conveivable, and the IETF does
retain change control of both.  So experimental seems OK.  But I
could see an argument for informational, too.

> I think I agree that if we stick to informational, then maybe
> the MIB module should go under Glenn's own companies vendor OID.

I agree with that, but in that case it should be expected that
change control would be in Glenn's hands (or his company's), not
the IETF's.

Mike