Re: I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt

Hi Dan,

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

Regards,

Mark

Romascanu, Dan (Dan) wrote:

>     -----Original Message-----
>     From: [email protected] [mailto:[email protected]]On
>     Behalf Of Mark Ellison
>     Sent: 21 December, 2004 3:18 AM
>     To: [email protected]
>     Cc: [email protected]; 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.

_______________________________________________
RMONMIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rmonmib