RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Held for Document Update (2)

RFC 3815, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", June 2004

Source of RFC: mpls (rtg)

Errata ID: 3261
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Cohn
Date Reported: 2012-06-18
Held for Document Update by: Adrian Farrel

Section 3.5.9 says: 

   The mplsLdpFecTable is a table which contains FEC (Forwarding
   Equivalence Class) information.  Each entry/row represents a single
   FEC Element.  There is also an LDP LSP FEC Table, mplsLdpLspFecTable,
   which associates FECs with the LSPs.

It should say:

   The mplsFecTable is a table which contains FEC (Forwarding
   Equivalence Class) information.  Each entry/row represents a single
   FEC Element.  There is also an LDP LSP FEC Table, mplsLdpLspFecTable,
   which associates FECs with the LSPs.

Notes:

Since draft-06 the mplsLdpFecTable has been renamed mplsFecTable

Errata ID: 3262
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Cohn
Date Reported: 2012-06-18
Held for Document Update by: Adrian Farrel

Section 4 says: 

     mplsFecLastChange OBJECT-TYPE
         SYNTAX  TimeStamp
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
             "The value of sysUpTime at the time of the most
             recent addition/deletion of an entry
             to/from the mplsLdpFectTable or
             the most recent change in values to any objects
             in the mplsLdpFecTable.

             If no such changes have occurred since the last
             re-initialization of the local management subsystem,
             then this object contains a zero value."
        ::= { mplsFecObjects 1 }

It should say:

     mplsFecLastChange OBJECT-TYPE
         SYNTAX  TimeStamp
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
             "The value of sysUpTime at the time of the most
             recent addition/deletion of an entry
             to/from the mplsFecTable or
             the most recent change in values to any objects
             in the mplsFecTable.

             If no such changes have occurred since the last
             re-initialization of the local management subsystem,
             then this object contains a zero value."
        ::= { mplsFecObjects 1 }

Notes:

Since draft-06 mplsLdpFecTable has been renamed to mplsFecTable

Status: Rejected (1)

RFC 3815, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", June 2004

Source of RFC: mpls (rtg)

Errata ID: 227
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Kirkham
Date Reported: 2005-02-13
Rejected by: Adrian Farrel
Date Rejected: 2010-08-23

MplsFecEntry is defined as:

      MplsFecEntry ::= SEQUENCE {
          mplsFecIndex               IndexInteger,
          mplsFecType                INTEGER,
          mplsFecAddrType            InetAddressType,
          mplsFecAddr                InetAddress,
          mplsFecAddrPrefixLength    InetAddressPrefixLength,
          mplsFecStorageType         StorageType,
          mplsFecRowStatus           RowStatus
      }

It should say:

      MplsFecEntry ::= SEQUENCE {
          mplsFecIndex               IndexInteger,
          mplsFecType                INTEGER,
          mplsFecAddrPrefixLength    InetAddressPrefixLength,
          mplsFecAddrType            InetAddressType,
          mplsFecAddr                InetAddress,
          mplsFecStorageType         StorageType,
          mplsFecRowStatus           RowStatus
      }

Notes:



Because the OID assignments are:

mplsFecAddrPrefixLength - mplsFecEntry.3
mplsFecAddrType - mplsFecEntry.4
mplsFecAddr - mplsFecEntry.5
--VERIFIER NOTES--
After discussion with an author (Joan Cucchiara), a MIB Doctor (Mike Heard), and an MPLS MIB expert (Tom Nadeau), we conclude that no change is required.

In the words of Mike Heard...

While this may be a poor practice, I don't think it actually
violates RFC 2578. As far as I can see, the only thing it
actually says is this:

7.10. Mapping of the OBJECT-TYPE value
...
(2) If the object corresponds to a conceptual row, then at least one
assignment, one for each column in the conceptual row, is present
beneath that object. The administratively assigned name for each
column is derived by appending a unique, positive sub-identifier to
the administratively assigned name for the conceptual row.

which does not put any ordering constraints on the sub-identifiers.

Unless there is something that I have missed, it seems to me that
this is not actually an erratum.

Report New Errata



Advanced Search