Re: [Rserpool] Last Call: draft-ietf-rserpool-mib (Reliable ServerPooling: Management Information Base using SMIv2) toExperimental RFC)

[Thomas Dreibholz <[e-mail]>]

On Dienstag 27 Januar 2009, Bert Wijnen (IETF) wrote:

Dear all,

see my comments inline. Attached to this mail, you find an updated version of 
the MIB file.


> 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 do not have SMICng installed, but these problems should be fixed now.


> 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?

Okay, this is useful. Fixed.


> 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

Fixed. Prefix is now "RSerPool" for everything.


>   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

Fixed.


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

Fixed.


> -    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.

Fixed.


> - 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)}

Fixed.

smilint prints "warning: `InetAddressType' should not be subtyped" on this, 
but this seems to be a false positive. The SCTP-MIB also uses sub-typed 
InetAddressType.


>   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

Fixed.


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

1 is used for the ENRP servers branch, 2 is used for PE branch, 3 for PU 
branch. The next available number is 4.


>    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

Fixed.


> -
> 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.

Okay.


> 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

Okay.


> The REVISION clause should probably contain something like
>
>    REVISION "200901221012Z" -- January 22, 2009
>    DESCRIPTION
>    "This version of the MIB module published as RFC xxxx."

I will update this.


Best regards
-- 
=======================================================================
 Dr. Thomas Dreibholz

 University of Duisburg-Essen,                   Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
-----------------------------------------------------------------------
 E-Mail:     [e-mail]
 Homepage:   http://www.iem.uni-due.de/~dreibh
=======================================================================

_______________________________________________
rserpool mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rserpool