[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Re: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt]



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 --------
Subject: Re: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt
Date: Mon, 03 Jan 2005 15:02:32 -0800
From: Mark Ellison <ellison@ieee.org>
Organization: Ellison Software Consulting, Inc.
To: Romascanu, Dan (Dan) <dromasca@avaya.com>
CC: egolovin@bmc.com, rmonmib@ietf.org, Mark Ellison <ellison@ieee.org>
References: <AAB4B3D3CF0F454F98272CBE187FDE2F038A9FBF@is0004avexu1.global.avaya.com>


Hi Dan,

Thanks for your response- I've added my clarifications inline.

Regards,

Mark

Romascanu, Dan (Dan) wrote:
-----Original Message-----
From: rmonmib-bounces@ietf.org [mailto:rmonmib-bounces@ietf.org]On Behalf Of Mark Ellison
Sent: 21 December, 2004 3:18 AM
To: egolovin@bmc.com
Cc: rmonmib@ietf.org; Mark Ellison
Subject: Re: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt

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.