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

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 3 Feb 2009 17:14:58 +0100

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: [email-masked] 
  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:     [email-masked]
   Homepage:   http://www.iem.uni-due.de/~dreibh
  =======================================================================
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Thomas Dreibholz <[email-masked]>
Date: Thu, 5 Feb 2009 07:29:51 +0100

Dear all,

attached to this mail you find the updated version of the RSerPool MIB module.

See my comments inline.

Fixed.

Fixed.

> 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
>
> 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 replaced the prefix RSerPool by Rserpool. The warning should be fixed now. 
Bert, please could you run the SMICng program again on the updated MIB module?

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 5 Feb 2009 11:46:08 +0100

Thanks Thomas for the quick turn-arounds. This helps a lot with context-switching.
In other words, this way I can quickly re-check (as opposed to some MIB reviews 
I have done where it takes montsh for a new revision to show up).

The SMICng check show two naming issues left:

  C:\bw\smicng\work>smicng rserpool.inc
  W: f(rserpool.mi2), (761,1) Sequence "RserpoolPoolElementEntry" and Row "rserpoolPEEntry" should have related names
  W: f(rserpool.mi2), (1074,1) Sequence "RserpoolPoolUserEntry" and Row "rserpoolPUEntry" should have related names

  *** 0 errors and 2 warnings in parsing

Further, you claim:
> The normal setup (according to rfc4181) would be something like:
>

Fixed.

But I do nto see that fix, do I ??

Bert

  ----- Original Message ----- 
  From: Thomas Dreibholz 
  To: Bert Wijnen (IETF) 
  Cc: [email-masked] ; MIB Doctors (E-mail) ; David B Harrington 
  Sent: Thursday, February 05, 2009 7:29 AM
  Subject: Re: [Rserpool] Last Call: draft-ietf-rserpool-mib (Reliable ServerPooling: Management Information Base using SMIv2) toExperimental RFC)

  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1

  Dear all,

  See my comments inline.

  Fixed.

  Fixed.

  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.9 (GNU/Linux)

  iEYEARECAAYFAkmKh3IACgkQ32BbsHYPLWVI/wCffN6IE/gABUiaqRHRCaXrcm74
  ZqAAn3ETcUhzC8nPrhoMJ8QeKZ2Iv/CT
  =1J4Z
  -----END PGP SIGNATURE-----

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 5 Feb 2009 12:41:38 +0100

Thanks Thomas.
The new MIB module now compiles clean.
I am happy with this version of the MIB module.

Bert
  ----- Original Message ----- 
  From: Thomas Dreibholz 
  To: Bert Wijnen (IETF) 
  Cc: [email-masked] ; MIB Doctors (E-mail) ; David B Harrington 
  Sent: Thursday, February 05, 2009 12:37 PM
  Subject: Re: [Rserpool] Last Call: draft-ietf-rserpool-mib (Reliable ServerPooling: Management Information Base using SMIv2) toExperimental RFC)

  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1

  Dear all,

  attached to this mail, you find again the latest version of the RSerPool MIB 
  module.

  See my comments inline.

  On Donnerstag 05 Februar 2009, Bert Wijnen (IETF) wrote:
  > Thanks Thomas for the quick turn-arounds. This helps a lot with
  > context-switching. In other words, this way I can quickly re-check (as
  > opposed to some MIB reviews I have done where it takes montsh for a new
  > revision to show up).
  >
  >   W: f(rserpool.mi2), (761,1) Sequence "RserpoolPoolElementEntry" and Row
  > "rserpoolPEEntry" should have related names W: f(rserpool.mi2), (1074,1)
  > Sequence "RserpoolPoolUserEntry" and Row "rserpoolPUEntry" should have
  > related names
  >

  There warnings should be fixed now. Bert, please could you re-run the SMICng 
  program?

  > > Not a fatal flaw, but does not help in readability.

  Sorry, I had attached a slightly older version (without this fix) in my last 
  mail. Now, it should be fixed.

  Best regards
  - -- 

  - -----------------------------------------------------------------------
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.6 (GNU/Linux)

  iD8DBQFJis+T32BbsHYPLWURApfIAKDci0+xEttdSCB9F0AodGzlnDqeDACg006U
  aFwuKQxu0STd+7t04DdzbbI=
  =UeB6
  -----END PGP SIGNATURE-----

---

From: Thomas Dreibholz <[email-masked]>
Date: Thu, 5 Feb 2009 12:37:42 +0100

Dear all,

See my comments inline.

Best regards
- --