RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (1)

RFC 5060, "Protocol Independent Multicast MIB", January 2008

Source of RFC: pim (rtg)

Errata ID: 1449
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2008-06-14
Verifier Name: Adrian Farrel
Date Verified: 2011-09-28

Section 5, pg.49 ff. says:

...

pimSGIJoinPruneState OBJECT-TYPE
    SYNTAX     INTEGER {
|                 noInfo (1),
|                 join (2),
|                 prunePending (3)
               }
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "The state resulting from (S,G) Join/Prune messages
|           received on this interface.  This corresponds to the state
|           of the downstream per-interface (S,G) state machine in the
|           PIM-SM and PIM-DM specification."
    REFERENCE "RFC 4601 section 4.5.3 and RFC 3973 section 4.4.2"
    ...

...

It should say:

pimSGIJoinPruneState OBJECT-TYPE
    SYNTAX     INTEGER {
                  noInfo (1),
                  join (2),
                  prunePending (3),
                  pruned (4)
               }
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "The state resulting from (S,G) Join/Prune messages
            received on this interface.  This corresponds to the state
            of the downstream per-interface (S,G) state machine in the
            PIM-SM and PIM-DM specification."
    REFERENCE "RFC 4601 section 4.5.3 and RFC 3973 section 4.4.2"
    ::= { pimSGIEntry 4 }

Notes:

A fourth state is added to allow for the reporting of pruned state in PIM-DM.

Status: Held for Document Update (2)

RFC 5060, "Protocol Independent Multicast MIB", January 2008

Source of RFC: pim (rtg)

Errata ID: 1445
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2008-06-14
Held for Document Update by: Adrian Farrel
Date Held: 2011-09-28

Section 5, pg.12 says:

pimInvalidRegisterAddressType
    ...
    DESCRIPTION
            "The address type stored in pimInvalidRegisterOrigin,
            pimInvalidRegisterGroup, and pimInvalidRegisterRp.
            [...]

It should say:

pimInvalidRegisterAddressType
    ...
    DESCRIPTION
|           "The type of the addresses stored in
            pimInvalidRegisterOrigin,
            pimInvalidRegisterGroup, and pimInvalidRegisterRp.
            [...]

Notes:

The Original Text is misleading. No "address type [is] stored" in
the columnar objects pimInvalidRegisterOrigin,
pimInvalidRegisterGroup, and pimInvalidRegisterRp; addresses are!
The addres type for these addresses is stored in
pimInvalidRegisterAddressType -- as its name says.

Type changed to Editorial

Errata ID: 1446
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2008-06-14
Held for Document Update by: Adrian Farrel

Section 5, pg.20 says:

pimInterfaceTrigHelloInterval
    ...
    DESCRIPTION
       ...
       the 'Trigered_Hello_Delay' timer ...

It should say:

pimInterfaceTrigHelloInterval
    ...
    DESCRIPTION
       ...
       the 'Triggered_Hello_Delay' timer ...

Notes:

Typo yields invalid variable name / reference to the PIM-SM spec.

Status: Rejected (2)

RFC 5060, "Protocol Independent Multicast MIB", January 2008

Source of RFC: pim (rtg)

Errata ID: 1447
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2008-06-14
Rejected by: Adrian Farrel
Date Rejected: 2011-09-28

Section 5, pg.32 ff. says:


Notes:

The description clauses of many columnar objects in the
PIM (*,G) State Table are underspecified:
If an object is "used with" a specific variant of PIM,
what is the desired behavior for other variants?
- shall the object be instantiated or not?
- if yes, what's the default / substitute value in this case?
- shouldn't such defaults be listed in DEFAULT clauses ?

Similar deficiencies also exist in the descriptions of objects
in other MIB tables in this MIB module.
--VERIFIER NOTES--
I don't see this as underspecified at all. In fact, objects like pimSGPimMode
and pimStaticRPPimMode are very specific in only supporting a limited range of
modes for the entire table. In effect, if another mode is in use, the table
cannot be used by definition.

Errata ID: 1448
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2008-06-14
Rejected by: Adrian Farrel
Date Rejected: 2011-09-28

Section 5, pg.47/48 says:

pimSGUpstreamPruneState OBJECT-TYPE
    SYNTAX     INTEGER {
 |                forwarding (1),
                  ackpending (2),
                  pruned (3)
               }
    ...
    DESCRIPTION
            "Whether the local router has pruned itself from the tree.
            This corresponds to the state of the upstream prune (S,G)
|           state machine in the PIM-DM specification.  This object is
|           used only by PIM-DM."

Notes:

The DESCRIPTION clause says: "This object is used only by PIM-DM."
Does this mean: "This object is only instantiated for PIM-DM." ?
Otherwise, the alternative:
noinfo(0),
should perhaps be allowed in the SYNTAX clause and be the DEFAULT.

Similar issues exist for the subsequent columnar objects,
pimSGUpstreamPruneLimitTimer, pimSGOriginatorState,
pimSGSourceActiveTimer, and pimSGStateRefreshTimer.

Also, there's no hint in the RFC why the other applicable
timers, GraftRetryTimer and OverrideTimer have not been
modeled in this MIB module.
--VERIFIER NOTES--
There are two issues in this Erratum...

1. "This object is only used..."

I interpret this to mean that an attempt to read the object in
other cases would return an error. Thus I don't see a problem
with the current text, and reject this part of the Erratum

2. "other timers are not modelled" Specifically:

GraftRetryTimer - I see pimInterfaceGraftRetryInterval
OverrideTimer - I see pimInterfaceOverrideInterval

The question is: why can't I see how the timer is running?
This looks like function that could have been added to the
MIB module, but was not.

However, someone who wants this function can add if they
feel inspired by revising the module or writing a new one.

Report New Errata



Advanced Search