1. The MIB compiles cleanly.
2. idnits detected three documents in the references that were already
published as RFCs:
== Outdated reference: draft-ietf-pim-mib-v2 has been published as RFC
== Outdated reference: draft-ietf-pim-sm-bsr has been published as RFC
== Outdated reference: draft-ietf-mboned-ip-mcast-mib has been
3. The document should display Intended Status: Proposed Standard in the
4. Acronyms and terms like RP, Candidate-RP, Elected RP, BSR,
Candidate-BSR and Elected BSR are not explained. The document needs a
short glossary or a pointer to the document that includes these. I could
not find straight definitions in RFC 4601, maybe they are some place
5. As draft-ietf-pim-sm-bsr has been published as RFC 5059 REFERENCE
clauses should be updated accordingly.
6. I am a little confused by the following logic:
In the DESCRIPTION clause of pimBsrCandidateRPStatus:
All writable objects in this entry can be modified
when the status of this entry is active(1).
While in the DESCRIPTION clause of pimBsrCandidateRPStorageType
The storage type for this row. Rows having the value
'permanent' need not allow write-access to any columnar
objects in the row."
Is 'need not' equivalent with a 'should not'? And why is this dependent
of the storage type?
7. Same questions about entries in pimBsrCandidateBSRTable
8. The DESCRIPTION clause of pimBsrElectedBSRRPSetPriority says:
. Numerically higher values for
this object indicate lower priorities, with the value
zero denoting the highest priority
Is this true also for pimBsrCandidateRPPriority?
9. The objects defining hash mask lengths could use UNITS clause "bits"
[mailto:ietf-announce-bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: Wednesday, March 12, 2008 10:16 PM
Subject: Last Call: draft-ietf-pim-bsr-mib (PIM Bootstrap
Router MIB) to Proposed Standard
The IESG has received a request from the Protocol Independent
Multicast WG (pim) to consider the following document:
- 'PIM Bootstrap Router MIB '
<draft-ietf-pim-bsr-mib-04.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send
substantive comments to the ietf(_at_)ietf(_dot_)org mailing lists by
2008-03-26. Exceptionally, comments may be sent to
iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
The file can be obtained via
IESG discussion can be tracked via
IETF-Announce mailing list
IETF mailing list