Bert and Mike,
There is currently a dicussion about a point in RFC 2578 sxn 7.7, as
described below. Possibly, this issue could be clarified in the next
id for the mib review guidelines?
Regards,
Mark Ellison
-------- Original Message --------
Hi Dan,
Thanks for your response- I've added my clarifications inline.
Regards,
Mark
Romascanu, Dan (Dan) wrote:
Hi,
In looking at the RAQMON-RDS-MIB, some issues arise, as follows:
1) raqmonDs MODULE-IDENTITY
module identity name should end with Mib or MIB
[Romascanu, Dan (Dan)] I have no objection, although I cannot find a reference for your SHOULD. Do you have one?
RFC 2578 seems to require the name to be just a unique ASN.1 identifier. The MIB guidelines are also mute on this issue.
RFC 3729 which is t he last RFC defining a MIB module issued by this WG defines just apm and not apmMIB or something similar.
[Mark Ellison] Yes. I should have cited a reference. Here it is (if
expired by a couple of days):
The ietf-ops-mib-review-guidelines (last known:
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-03.txt)
Section 4.1, "Module Names", states:
"RFC 2578 Section 3 specifies the rules for module names.
Note in particular that names of "standard" modules MUST be unique,
MUST follow the syntax rules in RFC 2578 Section 3, and MUST NOT be
changed when a MIB module is revised (see also RFC 2578 Section 10).
It is RECOMMENDED that module names be mnemonic. See Appendix C for
suggested naming conventions."
So, my "should" is a derived from the above RECOMMENDED, and, from
'urged' in the Appendix C, "Suggested Naming Conventions":
"Authors and reviewers of IETF MIB modules have often found
the following naming conventions to be helpful in the past, and authors
of new IETF MIB modules are urged to consider following them.
The following bullet from page 37, Appendix C address the Module
identity construct:
- The descriptor associated with the MODULE-IDENTITY
invocation should be of the form xxxMIB, xxxMib, or xxxMibModule, where
xxx is a mixed-case version of XXX starting with a lower-case letter
and without any hyphens. For example, the OPT-IF-MIB uses the prefix
optIf, and the descriptor associated with its MODULE-IDENTITY
invocation is optIfMibModule.
So, if I've followed the review guidelines correctly, I believe that "raqmonDs"
MODULE-IDENTITY should be "raqmonDsMib" or "raqmonDsMIB".
The module name, RAQMON-RDS-MIB, is consistent with the MIB review
guidelines.
2) raqmonDsNotificationEntry
objects used in index clause [raqmonDSRC, raqmonRCN,
raqmonPeerAddrType, raqmonPeerAddr] according to
SMIv2 (2578 sxn 7.7) should have a MAX-ACCESS of
not-accessible.
The two defined notifications, raqmonDsNotification and
raqmonDsByeNotification require only index objects be sent.
Since the value part of the object instance is included
in the index portion of the varbind name, there is a
unnecessary duplication of information.
This suggests one of two alternative approaches- either
a) change the OBJECTS clause for the NOTIFICATION-TYPEs
to specify an accessible-for-notify object that is not
mentioned in the INDEX clause of raqmonDsNotificationEntry
and replace the current OBJECTs list with this object.
b) change the raqmonDsNotificationEntry into a group of
scalars, leaving the index objects with a MAX-ACCESS of
accessible-for-notify, and, leaving the two defined
NOTIFICATION-TYPEs as is.
[Romascanu, Dan (Dan)] I will go with your proposal a.
There are reasons to keep the table structure, so that the information is correlated if the table is extended in the future.
[Mark Ellison] I like the table structure as well.
Since 2578 Sxn 7.7 appears specifies that at least
one
object in an entry must have a MAX-ACCESS of at least
read-only,
it might be a good idea to address this point in the
description
clause of the entry, given the design choice to stick with the
current organization, or, make an object read-only, and then
restrict its MAX-ACCESS to accessible-for-notify in a compliance
clause.
[Romascanu, Dan (Dan)] Actually I believe
that this is OK and we do not need a 'read-only' object. What RFC 2578
says is:
a conceptual row must contain at least one columnar object
which is
not an auxiliary object. In the event that all of a conceptual
row's columnar objects are also specified in its INDEX clause, then
one of them must be accessible, i.e., have a MAX-ACCESS clause of
"read-only".
" read-only"
is an example. The objects in raqmonDsNotificationEntry
are accessible-for-notify.
[Mark Ellison] Yes, its the "i.e." part that requires clarification,
since "i.e." usually means "that is", whereas "e.g." usually means "for
example". I've forwarded a copy of this email to Bert Wijnen. Perhaps
a clarification can be added to the next id for the mib review
guidelines. I hope an "e.g." was intended, and that a MAX-ACCESS of
accessible-for-notify is compliant in this regard.
This MIB module defines a mapping of
the RAQMON PDU into SNMP notifications and this level of accessibility
is sufficient.
[Mark Ellison] I see no reason to actually specify or implement a
greater (e.g. read-only) MAX-ACCESS value for any of the defined
objects unless "i.e." in the 2578 text quoted above really means "that
is". Iff this is the case, then one might need to resort to
contortions compliant with the SMI.
|