Skip to main content

Protocol Independent Multicast MIB
draft-ietf-pim-mib-v2-10

Yes

(Bill Fenner)

No Objection

Lars Eggert
(Cullen Jennings)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Magnus Westerlund)
(Mark Townsley)
(Ross Callon)
(Russ Housley)
(Sam Hartman)
(Ted Hardie)

Note: This ballot was opened for revision 10 and is now closed.

Lars Eggert (was Discuss) No Objection

(Bill Fenner; former steering group member) Yes

Yes ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2007-01-23)
Shouldn't this be labelled as "Updates: 2934" ?

RFC 3376, RFC 3569, RFC 3618, and RFC 3810 appear in the References
section but do not seem to be used anywhere in the text.

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection (2007-01-22)
Part of the issues in this COMMENT were raised by Bert Wijnen. 

1. The document is part of a package that obsoletes RFC 2934. This should be mentioned in the header (if approved)

2. I wonder whether  [I-D.ietf-mboned-ip-mcast-mib] needs to be a Normative Reference. It looks to me that it is more a secondary reference for the obects where it's quoted, and mentioned more in relationship with the MIB module defined in  [I-D.ietf-mboned-ip-mcast-mib]. If I am correct I would suggest that this reference is moved to Informative, to allow to reduce the number of un-pubished Normative References and have th edocument approved sooner. 

3. I see few read-write objects that do not state anything about expected persistence behaviour. I see that it is controlled by pimDeviceConfigStorageType. Might be handy to make a note of that in the object itself

4. When I see:
   pimLastAssertGroupAddressType OBJECT-TYPE
    SYNTAX     InetAddressType
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "The address type of the multicast group address in the most
            recently sent or received assert.  If this router has not
            sent or received an assert then this object is set to
            unknown(0)."
    ::= { pim 25 }

   pimLastAssertGroupAddress OBJECT-TYPE
    SYNTAX     InetAddress (SIZE (0|4|8|16|20))
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "The multicast group address in the most recently sent or
            received assert.  The InetAddressType is given by the
            pimLastAssertGroupAddressType object."
    ::= { pim 26 }

So dns is not used as type - would it then not also be logical to limit the InetAddressTypes to the set that at least fit into a max size of 20? 

5. I do not see any text in the Counter32/64 objects about when possible discontinuities can occur? Does that mean only at reboot/restart? I would still mention that, so that it is clear to everyone.

6. I would use the term "notification(s)" instead of "trap(s)" throught the document/MIB-Module.

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection ()