Another thing to consider here is the point at which code points are
assigned.
In a lot of cases we have had incompatibility resulting from experimental
code points being used and then changed when the final draft is agreed.
For some spaces code points are scarce and it is necessary to conserve. But
for most there is no real harm done by wasting a few. And in the case of
OIDs and URIs the code space is infinite.
On Mon, Jun 21, 2010 at 4:33 PM, Michael StJohns
<mstjohns(_at_)comcast(_dot_)net>wrote:
I think its a good idea to readdress this. Part of the issue with the
current system, is that there is both no great benefit to advancing a
standard to the next level for the advocates, and no real downside to not
advancing it. In many cases, having gone through the pain of getting to RFC
status, one is unwilling to place their body in the firing line again. Any
change to the system should consider the real world implications and try and
add in the appropriate carrots and sticks.
One side note - MIBs. MIBs by their nature are actually collections of
mini-standards - the objects. Once an object is defined and published in a
non-transitional document (RFC), the OID associated with that object is
pretty much stuck with that definition. And that permanance tends to
percolate up to the collection of objects that make up a MIB.
I'd suggest only a single standards level for a MIB - stable - tied to a
specific conformance statement. Obviously, this is sort of a sketch of an
idea, but given the immutability of each MIB object, advancing a MIB is
pretty much impossible unless there are absolutely no changes.
Mike
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf