|
My
personal view is that I agree with your (Dan)
interpretation.
Bert
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.
|