Pls note that I am not on the resepool mailing list, so send an explicit 
cc/bcc if
you want me to see it.

I am getting these SMICng (strict checking) errors/warnings:

C:\bw\smicng\work>smicng rserpool.inc
W: f(rserpool.mi2), (133,4) Sequence "ENRPServerEntry" and Row 
"enrpServerEntry" should have related
names
W: f(rserpool.mi2), (167,15) Item "enrpServerOperationScope" should have 
SIZE specified
W: f(rserpool.mi2), (272,4) Sequence "ENRPServerPoolEntry" and Row 
"enrpServerPoolEntry" should have
related names
W: f(rserpool.mi2), (295,15) Item "enrpServerPoolHandle" should have SIZE 
specified
W: f(rserpool.mi2), (311,4) Sequence "ENRPServerPoolElementEntry" and Row 
"enrpServerPoolElementEntry
" should have related names
W: f(rserpool.mi2), (461,4) Sequence "ENRPServerASAPAddrTableEntry" and Row 
"enrpServerASAPAddrTableE
ntry" should have related names
W: f(rserpool.mi2), (515,4) Sequence "ENRPServerUserAddrTableEntry" and Row 
"enrpServerUserAddrTableE
ntry" should have related names
W: f(rserpool.mi2), (560,15) Item "enrpServerUserL3Opaque" should have SIZE 
specified
W: f(rserpool.mi2), (578,4) Sequence "ENRPServerENRPAddrTableEntry" and Row 
"enrpServerENRPAddrTableE
ntry" should have related names
W: f(rserpool.mi2), (629,4) Sequence "ENRPServerPeerEntry" and Row 
"enrpServerPeerEntry" should have
related names
W: f(rserpool.mi2), (688,4) Sequence "ENRPServerPeerAddrTableEntry" and Row 
"enrpServerPeerAddrTableE
ntry" should have related names
W: f(rserpool.mi2), (784,15) Item "poolElementOperationScope" should have 
SIZE specified
W: f(rserpool.mi2), (792,15) Item "poolElementPoolHandle" should have SIZE 
specified
W: f(rserpool.mi2), (1026,15) Item "poolElementUserL3Opaque" should have 
SIZE specified
W: f(rserpool.mi2), (1071,15) Item "poolUserOperationScope" should have SIZE 
specified
W: f(rserpool.mi2), (1079,15) Item "poolUserPoolHandle" should have SIZE 
specified

*** 0 errors and 16 warnings in parsing

I wonder if
       ::= { mib-2 xxx } -- To be IANA Assigned!!!
is appropriate for an EXPERIMENTAL MIB module
Probably want to root it under the experimental tree?

Further I see a lot of naming inconsistencies

- Normally, in a MIB module we prefix all TCs with a prefix that makes it 
clear
  which module these TCs are defined in. This is to try and avoid that the 
TC
  names/identifiers will not conflict with any existing or future other TCs.
  Specifically for a experiemntal module you do not want to have conflicts
  with standards track MIB modules.
  So for these

   ENRPServerIdentifierType ::= TEXTUAL-CONVENTION
   OperationScopeType ::= TEXTUAL-CONVENTION
   PoolHandleType ::= TEXTUAL-CONVENTION
   DescriptionType ::= TEXTUAL-CONVENTION
   PoolElementIdentifierType ::= TEXTUAL-CONVENTION
   PolicyIDType ::= TEXTUAL-CONVENTION
   PolicyLoadType ::= TEXTUAL-CONVENTION
   PolicyWeightType ::= TEXTUAL-CONVENTION
   TransportUseType ::= TEXTUAL-CONVENTION

  I would add a prefix aka

   RserENRPServerIdentifierType ::= TEXTUAL-CONVENTION
   RserOperationScopeType ::= TEXTUAL-CONVENTION
   RserPoolHandleType ::= TEXTUAL-CONVENTION
   RserDescriptionType ::= TEXTUAL-CONVENTION
   RserPoolElementIdentifierType ::= TEXTUAL-CONVENTION
   RserPolicyIDType ::= TEXTUAL-CONVENTION
   RserPolicyLoadType ::= TEXTUAL-CONVENTION
   RserPolicyWeightType ::= TEXTUAL-CONVENTION
   RserTransportUseType ::= TEXTUAL-CONVENTION

  Or maybe Enrp is the prefix as late object naming seems toindicate.
  But then I would also make the MIB modulename ENRP-MIB and
  then change
          rserpoolMIB MODULE-IDENTITY
  into
          enrpMIB MODULE-IDENTITY

  I am also not sure I would let the TC names have a suffix of "Type".
  But that may be personal taste.

- further down in the MIB module we see another prefix

       poolElementEntry OBJECT-TYPE

  I would ALWAYS use the same prefix throught the MIB module!

- I blieve that for this one
   enrpServerPort OBJECT-TYPE
   SYNTAX     Unsigned32 (1..65535)
  one should use the InetPort TC from RFC4001

  this is true for other PORT definitions as well

- I see various writable objects that do not describe what their expected
  persistency behaviour is

-    enrpServerASAPAnnounceAddr OBJECT-TYPE
   SYNTAX     InetAddress
   MAX-ACCESS read-only
   STATUS     current
   DESCRIPTION
   "The destination multicast IP address ASAP multicast
   announce messages are sent to."
   ::= { enrpServerEntry 9 }

  RFC4001 (that defines the InetAddress TC) prescribes that the
  DESCRIPTION clause must indicate which object of SYNTAX
  InetAddressType controls the format of this object.

- When I see somehting like
  enrpServerENRPL3Proto OBJECT-TYPE
  SYNTAX     InetAddressType
  MAX-ACCESS read-only
  STATUS     current
  DESCRIPTION
  "The network-layer protocol (IPv4 or IPv6) of an IP address of
  an ENRP transport endpoint."
  ::= { enrpServerENRPAddrTableEntry 2 }

  Then I wonder if it would not be better to SUBTYPE the TC
  So something like

       SYNTAX     InetAddressType{ipv4(1), ipv6(2)}

  The associated
   enrpServerPeerL3Addr OBJECT-TYPE
   SYNTAX     InetAddress

  would then become
   enrpServerPeerL3Addr OBJECT-TYPE
   SYNTAX     InetAddress (SIZE(4|16))

  all this assuming that you explicitly want to only support IPv4 and IPv6 
and
  not DNS and not Scoped IPv6 addresses

- According to RFC4181 this one
         rserpoolMIBConformance OBJECT IDENTIFIER ::= { rserpoolMIB 4 }
   should change to
            rserpoolMIBConformance OBJECT IDENTIFIER ::= { rserpoolMIB 2 }

   I do not see a reason why the recommended MIb structure in RFC4181 would
   not be followed.

- This
   DESCRIPTION "The group of ENRP servers"
   ::= { rserpoolMIBGroups 1 }

  is of course not a good DESCRITPION clause.
  It is I think "The group of objects to manage/monitor ENRP servers."
  or some such.

  Same for otehr groups

-
Abstract

   RSerPool [RFC5351] is a framework to provide reliable server pooling.
   This document defines a SMIv2 compliant Management Information Base
   (MIB) providing access to managed objects in an RSerPool
   implementation.

Normally, citations are not supposed to be in the abstract. But that is a 
NIB,
The document however, does not define a MIB, but a MIB module.
I know some people think this is a nit too. The introduction has irt right.

Seuritty considerations is weak. It does not state anything about the
possible secuirty issues/concerns when peole get read and/or write
access to the various objects.

s /IPSec/IPsec/ as well

I think that RFC4001 is missing from the NORMATIVE references list

The REVISION clause should probably contain something like

   REVISION "200901221012Z" -- January 22, 2009
   DESCRIPTION
   "This version of the MIB module published as RFC xxxx."



Bert Wijnen 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf