Re: Last Call: draft-ietf-rserpool-mib (Reliable ServerPooling: Management Information Base using SMIv2) toExperimental RFC)
"Bert Wijnen \(IETF\)" <[email protected]> Tue, 3 Feb 2009 17:14:58 +0100
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Organization | Consultant |
| Message-ID | <910DB442FB3247CDB14FE49A17D96DA3@BertLaptop> |
This is a multi-part message in MIME format.
--===============1804878683==
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_079A_01C98622.F0A9F510"
This is a multi-part message in MIME format.
------=_NextPart_000_079A_01C98622.F0A9F510
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thomas, thanks for the responses.
W.r.t.
>> - According to RFC4181 this one
>> rserpoolMIBConformance OBJECT IDENTIFIER ::=3D { rserpoolMIB =
4 }
>> should change to
>> rserpoolMIBConformance OBJECT IDENTIFIER ::=3D { =
rserpoolMIB 2 }
>
> 1 is used for the ENRP servers branch, 2 is used for PE branch, 3 for =
PU=20
> branch. The next available number is 4.
The normal setup (according to rfc41`81) would be something like:
rserpoolMIBObjects OBJECT-IDENTIFIER ::=3D { rserpoolMIB 1 }
rserpoolMIBConformance OBJECT IDENTIFIER ::=3D { rserpoolMIB 2 }
rserpoolENRPServers OBJECT IDENTIFIER ::=3D { rserpoolMIBObjects 1 =
}
rserpoolPoolElements OBJECT IDENTIFIER ::=3D { rserpoolMIBObjects 2 =
}
rserpoolPoolUsers OBJECT IDENTIFIER ::=3D { rserpoolMIBObjects =
3 }
Your new MIB module has no indertation at all.=20
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 ::=3D SEQUENCE {
rserpoolENRPIndex Unsigned32,
Same further down in the MIB module.
Hope this helps,
Bert Wijnen
----- Original Message -----=20
From: Thomas Dreibholz=20
To: Bert Wijnen (IETF)=20
Cc: [email protected]=20
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=20
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
>
> ::=3D { 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 ::=3D TEXTUAL-CONVENTION
> OperationScopeType ::=3D TEXTUAL-CONVENTION
> PoolHandleType ::=3D TEXTUAL-CONVENTION
> DescriptionType ::=3D TEXTUAL-CONVENTION
> PoolElementIdentifierType ::=3D TEXTUAL-CONVENTION
> PolicyIDType ::=3D TEXTUAL-CONVENTION
> PolicyLoadType ::=3D TEXTUAL-CONVENTION
> PolicyWeightType ::=3D TEXTUAL-CONVENTION
> TransportUseType ::=3D TEXTUAL-CONVENTION
>
> I would add a prefix aka
>
> RserENRPServerIdentifierType ::=3D TEXTUAL-CONVENTION
> RserOperationScopeType ::=3D TEXTUAL-CONVENTION
> RserPoolHandleType ::=3D TEXTUAL-CONVENTION
> RserDescriptionType ::=3D TEXTUAL-CONVENTION
> RserPoolElementIdentifierType ::=3D TEXTUAL-CONVENTION
> RserPolicyIDType ::=3D TEXTUAL-CONVENTION
> RserPolicyLoadType ::=3D TEXTUAL-CONVENTION
> RserPolicyWeightType ::=3D TEXTUAL-CONVENTION
> RserTransportUseType ::=3D 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."
>
> ::=3D { 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."
>
> ::=3D { 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,=20
but this seems to be a false positive. The SCTP-MIB also uses =
sub-typed=20
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 ::=3D { =
rserpoolMIB 4 }
> should change to
> rserpoolMIBConformance OBJECT IDENTIFIER ::=3D { =
rserpoolMIB 2 }
1 is used for the ENRP servers branch, 2 is used for PE branch, 3 for =
PU=20
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"
>
> ::=3D { 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
--=20
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr. Thomas Dreibholz
University of Duisburg-Essen, Room ES210
Inst. for Experimental Mathematics Ellernstra=DFe 29
Computer Networking Technology Group D-45326 Essen/Germany
=
-----------------------------------------------------------------------
E-Mail: [email protected]
Homepage: http://www.iem.uni-due.de/~dreibh
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------=_NextPart_000_079A_01C98622.F0A9F510
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6001.18183" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Thomas, thanks for the responses.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>W.r.t.</FONT></DIV>
<DIV>>> - According to RFC4181 this=20
one<BR>>> =20
rserpoolMIBConformance OBJECT IDENTIFIER ::=3D { rserpoolMIB 4=20
}<BR>>> should change=20
to<BR>>>  =
; =20
rserpoolMIBConformance OBJECT IDENTIFIER ::=3D { rserpoolMIB 2 =
}<BR><FONT=20
size=3D2>></FONT><BR>> 1 is used for the ENRP servers branch, 2 is =
used for=20
PE branch, 3 for PU <BR>> branch. The next available number is =
4.<BR></DIV>
<DIV><FONT size=3D2>The normal setup (according to rfc41`81) would be =
something=20
like:</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT=20
size=3D2>rserpoolMIBObjects &nbs=
p; =20
OBJECT-IDENTIFIER ::=3D { rserpoolMIB 1 }</FONT></DIV>
<DIV><FONT size=3D2>rserpoolMIBConformance OBJECT IDENTIFIER ::=3D =
{=20
rserpoolMIB 2 }<BR></FONT></DIV>
<DIV><FONT size=3D2>rserpoolENRPServers =
OBJECT=20
IDENTIFIER ::=3D { rserpoolMIBObjects 1=20
}<BR>rserpoolPoolElements OBJECT =
IDENTIFIER=20
::=3D { rserpoolMIBObjects 2=20
}<BR>rserpoolPoolUsers &nb=
sp; =20
OBJECT IDENTIFIER ::=3D { rserpoolMIBObjects 3 }</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Your new MIB module has no indertation at all. =
</FONT></DIV>
<DIV><FONT size=3D2>Not a fatal flaw, but does not help in=20
readability.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>The new MIB module causes these SMICng =
warnings:</FONT></DIV>
<DIV><FONT size=3D2>W: f(rserpool.mi2), (137,1) Sequence =
"RSerPoolENRPEntry" and=20
Row "rserpoolENRPEntry" should have related names<BR>W: f(rserpool.mi2), =
(276,1)=20
Sequence "RSerPoolENRPPoolEntry" and Row "rserpoolENRPPoolEntry" should =
have=20
related names<BR>W: f(rserpool.mi2), (315,1) Sequence=20
"RSerPoolENRPPoolElementEntry" and Row "rserpoolENRPPoolElementEntry" =
should=20
have related names<BR>W: f(rserpool.mi2), (465,1) Sequence=20
"RSerPoolENRPASAPAddrTableEntry" and Row =
"rserpoolENRPASAPAddrTableEntry" should=20
have related names<BR>W: f(rserpool.mi2), (520,1) Sequence=20
"RSerPoolENRPUserAddrTableEntry" and Row =
"rserpoolENRPUserAddrTableEntry" should=20
have related names<BR>W: f(rserpool.mi2), (584,1) Sequence=20
"RSerPoolENRPENRPAddrTableEntry" and Row =
"rserpoolENRPENRPAddrTableEntry" should=20
have related names<BR>W: f(rserpool.mi2), (636,1) Sequence=20
"RSerPoolENRPPeerEntry" and Row "rserpoolENRPPeerEntry" should have =
related=20
names<BR>W: f(rserpool.mi2), (695,1) Sequence =
"RSerPoolENRPPeerAddrTableEntry"=20
and Row "rserpoolENRPPeerAddrTableEntry" should have related names<BR>W: =
f(rserpool.mi2), (753,1) Sequence "RSerPoolPoolElementEntry" and Row=20
"rserpoolPEEntry" should have related names<BR>W: f(rserpool.mi2), =
(941,1)=20
Sequence "RSerPoolPEASAPAddrTableEntry" and Row =
"rserpoolPEASAPAddrTableEntry"=20
should have related names<BR>W: f(rserpool.mi2), (994,1) Sequence=20
"RSerPoolPEUserAddrTableEntry" and Row "rserpoolPEUserAddrTableEntry" =
should=20
have related names<BR>W: f(rserpool.mi2), (1060,1) Sequence=20
"RSerPoolPoolUserEntry" and Row "rserpoolPUEntry" should have related=20
names</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>*** 0 errors and 12 warnings in =
parsing<BR></FONT></DIV>
<DIV><FONT size=3D2>Probably cause by sticking to a better naming =
convention. Bit=20
it would be consistent throughout.</FONT></DIV>
<DIV><FONT size=3D2>It seems likd what you have is not absolutely =
incorrect.=20
Yet... it is certainly not following the</FONT></DIV>
<DIV><FONT size=3D2>way things are normally done.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>I think this is more what I would =
expect:</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2> rserpoolENRPTable =
OBJECT-TYPE<BR> =20
SYNTAX SEQUENCE OF =
RserpoolENRPEntry</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Then the ENTRY spec should read like:</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2> rserpoolENRPEntry =
OBJECT-TYPE<BR> =20
SYNTAX RserpoolENRPEntry</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>And then:</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2> RserpoolENRPEntry ::=3D SEQUENCE =
{<BR> =20
rserpoolENRPIndex &n=
bsp; =20
Unsigned32,</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Same further down in the MIB module.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Hope this helps,</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Bert Wijnen</FONT></DIV>
<DIV><FONT size=3D2> </DIV>
<DIV></FONT>----- Original Message ----- </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
<A [email protected] =
href=3D"mailto:[email protected]">Thomas=20
Dreibholz</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
[email protected]=20
href=3D"mailto:[email protected]">Bert Wijnen (IETF)</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
[email protected]=20
href=3D"mailto:[email protected]">[email protected]</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, February 03, =
2009 1:49=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [Rserpool] Last =
Call:=20
draft-ietf-rserpool-mib (Reliable ServerPooling: Management =
Information Base=20
using SMIv2) toExperimental RFC)</DIV>
<DIV><FONT size=3D2></FONT><BR></DIV>On Dienstag 27 Januar 2009, Bert =
Wijnen=20
(IETF) wrote:<BR><BR>Dear all,<BR><BR>see my comments inline. Attached =
to this=20
mail, you find an updated version of <BR>the MIB file.<BR><BR><BR>> =
Pls=20
note that I am not on the resepool mailing list, so send an =
explicit<BR>>=20
cc/bcc if<BR>> you want me to see it.<BR>><BR>> I am getting =
these=20
SMICng (strict checking) errors/warnings:<BR>><BR>>=20
C:\bw\smicng\work>smicng rserpool.inc<BR>> W: f(rserpool.mi2), =
(133,4)=20
Sequence "ENRPServerEntry" and Row<BR>> "enrpServerEntry" should =
have=20
related<BR>> names<BR>> W: f(rserpool.mi2), (167,15) Item=20
"enrpServerOperationScope" should have<BR>> SIZE specified<BR>> =
W:=20
f(rserpool.mi2), (272,4) Sequence "ENRPServerPoolEntry" and =
Row<BR>>=20
"enrpServerPoolEntry" should have<BR>> related names<BR>> W:=20
f(rserpool.mi2), (295,15) Item "enrpServerPoolHandle" should have =
SIZE<BR>>=20
specified<BR>> W: f(rserpool.mi2), (311,4) Sequence=20
"ENRPServerPoolElementEntry" and Row<BR>>=20
"enrpServerPoolElementEntry<BR>> " should have related =
names<BR>> W:=20
f(rserpool.mi2), (461,4) Sequence "ENRPServerASAPAddrTableEntry" and=20
Row<BR>> "enrpServerASAPAddrTableE<BR>> ntry" should have =
related=20
names<BR>> W: f(rserpool.mi2), (515,4) Sequence=20
"ENRPServerUserAddrTableEntry" and Row<BR>>=20
"enrpServerUserAddrTableE<BR>> ntry" should have related =
names<BR>> W:=20
f(rserpool.mi2), (560,15) Item "enrpServerUserL3Opaque" should have=20
SIZE<BR>> specified<BR>> W: f(rserpool.mi2), (578,4) Sequence=20
"ENRPServerENRPAddrTableEntry" and Row<BR>>=20
"enrpServerENRPAddrTableE<BR>> ntry" should have related =
names<BR>> W:=20
f(rserpool.mi2), (629,4) Sequence "ENRPServerPeerEntry" and =
Row<BR>>=20
"enrpServerPeerEntry" should have<BR>> related names<BR>> W:=20
f(rserpool.mi2), (688,4) Sequence "ENRPServerPeerAddrTableEntry" and=20
Row<BR>> "enrpServerPeerAddrTableE<BR>> ntry" should have =
related=20
names<BR>> W: f(rserpool.mi2), (784,15) Item =
"poolElementOperationScope"=20
should have<BR>> SIZE specified<BR>> W: f(rserpool.mi2), =
(792,15) Item=20
"poolElementPoolHandle" should have SIZE<BR>> specified<BR>> W:=20
f(rserpool.mi2), (1026,15) Item "poolElementUserL3Opaque" should =
have<BR>>=20
SIZE specified<BR>> W: f(rserpool.mi2), (1071,15) Item=20
"poolUserOperationScope" should have<BR>> SIZE specified<BR>> W: =
f(rserpool.mi2), (1079,15) Item "poolUserPoolHandle" should have =
SIZE<BR>>=20
specified<BR>><BR>> *** 0 errors and 16 warnings in =
parsing<BR><BR>I do=20
not have SMICng installed, but these problems should be fixed=20
now.<BR><BR><BR>> I wonder=20
if<BR>><BR>> ::=3D { =
mib-2 xxx }=20
-- To be IANA Assigned!!!<BR>><BR>> is appropriate for an =
EXPERIMENTAL=20
MIB module<BR>> Probably want to root it under the experimental=20
tree?<BR><BR>Okay, this is useful. Fixed.<BR><BR><BR>> Further I =
see a lot=20
of naming inconsistencies<BR>><BR>> - Normally, in a MIB module =
we=20
prefix all TCs with a prefix that makes it<BR>> =
clear<BR>> =20
which module these TCs are defined in. This is to try and avoid that=20
the<BR>> TC<BR>> names/identifiers will not conflict =
with=20
any existing or future other<BR>> TCs. Specifically for a =
experiemntal=20
module you do not want to have<BR>> conflicts with standards track =
MIB=20
modules.<BR>> So for =
these<BR>><BR>> =20
ENRPServerIdentifierType ::=3D =
TEXTUAL-CONVENTION<BR>> =20
OperationScopeType ::=3D TEXTUAL-CONVENTION<BR>> =20
PoolHandleType ::=3D TEXTUAL-CONVENTION<BR>> =20
DescriptionType ::=3D TEXTUAL-CONVENTION<BR>> =20
PoolElementIdentifierType ::=3D =
TEXTUAL-CONVENTION<BR>> =20
PolicyIDType ::=3D TEXTUAL-CONVENTION<BR>> =
PolicyLoadType=20
::=3D TEXTUAL-CONVENTION<BR>> PolicyWeightType =
::=3D=20
TEXTUAL-CONVENTION<BR>> TransportUseType ::=3D=20
TEXTUAL-CONVENTION<BR>><BR>> I would add a prefix=20
aka<BR>><BR>> RserENRPServerIdentifierType =
::=3D=20
TEXTUAL-CONVENTION<BR>> RserOperationScopeType =
::=3D=20
TEXTUAL-CONVENTION<BR>> RserPoolHandleType ::=3D=20
TEXTUAL-CONVENTION<BR>> RserDescriptionType ::=3D =
TEXTUAL-CONVENTION<BR>> =
RserPoolElementIdentifierType ::=3D=20
TEXTUAL-CONVENTION<BR>> RserPolicyIDType ::=3D=20
TEXTUAL-CONVENTION<BR>> RserPolicyLoadType ::=3D=20
TEXTUAL-CONVENTION<BR>> RserPolicyWeightType =
::=3D=20
TEXTUAL-CONVENTION<BR>> RserTransportUseType =
::=3D=20
TEXTUAL-CONVENTION<BR><BR>Fixed. Prefix is now "RSerPool" for=20
everything.<BR><BR><BR>> Or maybe Enrp is the prefix as =
late=20
object naming seems toindicate.<BR>> But then I would =
also make=20
the MIB modulename ENRP-MIB and<BR>> then=20
=
change<BR>>  =
;=20
rserpoolMIB MODULE-IDENTITY<BR>> =20
=
into<BR>> =
enrpMIB MODULE-IDENTITY<BR>><BR>> I am also not sure =
I would=20
let the TC names have a suffix of "Type".<BR>> But that =
may be=20
personal taste.<BR>><BR>> - further down in the MIB module we =
see=20
another =
prefix<BR>><BR>> =20
poolElementEntry OBJECT-TYPE<BR>><BR>> I would =
ALWAYS use=20
the same prefix throught the MIB module!<BR>><BR>> - I blieve =
that for=20
this one<BR>> enrpServerPort=20
OBJECT-TYPE<BR>> SYNTAX =20
Unsigned32 (1..65535)<BR>> one should use the InetPort =
TC from=20
RFC4001<BR>><BR>> this is true for other PORT =
definitions as=20
well<BR><BR>Fixed.<BR><BR><BR>> - I see various writable objects =
that do=20
not describe what their expected<BR>> persistency =
behaviour=20
is<BR><BR>Fixed.<BR><BR><BR>> - =20
enrpServerASAPAnnounceAddr OBJECT-TYPE<BR>> =20
SYNTAX InetAddress<BR>> =20
MAX-ACCESS read-only<BR>> =
STATUS =20
current<BR>> =
DESCRIPTION<BR>> "The=20
destination multicast IP address ASAP =
multicast<BR>> =20
announce messages are sent to."<BR>><BR>> =
::=3D {=20
enrpServerEntry 9 }<BR>><BR>> RFC4001 (that defines =
the=20
InetAddress TC) prescribes that the<BR>> DESCRIPTION =
clause=20
must indicate which object of SYNTAX<BR>> =
InetAddressType=20
controls the format of this object.<BR><BR>Fixed.<BR><BR><BR>> - =
When I see=20
somehting like<BR>> enrpServerENRPL3Proto=20
OBJECT-TYPE<BR>> SYNTAX =20
InetAddressType<BR>> MAX-ACCESS =
read-only<BR>> =20
STATUS current<BR>> =20
DESCRIPTION<BR>> "The network-layer protocol (IPv4 or =
IPv6) of=20
an IP address of<BR>> an ENRP transport=20
endpoint."<BR>><BR>> ::=3D { =
enrpServerENRPAddrTableEntry 2=20
}<BR>><BR>> Then I wonder if it would not be better =
to=20
SUBTYPE the TC<BR>> So something=20
like<BR>><BR>> =20
SYNTAX InetAddressType{ipv4(1),=20
ipv6(2)}<BR><BR>Fixed.<BR><BR>smilint prints "warning: =
`InetAddressType'=20
should not be subtyped" on this, <BR>but this seems to be a false =
positive.=20
The SCTP-MIB also uses sub-typed=20
<BR>InetAddressType.<BR><BR><BR>> The=20
associated<BR>> enrpServerPeerL3Addr=20
OBJECT-TYPE<BR>> SYNTAX =20
InetAddress<BR>><BR>> would then=20
become<BR>> enrpServerPeerL3Addr=20
OBJECT-TYPE<BR>> SYNTAX =20
InetAddress (SIZE(4|16))<BR>><BR>> all this assuming =
that=20
you explicitly want to only support IPv4 and IPv6<BR>>=20
and<BR>> not DNS and not Scoped IPv6=20
addresses<BR><BR>Fixed.<BR><BR><BR>> - According to RFC4181 this=20
one<BR>> =20
rserpoolMIBConformance OBJECT IDENTIFIER ::=3D { rserpoolMIB 4=20
}<BR>> should change=20
=
to<BR>> &nb=
sp; =20
rserpoolMIBConformance OBJECT IDENTIFIER ::=3D { rserpoolMIB 2 =
}<BR><BR>1 is=20
used for the ENRP servers branch, 2 is used for PE branch, 3 for PU=20
<BR>branch. The next available number is =
4.<BR><BR><BR>> =20
I do not see a reason why the recommended MIb structure in RFC4181=20
would<BR>> not be followed.<BR>><BR>> -=20
This<BR>> DESCRIPTION "The group of ENRP=20
servers"<BR>><BR>> ::=3D { rserpoolMIBGroups 1 =
}<BR>><BR>> is of course not a good DESCRITPION=20
clause.<BR>> It is I think "The group of objects to=20
manage/monitor ENRP servers."<BR>> or some=20
such.<BR>><BR>> Same for otehr=20
groups<BR><BR>Fixed.<BR><BR><BR>> -<BR>>=20
Abstract<BR>><BR>> RSerPool [RFC5351] is a =
framework=20
to provide reliable server pooling.<BR>> This =
document=20
defines a SMIv2 compliant Management Information=20
Base<BR>> (MIB) providing access to managed =
objects in an=20
RSerPool<BR>> implementation.<BR>><BR>> =
Normally,=20
citations are not supposed to be in the abstract. But that is =
a<BR>>=20
NIB,<BR>> The document however, does not define a MIB, but a MIB=20
module.<BR>> I know some people think this is a nit too. The =
introduction=20
has irt right.<BR><BR>Okay.<BR><BR><BR>> Seuritty considerations is =
weak.=20
It does not state anything about the<BR>> possible secuirty =
issues/concerns=20
when peole get read and/or write<BR>> access to the various=20
objects.<BR>><BR>> s /IPSec/IPsec/ as well<BR>><BR>> I =
think that=20
RFC4001 is missing from the NORMATIVE references=20
list<BR><BR>Okay.<BR><BR><BR>> The REVISION clause should probably =
contain=20
something like<BR>><BR>> REVISION =
"200901221012Z" --=20
January 22, 2009<BR>> =20
DESCRIPTION<BR>> "This version of the MIB module=20
published as RFC xxxx."<BR><BR>I will update this.<BR><BR><BR>Best=20
regards<BR>--=20
=
<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>=
Dr.=20
Thomas Dreibholz<BR><BR> University of=20
=
Duisburg-Essen, &nbs=
p; =20
Room ES210<BR> Inst. for Experimental=20
=
Mathematics &n=
bsp; =20
Ellernstra=DFe 29<BR> Computer Networking Technology=20
=
Group =20
D-45326=20
=
Essen/Germany<BR>--------------------------------------------------------=
---------------<BR> E-Mail: =20
<A=20
=
href=3D"mailto:[email protected]">[email protected]</A><BR> =
Homepage: =20
<A=20
=
href=3D"http://www.iem.uni-due.de/~dreibh">http://www.iem.uni-due.de/~dre=
ibh</A><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
<BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_079A_01C98622.F0A9F510--
--===============1804878683==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
rserpool mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rserpool
--===============1804878683==--