|
I would welcome a quick clarification on this issue, as the
raqmon documents are due to be sipped to the IESG. My interpretation is that
having objects with a MAX-ACCESS of 'accessible-for-notify' in the conceptual
row is enough to meet the intent of SMIv2. However, if the intent is indeed for
at least one object to be 'read-only' and not something else, please jump in
(with a more detailed justification of course).
Thanks and
Regards,
Dan
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.
|