[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
On page 23, we now have:
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.
Does that mean it is not allowed to have s RowStatus or StorageType?
I think such is allowed, NO? And if so, we may want to make that
clear so that nobody interprets this incorrectly.
Further we list on page 34:
TDomain OBJECT IDENTIFIER
TAddress OCTET STRING (SIZE (1..255))
and on page 35:
TransportDomain OBJECT IDENTIFIER
TransportAddressType enumerated INTEGER
TransportAddress OCTET STRING (SIZE (0..255))
And I wonder if we would want to RECOMMEND/advise that in new MIB
module people use the latter 3 instead of the first 2.
I am checking with GenArea AD if we can actually reference RFC3907/8
in an I-D that goes to IETF Last Call while those RFCs do not yet
exist in final/published form.
Other then the above, I think this doc is ready to be posted
and then I can issue a 4 week IETF Last Call for publication as BCP.
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
>