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

["Bert Wijnen \(IETF\)" <[e-mail]>]

Thomas, thanks for the responses.

W.r.t.
>> - 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.

The normal setup (according to rfc41`81) would be something like:

rserpoolMIBObjects          OBJECT-IDENTIFIER ::= { rserpoolMIB 1 }
rserpoolMIBConformance  OBJECT IDENTIFIER ::= { rserpoolMIB 2 }

rserpoolENRPServers       OBJECT IDENTIFIER ::= { rserpoolMIBObjects 1 }
rserpoolPoolElements      OBJECT IDENTIFIER ::= { rserpoolMIBObjects 2 }
rserpoolPoolUsers           OBJECT IDENTIFIER ::= { rserpoolMIBObjects 3 }

Your new MIB module has no indertation at all. 
Not a fatal flaw, but does not help in readability.

The new MIB module causes these SMICng warnings:
W: f(rserpool.mi2), (137,1) Sequence "RSerPoolENRPEntry" and Row "rserpoolENRPEntry" should have related names
W: f(rserpool.mi2), (276,1) Sequence "RSerPoolENRPPoolEntry" and Row "rserpoolENRPPoolEntry" should have related names
W: f(rserpool.mi2), (315,1) Sequence "RSerPoolENRPPoolElementEntry" and Row "rserpoolENRPPoolElementEntry" should have related names
W: f(rserpool.mi2), (465,1) Sequence "RSerPoolENRPASAPAddrTableEntry" and Row "rserpoolENRPASAPAddrTableEntry" should have related names
W: f(rserpool.mi2), (520,1) Sequence "RSerPoolENRPUserAddrTableEntry" and Row "rserpoolENRPUserAddrTableEntry" should have related names
W: f(rserpool.mi2), (584,1) Sequence "RSerPoolENRPENRPAddrTableEntry" and Row "rserpoolENRPENRPAddrTableEntry" should have related names
W: f(rserpool.mi2), (636,1) Sequence "RSerPoolENRPPeerEntry" and Row "rserpoolENRPPeerEntry" should have related names
W: f(rserpool.mi2), (695,1) Sequence "RSerPoolENRPPeerAddrTableEntry" and Row "rserpoolENRPPeerAddrTableEntry" should have related names
W: f(rserpool.mi2), (753,1) Sequence "RSerPoolPoolElementEntry" and Row "rserpoolPEEntry" should have related names
W: f(rserpool.mi2), (941,1) Sequence "RSerPoolPEASAPAddrTableEntry" and Row "rserpoolPEASAPAddrTableEntry" should have related names
W: f(rserpool.mi2), (994,1) Sequence "RSerPoolPEUserAddrTableEntry" and Row "rserpoolPEUserAddrTableEntry" should have related names
W: f(rserpool.mi2), (1060,1) Sequence "RSerPoolPoolUserEntry" and Row "rserpoolPUEntry" should have related names

*** 0 errors and 12 warnings in parsing

Probably cause by sticking to a better naming convention. Bit it would be consistent throughout.
It seems likd what you have is not absolutely incorrect. Yet... it is certainly not following the
way things are normally done.

I think this is more what I would expect:

   rserpoolENRPTable OBJECT-TYPE
   SYNTAX     SEQUENCE OF RserpoolENRPEntry

Then the ENTRY spec should read like:

   rserpoolENRPEntry OBJECT-TYPE
   SYNTAX     RserpoolENRPEntry

And then:

   RserpoolENRPEntry ::= SEQUENCE {
   rserpoolENRPIndex                Unsigned32,


Same further down in the MIB module.

Hope this helps,

Bert Wijnen

----- Original Message ----- 
  From: Thomas Dreibholz 
  To: Bert Wijnen (IETF) 
  Cc: [e-mail] 
  Sent: Tuesday, February 03, 2009 1:49 PM
  Subject: Re: [Rserpool] Last Call: draft-ietf-rserpool-mib (Reliable ServerPooling: Management Information Base using SMIv2) toExperimental RFC)


  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