draft-ietf-rserpool-mib-02.txt
Harrie Hazewinkel <[email protected]> Sun, 5 Feb 2006 16:20:53 +0100
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <[email protected]> |
Hi all, Some comments for the rserpool mib. > 1. Introduction > > This memo defines a Management Information Base (MIB) module which > describes managed objects for RserPool implementations. The MIB > defined in this memo is described using the Structure of Management > Information version 2, as defined in RFC1902 [6], RFC1903 [7], and > RFC1904 [8]. Would be nice to have a simply intro to RSerPool and how management is applied to it. > 2. The SNMP Management Framework > > The SNMP Management Framework presently consists of five major > components: DELETED: old boiler plate. Please update to the new boiler plate. > Dreibholz, et al. Expires August 6, 2006 > [Page 5] > Internet-Draft RSerPool MIB February > 2006 > > > 3. Structure of the MIB > > The following diagram illustrates the structure of the MIB. > > Structure of MIB > > > +--rserpoolMIB(12345) > | > +--enrpServers(1) I do not believe that a tree as presented is needed in a MIB module definition document. Not objecting, but it would be better to add this as Appendix. > As the figure shows, the MIB consists of three main branches: > "enrpServers", "poolElements" and "poolUsers". The first branch, > "enrpServers" is used to access managed objects in the set of ENRP > servers running on a given host. While it is assumed that it does > not make much sense to run multiple ENRP servers for the same > operation scope on one host, running multiple ENRP servers for > different operation scopes is very likely when the ENRP server > processes run on routers. Therefore, the MIB has to be able to > manage multiple ENRP servers on the same host. "poolElements" is > used > to access managed objects in the set of Pool Elements that are > running on a given host and the third branch, "poolUsers" is > used to > access managed objects in the set of Pool Users that are running > on a > given host. In fact, the structure of the three branches is very > similar. Because the two branches are so similar, we describe only > > > > Dreibholz, et al. Expires August 6, 2006 > [Page 9] > Internet-Draft RSerPool MIB February > 2006 > > > the first branch in detail, and provide a summary description of > the > second and third branch. We now proceed with a description of the > branches. It might sound weird, but from a standards perspective you would need to do this twice. IMHO, a standard must be clear and concise on all points. Also it would be nice if a more high level overview of the architecture managed is given. Not explaining RSerPool, but how management is applied to it. > > > > 4. Definitions > Overall for the complete MIB module, I strongly suggest to improve the wording for the description clause. Mostly the MIB module definition on its own should already provide sufficient information what the managed object is for. I did not comment on each individual object I have only added some specific ones inline below. Therefore, it applies to almost all object. Also I would suggest the MIB authors to read the MIB review guidelines also and apply the advice laid out in that document. > > RSERPOOL-MIB DEFINITIONS ::= BEGIN > > IMPORTS > MODULE-IDENTITY, > OBJECT-TYPE, > TimeTicks, > Unsigned32 > FROM SNMPv2-SMI > InetAddress > FROM INET-ADDRESS-MIB; Add a comment to the MODULE names indicating the RFC number. > > -- ## Module definition ########################################### > rserpoolMIB MODULE-IDENTITY > LAST-UPDATED "200506100820Z" > ORGANIZATION "IEM-TdR, UNIVERSITY OF DUISBURG-ESSEN" > CONTACT-INFO > " THOMAS-DREIBHOLZ > > Postal: University of Duisburg-Essen > Institute for Experimental Mathematics > Ellernstrasse 29 > D-45326 Essen > Germany > Phone: +49 201-183 7637 > Email: [email protected] > > > JAIWANT-MULIK > PHILLIP-CONRAD > KEVIN-PINZHOFFER > > Postal: 1805, N Broad St. > Philadelphia, PA > USA 19121 > Phones: +1 215 204 7910 > Emails: [email protected] > [email protected] > [email protected]" > DESCRIPTION > "The MIB module for managing a RSerPool implementation" > ::= { mib-2 12345 } -- To be IANA Assigned!!! Please do not assign some random number for the MIB module!! That might create problems in the long term. I would refer to the MIB review guidelines for instructions on how to do this. The problem is that people do implement this MIB module with this 'unofficial' assigned number for the module and forget or cannot really change it later. > Dreibholz, et al. Expires August 6, 2006 > [Page 13] > Internet-Draft RSerPool MIB February > 2006 > > > -- ## RSerPool type definitions ################################### > ENRPServerIdentifier ::= INTEGER (1..4294967295) > ENRPServerDescription ::= OCTET STRING (0..255) > OperationScope ::= OCTET STRING > > PoolHandle ::= OCTET STRING > > PoolElementIdentifier ::= INTEGER (1..4294967295) > PolicyType ::= INTEGER (0..255) > PolicyDescription ::= OCTET STRING (0..255) > PolicyLoad ::= INTEGER (0..16777215) > PolicyWeight ::= INTEGER (0..16777215) > TransportUse ::= INTEGER { > dataOnly(0), > dataPlusControl(1) > } > > ENRPServerIndex ::= INTEGER (1..2147483647) > PoolIndex ::= INTEGER (1..2147483647) > PoolElementIndex ::= INTEGER (1..2147483647) Type definitions are NOT done this way in SMI. Please use Textual conventions as defined in SNMPv2-TC/RFC 2578 > > > > -- ## Top-level definitions ####################################### > enrpServers OBJECT IDENTIFIER ::= { rserpoolMIB 1 } > poolElements OBJECT IDENTIFIER ::= { rserpoolMIB 2 } > poolUsers OBJECT IDENTIFIER ::= { rserpoolMIB 3 } > > > > -- ## Definition of the ENRP server table ######################### > enrpServerCount OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of ENRP servers on this host" > ::= { enrpServers 1 } This kind of object is not defined anymore. One can retrieve this information from the table itself. It was done in the early days with the INTERFACE-MIB, but currently not used anymore. > > enrpServerTable OBJECT-TYPE > SYNTAX SEQUENCE OF enrpServerEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The conceptual table listing of the ENRP > servers > on this host" > ::= { enrpServers 2 } > > enrpServerEntry OBJECT-TYPE > SYNTAX ENRPServerEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The conceptual row in enrpServerTable" > INDEX { enrpServerIndex } > ::= { enrpServerTable 1 } > > ENRPServerEntry ::= SEQUENCE { > enrpServerIndex ENRPServerIndex, > enrpServerElementCount Counter32, Has this MIB module ever been tested with some tools for validity? Guess not, since the enrpServerElementCount item is not defined.. :-)) I suggest for future publications of this document first to check it with a MIB compiler/tool. > enrpServerIdentifier ENRPServerIdentifier, > enrpServerUptime timeTicks, > enrpServerDescription ENRPServerDescription, > enrpPort INTEGER, > enrpAddrCount Counter32, > peerCount Counter32, > poolCount Counter32, > enrpServerASAPAnnouncePort INTEGER, > enrpServerASAPAnnounceAddr InetAddress, > enrpServerENRPAnnouncePort INTEGER, > enrpServerENRPAnnounceAddr InetAddress } > > enrpServerIndex OBJECT-TYPE > SYNTAX ENRPServerIndex > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This is the index to the enrpServerTable" > ::= { enrpServerEntry 1 } > > enrpServerIdentifier OBJECT-TYPE > SYNTAX ENRPServerIdentifier > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This is the ENRP server identifier of this row" > ::= { enrpServerEntry 2 } > As well enrpServerIndex and enrpServerIdentifier seem to be usable for an index. In this case I would suggest to use the last one as index and delete the first one which is currently the index. > enrpServerOperationScope OBJECT-TYPE > SYNTAX PoolElementIdentifier > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This is the operation scope of this row" > ::= { enrpServerEntry 3 } In this document is not a clear definition of operation scope. I would suggest to add this properly within the DESCRIPTION clause of the textual convention that you MUST define for the type, PoolElementIdentifier. > > enrpServerUptime OBJECT-TYPE > SYNTAX TimeTicks > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This is the uptime of this row" > ::= { enrpServerEntry 4 } As an example, this is not considered a proper description clause by most IESG MIB reviewers. > > enrpAddrCount OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The ENRP address count of this row" > ::= { enrpServerEntry 7 } For instance, how is counted or what? > > peerCount OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of peers of this ENRP server" > ::= { enrpServerEntry 8 } Object name can be more precise for its purpose. There are no compliance statements and object groups defined. This would have been found if the MIB was tested with tools for validity. > > END > > > For sake of brevity and to avoid inadvertant inconsistencies due to > typos, we omit the full elaboration of the poolElements and > poolUsers > branch. However, we repeat for emphasis that the semantics of the > two branches are different, as noted earlier in this memo. Unfortenetely, this approach is not acceptable in order to have a clear and concise MIB module that is usable for RSerPool. > > 5. Security Considerations > > SNMPv1 by itself is not a secure environment. Even if the network > itself is secure (for example by using IPSec), there is no > control as > to who on the secure network is allowed to access and GET/SET > (read/ > change/create/delete) the objects in this MIB. > > It is recommended that the implementers consider the security > features as provided by the SNMPv3 framework. Specifically, the > use > of the User-based Security Model RFC 2574 [15] and the View-based > Access Control Model RFC 2575 [16] is recommended. > > It is then a customer/user responsibility to ensure that the SNMP > entity giving access to an instance of this MIB, is properly > configured to give access to the objects only to those principals > (users) that have legitimate rights to indeed GET or SET (change/ > create/delete) them. > besides a standard template for this, the MIB author should also provide information regarding the sensibility of the managed objects for reading/writing. That would include for instance using the plain values over the wire with SNMP v2c for instance. > > > 6. IANA Considerations > > IANA will need to assign an OID prefix for the RSerPool MIB. > Indeed and therefore you cannot assign some random value in the MIB draft. The MIB review guidelines provide instructions for this. > > 7. References Please update the references for the SNMP parts as provided by the boiler plate and the the MIB moduleguidelines. Harrie