Subject: [Rserpool] draft-ietf-rserpool-mib-02.txt

From: Harrie Hazewinkel <[email-masked]>
Date: Sun, 5 Feb 2006 16:20:53 +0100

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-masked]
>
>
>          JAIWANT-MULIK
>          PHILLIP-CONRAD
>          KEVIN-PINZHOFFER
>
>          Postal: 1805, N Broad St.
>                   Philadelphia, PA
>                   USA 19121
>          Phones: +1 215 204 7910
>          Emails: [email-masked]
>                   [email-masked]
>                   [email-masked]"
>       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

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool