Subject: [pim] Triage on Errata for RFC 5060

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 11 Sep 2011 23:30:19 +0100

Hi,
 
Can I have your opinions on the Errata for RFC 5060?

http://www.rfc-editor.org/errata_search.php?eid=1445
This is correct, but at the extreme end of pedantry. It is certainly not a
Technical Erratum.
I propose to change it Editorial, and mark it "Held for Document Update"

http://www.rfc-editor.org/errata_search.php?eid=1447
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.
I propose to reject this Erratum.

http://www.rfc-editor.org/errata_search.php?eid=1448
There are two issues in this Erratum...
1. "This object is only used..."
  I would interpret this to mean that an attempt to read the object
  in other cases would return an error. I don't see a problem with the
  current text and propose to reject this part of the Erratum
2. "other timers are not modelled" Specifically:
   GraftRetryTimer - I see pimInterfaceGraftRetryInterval
   OverrideTimer - I see pimInterfaceOverrideInterval
   I suppose the question is: why can't I see how the timer is running?
   Looks like function that someone who wants it can add if they feel
   inspired.
   I propose to reject this as an Erratum and suggest that a MIB module
   could be written.

http://www.rfc-editor.org/errata_search.php?eid=1449
I need your help with this, but I think it is wrong.
In 3973 I see three states: NoInfo, PrunePending, Pruned. I *think* that Pruned
would not be reported, because the entry would go away.
In 4601 I see three states: NoInfo, Join, PrunePending. 
So the union of the states is what we see in 5060 and there is nothing to do.
I believe I should reject this Erratum.

Thoughts?

Thanks,
Adrian

---

From: "Nicholas, Jonathan - ES" <[email-masked]>
Date: Mon, 12 Sep 2011 07:56:14 -0400

With respect to errata 1449, I believe it is correct - a Pruned state should be available for PIM-DM.  Since the default state of PIM-DM (NoInfo) is to forward packets, it is important to retain information concerning pruned branches.

Below is the object I proposed back in 2005.  I had thought that it had been added, but it must have been missed.

Jonathan Nicholas

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 specifications."
    REFERENCE "I-D.ietf-pim-sm-v2-new section 4.5.3 and RFC 3973 section 4.4.2"
    ::= { pimSGIEntry 4 }

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adrian Farrel
> Sent: Sunday, September 11, 2011 6:30 PM
> To: [email-masked]
> Subject: [pim] Triage on Errata for RFC 5060
>
> Hi,
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.