[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP MIB revision 6
Well well...
SMICng says:
W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
"lmpDataLinkPropertyMismatch" is an index for a table
W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
"lmpTeLinkDegraded" is an index for a table
W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
"lmpTeLinkNotDegraded" is an index for a table
W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
"lmpDataLinkVerificationFailure" is an index for a table
W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
specified for "lmpCcOperStatus"
W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
specified for "lmpTeLinkOperStatus"
W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
specified for "lmpDataLinkActiveOperStatus"
W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
specified for "lmpDataLinkPassiveOperStatus"
smilint says:
.\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
`degraded(4)' illegal in sub-type
.\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
`up(1)' illegal in sub-type
.\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
`down(2)' illegal in sub-type
.\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
`degraded(4)' illegal in sub-type
.\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
`up(1)' illegal in sub-type
.\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
`down(2)' illegal in sub-type
.\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
`degraded(4)' illegal in sub-type
.\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
`degraded(4)' illegal in sub-type
.\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
`up(1)' illegal in sub-type
.\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
`down(2)' illegal in sub-type
.\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
`degraded(4)' illegal in sub-type
.\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
`up(1)' illegal in sub-type
.\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
`down(2)' illegal in sub-type
.\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
`degraded(4)' illegal in sub-type
.\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
.\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
.\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' objectshould have an accompanied preceding
`InetAdressType' object
Some details:
1. lmpNbrNodeId OBJECT-TYPE
SYNTAX InetAddress (SIZE(4))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a unique index for an entry in the LmpNbrTable.
This value represents the remote Node ID. The Node ID
address type must be IPv4."
::= { lmpNbrEntry 1 }
You do know that MIB modules need to be IPv6 friendly, no?
Is LMP itself such that it only works with IPv4? I doubt that
IESG will approve new protocols that do not support IPv6.
2. For these 2 objects:
lmpNbrRetransmitInterval LmpRetransmitInterval,
lmpNbrRetryLimit Unsigned32,
You may want to add some text as to howyou intend to deal with
congestion (RFC 2914). This over UDP if I remember well?
I think it would be good to point explicitly to the text in lmp
document (sect 10).
3. lmpNbrRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable is used to create, modify, and/or
delete a row in this table. All read-create objects
can only be changed when lmpNbrRowStatus is active."
That sounds strange. The notInService status was specifically
created to allow changes for cases where changes were not allowed
while row was active. Here you say it MUST be active in order
to make changes? Or did you mean "can not be changed"?
This occurs in more (maybe all) RowStatus objects in this doc.
4. You have some objedts that are not part of a table, yet are
read-write. For example
lmpAdminStatus
lmpCcHelloIntervalDefault
lmpCcHelloIntervalDefaultMin
... and more ...
What is the persistency behaviour of these objects?
In other words: is the value preserved over a reboot?
5. Is lmpCcIsIf not redundant? The way I read it, then if the
lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
an interface, no?
6. lmpRemoteCcAddressType and lmpRemoteCcAddress
In the telink MIB you have done things correctly and as presscribe
by RFC3291. Here you have not. Why ?
Even in this doc you have done it correctly in some places.
7. Mmmmmm??? 52 counters to "measure the performance" of the LMP channels?
Sounds overwhelming to me.
8. Formally, every Counterxx object needs to include in its descritpion
clause which object indicates a potential discontinuity. I understand
that they all are covered by lmpCcCounterDiscontinuityTime in the
same row. Maybe write something about that in the ...Entry description
clause as well if you do not want to add text to every Counter
9. lmpTeLinkTable
DESCRIPTION
"This table contains a collection of TE link."
Means what??
10. lmpLinkVerificationInterval
What does a value of zero mean?
Any comments regarding possible congestiuon if the value is set to
a very small number of msecs?
11. lmpLinkVerificationTable
Or is it better namep lmpTeLinkLinkVerificationTable
and then rename objects as well? If is correct name,
Then maybe rename
lmpTeLinkBitRate to lmpLinkVerificationTeLinkBitRate
lmpTeLinkWavelength to lmpLinkVerificationTeLinkWavelength
12. lmpVerifyTransportMechanism
There are a few TBDs in there. Better decide before you submit to AD
13. lmpTeLinkBitRate
DESCRIPTION
"This is the bit rate at which the Test messages will be
transmitted and is expressed in bytes per second."
A BIT rate that gest expressed in BYTES per second?
Possible of course but strange, no? Why not call it ByteRate?
14. Another 40 or so counters for lmpTeLinkPerfTable ???
15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
OBJECTS { ifIndex,
lmpDataLinkRemoteIfId }
The second object already (implicitly) also contains the value
of the first object (it is the index part of the OID).
16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
them. But when they are enabled, what kind of rates per second
should we fear for in a worst case conidition?
Pls think about both an agent (i.e. an LMP node) generating
them, but also think about a SNMP management station receiving
them from potentially 100s or 1000s of LMP nodes.
17. On page 7 I see:
lmpDataLinkAddressType = unnumbered(1),
Mm... that is not a valid value for an InetAddressType
18. Security COnsiderations
You are not following the guidelines to describe first the
SET (read-write, read-create) issues/concerns/vulnerabilities
and then the read-only sensistivities. So I would not be
surprised to see push back from the Security front.
I have done a pretty serious review... but not exhaustive.
Thanks,
Bert
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: maandag 1 september 2003 20:14
To: 'Martin Dubuc'; Wijnen, Bert (Bert)
Subject: RE: LMP MIB
I have it on my todo-list. I am currently checking te-link mib.
Thanks,
Bert
-----Original Message-----
From: Martin Dubuc [mailto:m.dubuc@rogers.com]
Sent: maandag 1 september 2003 19:55
To: Bert Wijnen
Subject: LMP MIB
Bert,
I know you have been quite busy with all the MPLS drafts. I just wanted to know if you had time review the LMP MIB draft and if not, when you think you'll get around reviewing it.
Regards,
Martin