Hi Spencer,
Thanks for reviewing this document. I shall add clarification you
have asked for in the next revision.
Please see my response in line.
Thanks,
Bharat
> I have been selected as the General Area Review Team (Gen-ART) reviewer for
> this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments you
> may receive.
>
> Thanks,
>
> Spencer
>
> 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).
Ok. I agree that adding 'configured to' in the statement makes it more
explicit.
> 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).
>
Ok. I shall expand them on their first usage. If require, I will add
them in the terminology section.
> 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.
>
The 'RowStatus' object is used for two purposes. One is to provide the
current status of a Row and another is to create/delete a specific Row.
So this statement looks ok.
> 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 }
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf