[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIB II or RFC1213 and its successors
On Sat, 17 Apr 2004, Wijnen, Bert (Bert) wrote:
> The RFC-Editor wants to know which documents they should
> tag as related and/or obsoleting or updating which.
>
> I think it was all triggered by a question from Dave Harrington.
> Dave has already commented and co[n]tributed to the below.
>
> Anyway, this is what I have documented sofar.
> Any comments or suggestions for change?
>
> I think it would be good if these relationships are
> expressed in the RFC indexes.
>
> >
> > First, RFC1213 is a STD level.
> >
> > RFC2011,2012 and 2013 are at PS level.
Likewise RFC 2096. Note that all of these documents will soon
be replaced by other documents (also to be published at PS):
draft-ietf-ipv6-rfc2011-update-08.txt 08-Apr-2004 14:01 259K
draft-ietf-ipv6-rfc2012-update-06.txt 20-Feb-2004 09:10 54K
draft-ietf-ipv6-rfc2013-update-02.txt 20-Nov-2003 13:39 37K
draft-ietf-ipv6-rfc2096-update-07.txt 12-Feb-2004 14:39 81K
One thing that might be considered for each of the above drafts is
to have the abstract and introduction mention that it updates RFC
1213 (the documents do mention the RFCs that they obsoleted but
do not mention RFC 1213). Then the normal procedures for updating
rfc-index.txt would keep the relationships in sync. In the case of
2096-update and 2012-update this would have to be done during AUTH-48
since they've already been approved and are in the RFC Editor's queue.
> > RFC2863 is at DS level
Don't forget RFC 2864 (that's the companion document that covers
the ifInvertedStackTable and has the implementation requirements
for the ifStackTable). It is as PS level.
> > RC3418 is at STD level
> >
> > RFC2011 updates the ip group in RFC1213,
> > so it updates the objects under { mib-2 4 }
> > it also updates the icmp group in RFC1213
> > so it updates the objects under { mib-2 5 }
RFC 2096 replaces the ipRouteTable (which consists of
the objects under { mib-2 4 21 }, i.e., { ip 21 }) by
new objects under { mib-2 4 24 }, i.e., { ip 24 }.
Note that its recently-approved replacement will add
more objects under { mib-2 4 24 } and will deprecate
the existing object under { mib-2 4 23 }.
> > RFC2012 updates the TCP group in RFC1213
> > so it updates the objects under { mib-2 6 }
> > RFC2013 updates the UDP gropup in RFC1213
> > so it updates the objects under { mib-2 7 }
> > RFC2863 updates the interfaces group in RFC1213.
> > so it updates the objects under { mib-2 2 }
RFC 2864 should probably be mentioned in conjunction with
RFC 2863 in this context.
> > RFC3418 updates the system group in RFC1213
> > so it updates the objects under { mib-2 1 }
> > it also updates the SNMP group in RFC1213
> > so it updates the objects under { mib-2 11 }
> >
> > Further, RFC1213 has these groups
> >
> > - at group which is { mib-2 3 }
> > not sure if it is still used anywhere, but in any event
> > it is already "deprecated".
> > - egp group which is { mib-2 8 }
> > I also doubt that this is still used anywhere
> > - cmot group, which is { mib-2 9 }
> > it was already historical at RFC1213 publication time
> > - transmission group, which is { mib-2 10 }
> > This is just an anchor in RFC1213
> >
> > Of course, mib-2 itself was defined in RFC1213 as the anchor/root
> > for all standards track MIB modules. The various groups under
> > mib-2 (as you can see above) were/are defined in RFC1213.
> >
> > But RFC2578 has taken over some of the role of defining the mib-2
> > root and some of the groups (still in use).
> >
> > RFC2578 sort of also updates RFC1213 in that
> > it defines the root mib-2
> > it defines the transmission group as { mib-2 10 }
> >
> > In summary:
> >
> > - quite a few docs contains updates or pieces of replacements for
> > RFC1213. I am not even 100% sure I have listed all of it above,
> > I think I am close, and if you want I can check some more.
> > - Although RFC1213 is at full STD, most of the things that are
> > currently in use and implemented, are those as defined in the
> > newwer MIB modules, even though those are at PS or DS level.
> > - At some point we may want to write an RFC that deprecates or
> > obsoletes those pieces from RFC1213 that we believe are no longer
> > used.
> > - At some time we may want to make RFC1213 HISTORIC.
> > Not sure if we should do that before the all the replacements
> > reach at least DS or maybe even STD level.
One problem is that many of our existing documents still cite RFC
1213 as a normative reference, e.g., for the system group. Some
cite both old and new documents using language such as
MIB II [RFC1213], as extended by [RFC2863], [RFC2864], and [RFC3418]
accommodates these cases by appropriate use of the system group and
the interfaces group. [ ... ]
These are probably OK. However, there are many other cases where the
newest documents are not cited (only RFC 1213 is), and we probably don't
want to move RFC 1213 to HISTORIC until that's all been sorted out.
> > If you want, I can bring this up in the MIB Doctor mailing list to
> > see if we have any consensus on what would be wise.
> >
> > Hope this helps.
> > Bert
Mike