IP Forwarding Table MIB
RFC 4292
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the Yes position for Bert Wijnen |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Alex Zinin |
|
2006-04-14
|
07 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2006-04-14
|
07 | Amy Vezza | [Note]: 'RFC 4292' added by Amy Vezza |
|
2006-04-11
|
07 | (System) | RFC published |
|
2004-02-23
|
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2004-02-20
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2004-02-20
|
07 | Amy Vezza | IESG has approved the document |
|
2004-02-20
|
07 | Amy Vezza | Closed "Approve" ballot |
|
2004-02-20
|
07 | Thomas Narten | State Changes to Approved-announcement to be sent from IESG Evaluation::Revised ID Needed by Thomas Narten |
|
2004-02-19
|
07 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to Yes from No Objection by Bert Wijnen |
|
2004-02-19
|
07 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen |
|
2004-02-11
|
07 | Alex Zinin | [Ballot Position Update] Position for Alex Zinin has been changed to No Objection from Discuss by Alex Zinin |
|
2004-02-11
|
07 | (System) | New version available: draft-ietf-ipv6-rfc2096-update-07.txt |
|
2004-01-29
|
06 | (System) | New version available: draft-ietf-ipv6-rfc2096-update-06.txt |
|
2003-12-04
|
07 | Amy Vezza | Removed from agenda for telechat - 2003-12-04 by Amy Vezza |
|
2003-12-04
|
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
|
2003-12-04
|
07 | Alex Zinin | [Ballot discuss] 2. inetCidrRouteDiscards The text says: > inetCidrRouteDiscards OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS … [Ballot discuss] 2. inetCidrRouteDiscards The text says: > inetCidrRouteDiscards OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of entries in the inetCidrRouteTable which > were chosen to be discarded even though they are valid. > One possible reason for discarding such an entry could > be to free-up buffer space for other routing entries." What does this counter really represent? Are discarded entries still reported in inetCidrRouteTable, but are not present in the actual FIB, or are they also not present in the inetCidrRouteTable? In other words, discarded by whom and at what point? Also, is it supposed to count both v4 and v6 discarded routes or discarded routes in that instance, whatever it includes? 3. inetCidrRoutePolicy The text says: > inetCidrRoutePolicy OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Represents the general set of conditions that would > cause the selection of one multipath route (set of next > hops for a given destination) over another (referred to > as policy). The value { 0 0 } shall be used for the > default policy or if no particular policy applies." > ::= { inetCidrRouteEntry 4 } 2096 had ToS-based policy description that wasn't really used. What is this description trying to define? Policy of next-hop selection in the ECMP case or route arbitration when multiple protocols provide a route to the same prefix? Also, which "policy" is meant here: > inetCidrRouteEntry OBJECT-TYPE > SYNTAX InetCidrRouteEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A particular route to a particular destination, under a > particular policy. 4. inetCidrRouteIfIndex The text: > inetCidrRouteIfIndex OBJECT-TYPE > SYNTAX InterfaceIndex > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The ifIndex value which identifies the local interface > through which the next hop of this route should be > reached." > ::= { inetCidrRouteEntry 7 } I assume that this MIB would be used by vendors to report the routing table as well, not strictly the forwarding table. In this case, it would be possible to have routes with only next-hop addresses, but no ifIndex, e.g. BGP or static routes. Should the description say that value 0 means no interface specified? |
|
2003-12-04
|
07 | Alex Zinin | [Ballot Position Update] New position, Discuss, has been recorded for by Alex Zinin |
|
2003-12-04
|
07 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for by Allison Mankin |
|
2003-12-04
|
07 | Bill Fenner | [Ballot Position Update] New position, Recuse, has been recorded for by Bill Fenner |
|
2003-12-04
|
07 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for by Jon Peterson |
|
2003-12-04
|
07 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for by Harald Alvestrand |
|
2003-12-03
|
07 | Steven Bellovin | [Ballot comment] Network map data is useful for far more than denial of service. I'd just delete that phrase. |
|
2003-12-03
|
07 | Steven Bellovin | [Ballot Position Update] New position, No Objection, has been recorded for by Steve Bellovin |
|
2003-12-03
|
07 | Bert Wijnen | [Ballot discuss] More or less serious (enough of those to take a DISCUSS): - For those objects where you have a syntax of InetAddressType/InetAddress … [Ballot discuss] More or less serious (enough of those to take a DISCUSS): - For those objects where you have a syntax of InetAddressType/InetAddress it seems to me that a value of "dns" or the type does not make sense. I discussed this with Mike HEard (who reviewed the MIB before as MIB doctor), and he sugegst to add this to the OBJECT-TYPE DESCRIPTION clause(s): "Only those address types that may appear in an actual routing table are allowed as values of this object." To then also make that clear in the MODULE-COMPLIANCE, it would be good to add all of the InetAddressType objects in this MIB module in OBJECT clauses specifying that only ipv4(1), ipv6(2),and in some cases unknown(0) address types are required, and further that only those address types actually supported by the implementation need to be allowed. That would then also result in OBJECT clauses to limit the size of the InetAddress objects to (0 | 4 | 16). - The REVISION clause of the MODULE-IDENTITY macro should also describe that the version-neutral inetCidrRouteTable replaces the IPv4 version-specific ipCidrRouteTable and related object groups and conformance statements. That is namely a pretty serious change that should be listed. It should also be listed in section 7. - a statement is needed (required by RFC2578) in the DESCRIPTION clause of ipForwardCompliance stating that it was deprecated in favor of ipForwardFullCompliance and ipForwardReadOnlyCompliance. - also statements are needed in the DESCRIPTION clause of ipForwardCidrRouteGroup stating that it was deprecated in favor of inetForwardCidrRouteGroup. - inetCidrRouteDest and inetCidrRouteNextHop The description clause should include something aka: "The type of this address is determined by the value of the inetCidrRouteDestType object." That is what RFC3291 prescribes in for uses of TC InetAddress. - There is a documentation issue as well (as raised by Dan Romascanu, another MIB doctor). That is: what does' MIB-II support' mean nowadays. This doc talks about RFC1213 mib in bullet 4) in section 3. But draft-ietf-ipv6-rfc2012-update-04.txt does much better. In its 'Relationship with other MIBs' section, it documents the relationship with the MIB module ancestors very well. Such a section helps a lot for implementers and users of the MIB. It is missing from draft-ietf-ipv6-rfc2096-update-05.txt. Nits (that editors may want to address at same time): - Margarets contact info is incorrect - WG mailing list info can be fixed now - I see in inetCidrRouteDestType DESCRIPTION "The type of the inetCidrRouteDest address, as defined in the InetAddress MIB [RFC3291]." Citation within description clause of an OBJECT-TYPE are not good. They get lost when the MIB module is extracted. Would be OK to do (RFC 3291), but the best way to reference it would be a REFERENCE clause. It occurs twice I believe. - I also wonder about inetCidrRouteDest: Any assignment (implicit or otherwise) of an instance of this object to a value x MUST be rejected if the bitwise logical-AND of x with the value of the mask formed from the corresponding instance of the inetCidrRoutePfxLen object is not equal to x." What I wonder about is "Any assignment... of an instance of this object.". Cause this object does not get instantiated. It is an index object. Similar issue with DESCRIPTION clause of inetCidrRoutePfxLen. Maybe it is just my English. If you think the above is OK, then fine. My personal text would be the same in both objects, more aka: The values for the index objects inetCidrRouteDest and inetCidrRoutePfxLen must be consistent. When the value of inetCidrRouteDest is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object inetCidrRoutePfxLen MUST be equal to x. If not, then the idex pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests." - For the ReadOnlyCompliance, this is OK: OBJECT inetCidrRouteStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." But would it would be better to do: OBJECT inetCidrRouteStatus SYNTAX { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." - Section 7 should probably also say that the inetCidrRouteTable retains the logical structure of the table it replaces in order to allow easy upgrade of existing IPv4 implementations to the version-independent MIB (that's what the "minimal changes" stuff in the DESCRIPTION clause of the latest revision means). |
|
2003-12-03
|
07 | Amy Vezza | [Ballot Position Update] New position, Discuss, has been recorded for by Amy Vezza |
|
2003-12-02
|
07 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie |
|
2003-12-02
|
07 | Ted Hardie | [Ballot comment] I think the Editor's contact info in ipForward MODULE-IDENTITY and the Author's addresses section are out of date (right, Margaret?) |
|
2003-12-02
|
07 | Ted Hardie | [Ballot Position Update] New position, Undefined, has been recorded for by Ted Hardie |
|
2003-12-02
|
07 | Margaret Cullen | [Ballot Position Update] New position, Recuse, has been recorded for by Margaret Wasserman |
|
2003-12-01
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for by Russ Housley |
|
2003-11-25
|
07 | Ned Freed | [Ballot comment] Nits: No IPR boilerplate Idle musing: This document, like so many other MIB documents, has a largely useless table of … [Ballot comment] Nits: No IPR boilerplate Idle musing: This document, like so many other MIB documents, has a largely useless table of contents: There's a few entries for pages 1-7 and 30-33 but nothing for the majority of the specification, which of course is the MIB itself. I wonder... Wouldn't it be useful to have a way of adding TOC entries for the various sections within the MIB itself? Would it be worth a note to see if XML2RFC could be extended this way? Mind you, I only find TOCs useful when looking at printed versions of the document, and the intersection of MIBs and scanning printed specifications might be so small as not to be worth it. Comments? |
|
2003-11-25
|
07 | Ned Freed | [Ballot Position Update] New position, No Objection, has been recorded for by Ned Freed |
|
2003-11-25
|
07 | Thomas Narten | Placed on agenda for telechat - 2003-12-04 by Thomas Narten |
|
2003-11-25
|
07 | Thomas Narten | State Changes to IESG Evaluation from Waiting for Writeup by Thomas Narten |
|
2003-11-25
|
07 | Thomas Narten | [Ballot Position Update] New position, Yes, has been recorded for Thomas Narten |
|
2003-11-25
|
07 | Thomas Narten | Ballot has been issued by Thomas Narten |
|
2003-11-25
|
07 | Thomas Narten | Created "Approve" ballot |
|
2003-11-24
|
07 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
|
2003-11-04
|
07 | Amy Vezza | Last call sent |
|
2003-11-04
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2003-11-04
|
07 | Thomas Narten | State Changes to Last Call Requested from Publication Requested by Thomas Narten |
|
2003-11-04
|
07 | Thomas Narten | Last Call was requested by Thomas Narten |
|
2003-11-04
|
07 | (System) | Ballot writeup text was added |
|
2003-11-04
|
07 | (System) | Last call text was added |
|
2003-11-04
|
07 | (System) | Ballot approval text was added |
|
2003-09-11
|
07 | Natalia Syracuse | Draft Added by Natalia Syracuse |
|
2003-08-29
|
05 | (System) | New version available: draft-ietf-ipv6-rfc2096-update-05.txt |
|
2003-06-30
|
04 | (System) | New version available: draft-ietf-ipv6-rfc2096-update-04.txt |
|
2003-06-20
|
03 | (System) | New version available: draft-ietf-ipv6-rfc2096-update-03.txt |
|
2002-11-07
|
02 | (System) | New version available: draft-ietf-ipv6-rfc2096-update-02.txt |
|
2002-08-28
|
01 | (System) | New version available: draft-ietf-ipv6-rfc2096-update-01.txt |
|
2002-07-02
|
00 | (System) | New version available: draft-ietf-ipv6-rfc2096-update-00.txt |