Protocol Independent Multicast MIB
draft-ietf-pim-mib-v2-10
Yes
No Objection
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
(Brian Carpenter; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
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
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sam Hartman; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection