Subject: [pim] [Technical Errata Reported] RFC4601 (2927)

From: RFC Errata System <[email-masked]>
Date: Tue, 9 Aug 2011 03:23:45 -0700 (PDT)

The following errata report has been submitted for RFC4601,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4601&eid=2927

--------------------------------------
Type: Technical
Reported by: Ang Way Chuang <[email-masked]>

Section: 4.2.2

Original Text
-------------
     void
     Update_SPTbit(S,G,iif) {
       if ( iif == RPF_interface(S)
             AND JoinDesired(S,G) == TRUE
             AND ( DirectlyConnected(S) == TRUE
                   OR RPF_interface(S) != RPF_interface(RP(G))
                   OR inherited_olist(S,G,rpt) == NULL
                   OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
                        ( RPF'(S,G) != NULL ) )
                   OR ( I_Am_Assert_Loser(S,G,iif) ) {
          Set SPTbit(S,G) to TRUE
       }
     }

Corrected Text
--------------
     void
     Update_SPTbit(S,G,iif) {
       if ( iif == RPF_interface(S)
             AND JoinDesired(S,G) == TRUE
             AND ( DirectlyConnected(S) == TRUE
                   OR RPF_interface(S) != RPF_interface(RP(G))
                   OR inherited_olist(S,G,rpt) == NULL
                   OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
                        ( RPF'(S,G) != NULL ) )
                   OR ( I_Am_Assert_Loser(S,G,iif) ) ) ) {
          Set SPTbit(S,G) to TRUE
       }
     }

Notes
-----
The logical evaluation is not properly enclosed. The RFC also doesn't mention the reason for the extra checking on the RPF'(S,G) != NULL. It is non-obvious to me. If the check on iif == RPF_interface(S) passes, how would there be any condition where RPF'(S,G) == NULL?

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4601 (draft-ietf-pim-sm-v2-new-12)
--------------------------------------
Title               : Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
Publication Date    : August 2006
Author(s)           : B. Fenner, M. Handley, H. Holbrook, I. Kouvelas
Category            : PROPOSED STANDARD
Source              : Protocol Independent Multicast
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Aug 2011 22:49:12 +0100

How nice to hear someone say "blimey." I think my grandfather used to say it -
he was born in East London - but it is not in wide use :-)

I updated the type to Editorial. Thanks for coming back on the point.

Cheers,
Adrian

> -----Original Message-----
> From: Ang Way Chuang [mailto:[email-masked]]
> Sent: 09 August 2011 15:48
> To: RFC Errata System
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Technical Errata Reported] RFC4601 (2927)
> 
> blimey, the type should be editorial not technical.
> 
> On 09/08/11 19:23, RFC Errata System wrote:
> > Reported by: Ang Way Chuang<[email-masked]>
> >
> > Section: 4.2.2
> >
> > Original Text
> > -------------
> >       void
> >
> >       Update_SPTbit(S,G,iif) {
> >
> > The logical evaluation is not properly enclosed. The RFC also doesn't
mention
> the reason for the extra checking on the RPF'(S,G) != NULL. It is non-obvious
to
> me. If the check on iif == RPF_interface(S) passes, how would there be any
> condition where RPF'(S,G) == NULL?
> >
> > Instructions:
> > -------------
> > Title               : Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol
> Specification (Revised)