errata logo graphic

Found 7 records.

Status: Verified (4)

RFC3973, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", January 2005

Source of RFC: pim (rtg)

Errata ID: 3271

Status: Verified
Type: Technical

Reported By: Joseph Weinstein
Date Reported: 2012-06-28
Verifier Name: Adrian Farrel
Date Verified: 2012-08-22

Section 4.5.1 says:

if StateRefreshCapable(I) == TRUE
         set PT(S,G) to largest active holdtime read from a Prune
         message accepted on I;

It should say:

if StateRefreshCapable(I) == TRUE
         set PT(S,G,I) to the Holdtime from an active Prune received on
         interface I. The Holdtime used SHOULD be the largest active one
         but MAY be the most recently received active Prune Holdtime.

Notes:

It is not clear what is meant by the "largest active holdtime", and in any event sec. 4.4.2.3 specifies a slightly different rule:

Send State Refresh(S,G) out interface I
The router has refreshed the Prune(S,G) state on interface I.
The router MUST reset the Prune Timer (PT(S,G,I)) to the Holdtime
from an active Prune received on interface I. The Holdtime used
SHOULD be the largest active one but MAY be the most recently
received active Prune Holdtime.

Additionally...
No macro PT(S,G) is defined anywhere in the RFC; the reference appears to be to P(S,G,I).

The concept of an "active Prune" is not defined in this RFC, but simply means those prunes which have not expired.


Errata ID: 967

Status: Verified
Type: Editorial

Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04

Section 4.6.1 says:

   assert_metric
   my_assert_metric(S,G,I) {
     if (CouldAssert(S,G,I) == TRUE) {
       return spt_assert_metric(S,G,I)
     } else {
       return infinite_assert_metric()
     }
   }

It should say:

   assert_metric
   my_assert_metric(S,G,I) {
     if (CouldAssert(S,G,I) == TRUE) {
       return spt_assert_metric(S,I)
     } else {
       return infinite_assert_metric()
     }
   }

Notes:

In Section 4.6.1, spt_assert_metric(S,I) is defined to have two
parameters, not three.

from pending [error in data transfer corrected 2/15/08.]


Errata ID: 968

Status: Verified
Type: Editorial

Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04

Section 4.6.1 says:

   assert_metric
   spt_assert_metric(S,I) {
     return {0,MRIB.pref(S),MRIB.metric(S),my_addr(I)}
   }

It should say:

   assert_metric
   spt_assert_metric(S,I) {
     return {MRIB.pref(S),MRIB.metric(S),my_addr(I)}
   }

Notes:

In Section 4.6.1, assert_metric is defined to be a 3-tuple, not a
4-tuple.


Errata ID: 969

Status: Verified
Type: Editorial

Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04

Section 4.6.1 says:

   assert_metric
   infinite_assert_metric() {
     return {1,infinity,infinity,0}
   }

It should say:

   assert_metric
   infinite_assert_metric() {
     return {infinity,infinity,0}
   }

Notes:

In Section 4.6.1, assert_metric is defined to be a 3-tuple, not a
4-tuple.


Status: Rejected (3)

RFC3973, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", January 2005

Source of RFC: pim (rtg)

Errata ID: 970

Status: Rejected
Type: Technical

Reported By: Mark Doll
Date Reported: 2007-05-16
Rejected by: Adrian Farrel
Date Rejected: 2011-09-04

 

Remark: In Section 4.7.10 it says, the 4th value is "The Rendezvous Point Tree
bit. Set to 0 for PIM-DM. Ignored upon receipt."

It should say:

[not submitted]

Notes:

from pending
--VERIFIER NOTES--
This Erratum is complaining that this RFC defines a bit, but then marks it as outside the scope of this document.

While this is bad practice, it does not break any rules and is not grounds for an Erratum. It might be justifiable e use of the bit if anyone is interested.

Furthermore, the Erratum does not make any specific point or propose and resolution.


Errata ID: 3270

Status: Rejected
Type: Editorial

Reported By: Joseph Weinstein
Date Reported: 2012-06-28
Rejected by: Adrian Farrel
Date Rejected: 2012-08-22

Section 4.5.1 says:

if StateRefreshCapable(I) == TRUE
         set PT(S,G) to largest active holdtime read from a Prune
         message accepted on I;

It should say:

if StateRefreshCapable(I) == TRUE
         set PT(S,G,I) to largest active holdtime read from a Prune
         message accepted on I;

Notes:

No macro PT(S,G) is defined anywhere in the RFC; the reference appears to be to P(S,G,I).
--VERIFIER NOTES--
Rejected as a duplicate of http://www.rfc-editor.org/errata_search.php?eid=3271


Errata ID: 3286

Status: Rejected
Type: Editorial

Reported By: Joseph Weinstein
Date Reported: 2012-07-16
Rejected by: Adrian Farrel
Date Rejected: 2012-08-22

Section 4.5 says:

(Additional subection)

It should say:

4.5.3 Receiving State Refresh Messages

When a State Refresh message is received, it may trigger state 
transitions to the upstream state machine and related actions, 
as described in Section 4.4.  It is then forwarded in accordance 
with Section 4.5.1.

Notes:

For clarity and completeness, an additional subsection is required to 4.5 describing the actions to be taken when a state refresh message is received. Since these actions have already been specified in Sections 4.4 and 4.5.1, it should be sufficient to simply refer to these sections. Without this additional subsection, an implementer could easily miss an important step in the processing of received state refresh messages.
--VERIFIER NOTES--
This may be fine and useful, but it does not qualify as Errata because it is
introducing new text and material.

If the WG feels strongly about this, it can be brought forward as a small
Informational I-D or included in an update of this RFC.


Report New Errata