Subject: Re: Gen-ART Review of draft-ietf-pim-bsr-mib-04.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 1 Apr 2008 09:02:33 -0500

Hi, Bharat,

What follows is my suggestion only, so please filter it appropriately...

>> 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.

Your explanation is very helpful. It would be great if your explanation 
ended up in the description itself. Perhaps something like

        DESCRIPTION
                "The status of this Row, used for two purposes - to create 
or
                 delete a specific Row from this table, and to provide the
                 status of a Row in this table"

If you're using a technique that's commonly used in MIB-land, fine, but 
manipulating an object by changing its "status" violates the principle of 
least astonishment, at least for this reader :-)

Either way - thanks for the quick response. Gen-ART reviewers love quick 
responses because we can remember why we wrote what we wrote...

Spencer 

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 1 Apr 2008 13:54:28 +0530

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.

> created/old entries deleted" - is that actually how it works? I would have

>                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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 2 Apr 2008 07:18:39 +0530

Hi Spencer,

> least astonishment, at least for this reader :-)

Yes. It is something commonly used in MIBs. This is defined as Textual Convention and has been standardize in RFC 2579. Here are the excerpts from this RFC:

RowStatus ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "The RowStatus textual convention is used to manage the
            creation and deletion of conceptual rows, and is used as the
            value of the SYNTAX clause for the status column of a
            conceptual row (as described in Section 7.7.1 of [2].)

Let me see if I can enhance the text in this object in all tables.

Regards,
Bharat