Document: draft-ietf-pim-bsr-mib-04.txt Reviewer: Spencer Dawkins Review Date: 2008-03-31 (LATE) IETF LC End Date: 2008-03-26 IESG Telechat date: (if known) Summary: Ready for publication as a Proposed Standard Comments: there are a small number of questions I tagged as "Clarity:" in the notes below. If this draft is revised, it would be worth looking at these questions. 4. Overview This MIB module contains four tables. The tables are: 1. The Candidate-RP Table, which contains one row for each multicast group address prefix for which the local router is to advertise itself as a Candidate-RP. This table exists on routers that are configured as Candidate-RP. Clarity: I'm reading this as "configured to advertise itself as Candidate-RP" - right? That seems to be the terminology used in the MIB descriptions, and is more clear to me (if I understood correctly here). Clarity: There are a decent number of multicast abbreviations that aren't expanded on first use. If the document gets respun after Last Call, it would be worth making sure these terms are expanded on first use (otherwise the RFC Editor has to either ask you or guess). 5. Definitions pimBsrCandidateRPStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table. Clarity: I'm sorry, but I don't get "status by which new entries may be created/old entries deleted" - is that actually how it works? I would have thought the status was the side effect of creation/deletion, not how creation/deletion actually happens. s/by which new/used to identify when new/? but I'm guessing here. This status object can be set to active(1) without setting any other columnar objects in this entry All writable objects in this entry can be modified when the status of this entry is active(1)." ::= { pimBsrCandidateRPEntry 10 }