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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf