[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments/review <draft-ietf-ops-mib-review-guidelines-00.txt>
Sorry that this took a while (well more than a day).
- you talk about "standard" MIB quite a few times.
maybe better to use "standards track" MIB, cause it is
true for all 3 levels on the stds track
- Sect 3 talks about need for IPR section.
I believe such is only required for stds track and bcp docs
It is allowed in other docs, but not required I think.
- sect 3.2
I have often asked people to IMPORT object groups from
other MIB modules if they require them to be implemnted
and then to add such groups to the MODULE-COMPLIANCE.
Would that not be better than narrative text to express it.
- sect 3.3 1st sentence
s/MIB modules/MIB module(s)/ ??
- sect 3.7
I personally have no problem is an tobe IANA-maintained
MIB module stays in an RFC where it gets first published
and handed to the RFC-Editor. As long as it makes clear
that current versions should be picked up from the iana
web pages, and that furture revisions will NOT include
the current or updated revisions.
RFC1573 is an example of that for IANA ifTypes.
- sect 4.3
as an aside, does that now mean that we as MIB doctors
agree that it is OK for draft-ietf-ops-rfc2786std-00.txt
to stay under experimental if that is what they want,
even when the doc gets published as stds track doc?
- sect 4.5
last sentence of 3rd bullet....
are we sure we agree? I have seen trouble with that, even
for the RMON MIB space... I cought it in time before
we published an RFC, but...
Should we at least ask that such registrations are
administered by IANA. SO the WG can make them but should
get them recorded and documented in the IANA registry.
That way... when say 10 years from now, someone wants to
add something, they have a central place to check as to
what actually has been assigned and what numbers are still
available.
- sect 4.6.1.1
You may want to indent the para that starts with
"Note that RFC 2578....
2 positions to the right. Or so I think
- sect 4.6.1.4, end of page 14
Mmm... the DisplayString is still current, although we
rarely want to allow people to use it anymore. We prefer
UTF-8 based TCs like SnmpAdminString.
Do we want to make a note of that? I think it would be
good. It is a thing that I see still far too often.
- sect 4.6.1.5 one but last para
s/RowPointerTC/RowPointer TC/ ??
- sect 4.6.3 page 18
You talks about the "status" column. Is it not better
to call it the "row-status" column ? Some MIB modules
use a additional status to indicate enabled/disabled
or inuse/out-of-order and what have you.
- Same section,
would it be good to add (tableEntry) in parentheses
at the first mention of "row object"
- Same section
For table that are not read-create, but that have read-write
objects, I think we also want some words about persistence
or a StorageType object.
- sect 4.7
I wonder if we should say something about what I often
mention when reviewing, and that is that for many MIB
modules, it makes sense to not do:
xxxMibNotifications OBJECT IDENTIFIER ::= { xxxMib 2 }
xxxMibNotificationPrefix
OBJECT IDENTIFIER ::= { xxxMibNotifications 0 }
but instead use
xxxMibNotifications OBJECT IDENTIFIER ::= { xxxMib 0 }
It is not always the best solution, but in many case sit is
and it shortens the OID by one subID.
(details details, right?)
Juergen actually had a good few paragraphs about it at
some time as to when to use which approach... but I can't
find it quickly.
- sect 4.8 3rd bullet
would we not recommend to do it in the same MIB module?
- last bullet on page 21
I'd actually remove the last few words. SO I would change
example is provided by the DIFFSERV-MIB [RFC3289]. Authors SHOULD
consider using this technique in situations where it is
appropriate.
into
example is provided by the DIFFSERV-MIB [RFC3289]. Authors SHOULD
consider using this technique.
Or maybe the last sentence:
It is strongly RECOMMENDED to use this technique.
because I think it makes it MUCH easier for an agent to express
what it complies with, and so it potentially makes things easier
on the manager (assuming everyone implements correctly and makes
correct claims).
- page 22
Is that a footnote that I see? I though RFC-Editor does not
allow for that
- Page 22 says towards bottom (just before footnote)
One cannot do this for inaccessible index objects because they cannot
be present in object groups and cannot be mentioned in OBJECT
clauses. There are situations, however, in which one might wish to
indicate that an implementation is required to support only a subset
of the possible values of some index in a read-create table. In such
cases the requirements MUST be specified either in the index object's
DESCRIPTION clause (RECOMMENDED if there is only one value subset) or
in the DESCRIPTION clause of a MODULE-COMPLIANCE statement (REQUIRED
if the value subset is unique to the compliance statement).
I wonder if we could recommend that they also just do the spec
in the form of comments for such index columns. So
-- OBJECT xxxIndex
-- SYNTAX InetAddressType { ipv4(1), ipv6(2) }
-- DESCRIPTION "Only ipv4 and ipv6 support is required"
That way it reads easier I think Of course it also is good to
have it in a real DESCRIPTION clause.
- Sections 4.8 and 4.9 are pretty long.
Would it be possible to add some sub-numbers or labels
so that when we review a MIB and we find it violates some
piece of these sections that we can easily say
see RFCxxxx section 4.9 bullet A sub 3 or some such?
Just thinking aloud here
- page 25 2nd bullet
I actually wonder if it would not be better if people did
list all the enumerations at the first revision of a MIB
and the compliance statements. That way... it is clear
from the beginning what it is that one can expect.
Of course some enumerations do not need that, because they
are intended to be extended, and that is OK.
- Appendix A
- add a bullet to do a general/overall check on ID-NITs
with ptr to it of course
- I will check the appendix C.. Mike did send me some stuff
to work out... still to be done.
Thing is I'd like to refer to 2578/79/80 instead of
1902/3/4
- Appendix D
- Make a note that DisplayString should not be used anymore
but some UTF-8 based TC instead
- We probably should add some more common TCs here.
In fact we should start that project to collect all
common TCs into one place one way or another, so that
they are easy to find.
Thanks again Mike. Great job.
Bert