[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: 2nd draft of proposed "Last Call" version of draft-ietf-ops-m ib-review-guidelines



Sorry Mike, I did not get to it over the weekend and am
currently pretty loaded. I fear it may be Friday before 
I get to it again. Pls bear with me.

If, in the meanwhile others have any final remarks, pls do
send them to the list or to Mike

Bert

> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of C. M. Heard
> Sent: Friday, January 14, 2005 08:58
> To: Mreview (E-mail)
> Subject: 2nd draft of proposed "Last Call" version of
> draft-ietf-ops-mib-review-guidelines
> 
> 
> MIB Doctors,
> 
> Attached please find draft-ietf-ops-mib-review-guidelines-04Pre2.txt
> along with a context diff showing what is different from the current
> (i.e., -03) draft.  Thanks to everyone who made comments on
> draft-ietf-ops-mib-review-guidelines-04Pre1.txt;  your comments have
> made this version better than the last.  I would like to believe
> that it is ready to go to IETF last call;  please let me know if you
> agree, or if you think that more work is needed.
> 
> 
> Here is a summary of the issues raised against
> draft-ietf-ops-mib-review-guidelines-04Pre1.txt
> along with the changes (if any) that have been
> made to resolve them.
> 
> >>>>> Guidelines for other SDOs:  there was a lengthy discussion of
> whether or not to include such things, at the end of which David B
> Harrington wrote:
> 
> dbh> I would be satisfied letting the document advance in its
> dbh> IETF-specific form, and then start a revision which deals with
> dbh> non-IETF guidelines, capturing some of the new MIB Doctor
> dbh> experience in non-IETF mib reviews.
> 
> Resolution:  no changes were made.
> 
> 
> >>>>> On Fri, 7 Jan 2005, Keith McCloghrie wrote:
> kzm> Do you think that this [ text from Section 4.6.4 ] or some
> kzm> other text in draft-ietf-ops-mib-review-guidelines-03.txt
> kzm> should mention the situation of one table which AUGMENTS
> kzm> another table, in which only one of them should have a
> kzm> RowStatus, i.e., this is one circumstance where it's legitimate
> kzm> to get read-create objects in a table without a RowStatus.
> 
> Resolution:  the following text was added near the end of Section
> 4.6.4:
> 
>    Note that RFC 2578 Section 7.8 requires that the lifetime of an
>    instance of a conceptual row that AUGMENTS a base row must be
>    the same as the corresponding instance of the base row.  It
>    follows that there is no need for a RowStatus or StorageType
>    column in an augmenting row if one is already present in the
>    base row.
> 
> 
> >>>>> On Fri, 7 Jan 2005, Randy Presuhn replied:
> Randy> Given that dissatisfaction with the complexity RowStatus
> Randy> bubbles up from time to time, I think the MUST is slightly
> Randy> overkill.
> 
> Resolution:  MUST was changed to SHOULD in the following:
> 
>      - There SHOULD be one columnar object with a SYNTAX value of
>        RowStatus [RFC2579] and a MAX-ACCESS value of read-create.
>        This object is called the status column for the conceptual
>        row.  All other columnar objects MUST have a MAX-ACCESS value
>        of read-create, read-only, accessible-for-notify, or
>        not-accessible;  a MAX-ACCESS value of read-write is not
>        allowed.
> 
> 
> >>>>> On Fri, 7 Jan 2005, Dave Thaler wrote:
> dt> I believe it is acceptable [to use IpAddress] in cases where a
> dt> MIB object instruments an inherently IPv4-only thing (e.g., an
> dt> IPv4-only protocol like ARP, or an object which is exists in
> dt> VRRPv2 for IPv4, but not in VRRPv3 for IPv6).  Not using it in
> dt> this case just adds gratuitous inefficiency.
> 
> Since there was little support for spelling out specific
> circumstances under which IpAddress might be acceptable in a new MIB
> module, no change was made to the document.  Note that there was
> language already in RFC 2578 that disparaged this data type.
> 
> 
> >>>>> On Fri, 7 Jan 2005, Mark Ellison wrote:
> me> I do feel there is a need to clarify that a special boundary
> me> case does not exist for a table with all non-auxilliary objects
> me> used exclusively for notifications....I missed the "non-" part
> me> of "non-auxiliary" in the suggested text.  Apologies for this
> me> confusion.
> me>
> me> Here's the suggested text (corrected):
> me>
> me>     - For conceptual rows used exclusively for defining objects
> me>       referenced by notification definitions:
> me>
> me>         - At least one non-auxiliary object must be defined with
> me>           a MAX-ACCESS of (at least) "accessible-for-notify"
> 
> This is being pursued as an erratum to RFC 2578 instead of as an
> addition to the guidelines document.
> 
> 
> >>>>> On Fri, 7 Jan 2005, Wijnen, Bert (Bert) wrote:
> bw> It looks to me, that we might be better of if we can massage
> bw> things such that 2223bis becomes an informative ref
> 
> Resolution:  the text has been so massaged.  Note that the consensus
> here is at best rather rough;  here is my answer to the objections:
> 
> On Mon, 10 Jan 2005, David B Harrington wrote:
> dbh> I disagree with trying to demote [rfc2223bis] to an informative
> > reference by making a web page the normative reference.
> 
> My answer to this was:
> cmh> While I share your discomfort with making the web pages
> cmh> normative, the fact is that http://www.ietf.org/ietf/1id-
> cmh> guidelines.txt and http://www.ietf.org/ID-Checklist.html --
> cmh> not RFC 2223bis -- set the requirements for Internet-Drafts,
> cmh> and the review guidelines apply to Internet-Drafts, not RFCs
> cmh> (which are the subject matter of RFC 2223bis).  So this
> cmh> demotion is really just an acknowledgment of the existing
> cmh> reality.
> 
> 
> >>>>> On Mon, 10 Jan 2005, Randy Presuhn wrote:
> Randy> What bothers me about both the current and the proposed text
> Randy> is that it repeats requirements already spelled out in detail
> Randy> in other documents.  [ ... ]  My proposed change would be to
> Randy> eliminate the redundant material, replacing it with a single
> Randy> note that MIBs submitted in the form of internet drafts need
> Randy> to conform to the rules for submitting internet drafts, and
> Randy> an information reference, regrettably, to 1id-guidelines.txt
> 
> The replacement text remains as originally proposed since specific
> alternative text has not been offered.
> 
> 
> >>>>> On Mon, 10 Jan 2005, Wijnen, Bert (Bert) wrote:
> Bert>[David Perkins wrote:]
> Bert> > More importantly is that if application A is created
> Bert> > to access table T, such as to create and delete rows
> Bert> > in T. Then adding support for augmentation table T1
> Bert> > MUST NOT cause A to stop working or to work differently.
> Bert> > This means that a MIB designer is quite constrained 
> Bert> > in the design of augmentation tables!
> Bert> > 
> Bert> > This should be obvious.
> Bert> 
> Bert> I guess you are right that it should be obvious. However, I
> Bert> suspect I never took it that restricted when reviewing new MIB
> Bert> modules. It restricts it very very seriously. For example, all
> Bert> the columns in the augemented table should have DEFVALs to
> Bert> allow the row to become active based on DEFVALs.
> 
> On Mon, 10 Jan 2005, David B Harrington wrote:
> dbh> I think the point about DEFVALs is good, and not obvious. It
> dbh> would be good to provide an explicit guideline on this point.
> 
> On Mon, 10 Jan 2005, C. M. Heard replied:
> cmh> Well, one thing we can't do is to say that DEFVALs are
> cmh> required.
> cmh>
> cmh> According to RFC 2578, DEFVALs are optional hints to
> cmh> implementors.  They are not required to be present and can be
> cmh> changed in future revision.  They also are not binding on
> cmh> the agent.  [ ... ]  Finally, note that a sensible default
> cmh> value does not always exist.
> cmh>
> cmh> What IS required is that the agent needs to be able to
> cmh> create a row even if values for the augmenting columns are
> cmh> not specified.  One way to do that is to provide default
> cmh> values for the augmenting columns.  Another way is to "fall
> cmh> back" and operate like it is implementing the un-AUGMENTed
> cmh> table.
> 
> Resolution:  since the discussion was inconclusive, no change has
> been made.
> 
> Regards,
> 
> Mike Heard
>