Link Management Protocol (LMP) Management Information Base (MIB)
draft-ietf-ccamp-lmp-mib-10

[Ballot comment]
Reviewed by Mary Barnes, Gen-ART

Her review:

Summary:
---------
Draft is ready to publish as Proposed Standard with the correction of
the following editorial nits ( based on the assumption that it's been
reviewed/approved by MIB doctors and run through the MIB compilation
tools).



Nits:
-----
- Needs updating to new template reflecting RFC 3668/3667.
- Blank lines between authors in the document heading is not at all necessary.
- Section 2: Introduction: The 2nd sentence is quite awkward and I
  would propose rewriting (at a minimum the word "which" should be
  changed to "whose")

  from:

      Along with Generalized MPLS (GMPLS) [RFC3471], the Link Management
    Protocol [LMP], which primary purpose is to manage traffic engineering
    (TE) links, is one of the key components of this stan dardization
    activity."

  to something like:

      Generalized MPLS (GMPLS) [RFC3471] and the Link Management Protocol
    [LMP] are key components of this standardization activity. The primary
    purpose of LMP is to manage traffic engineering (TE) links."

- Section 14.1 Normative References: Remove reference to RFC 2026 per
updates to template (curiously, RFC 3668 and 3667 are already listed
as references - do they really need to be as I've not seen this done
in other drafts?)

IANA Last Call Comments:
Upon approval of this document the IANA will register
a new IANA ifType for lmp and a transmission number
for LMP-MIB.  We understand the assignment of the same
number for the transmission and ifType assignments is
requested.

Last AD review (of revision 9)

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: maandag 19 juli 2004 23:00
To: Martin Dubuc; 'Thomas D. Nadeau'; Jonathan Lang; Sudheer
Dharanikota; Evan McGinnis
Cc: Adrian Farrel; Kireeti Kompella (E-mail); Alex Zinin (E-mail)
Subject: RE: draft-ietf-ccamp-lmp-mib-09.txt


OK, I am going through this doc again.
I don't think we need to consider any of the below as blocking.
I'd suggest we go ahead with an IETF Last Call and consider the
below as the first set of IETF Last Call comments.

Alex. this doc is in my name in ID-tracker.
If you want I can handle it and do the shepherding.
Although it is a CCAMP WG document and so the logical Ad to shepherd
this would be you. Possibly better from the IESG review process anyway.
Let me know if you want to take over from here.

1. Seems that some changes have caused inconsistencies

  6.5.  lmpLinkVerificationTable

  The link verification table is used for configuring the LMP link
  verification parameters of TE links. This table is an AUGMENT to the
  lmpTeLinkTable.

  It is now a "sparse augements", since you are using ifIndex (as indeed
  is correct). But using the capital AUGMENT here will give readers the
  wrong impression.

  I also wonder (having done a more close check again) if the table would
  not better be named (and prefixed with) lmpTeLinkVerification.
  That seems even more consistent that it is now. But I won't block on
  this.

2. Use of address in example (on page 6) not according to RFC3330.

      In lmpNbrTable:
      {
        lmpNbrNodeId                  = 'c0010101'H, -- 192.1.1.1

    Better would be:

      In lmpNbrTable:
      {
        lmpNbrNodeId                  = 'c0000201'H, -- 192.0.2.1

    Also... I understand what you are saying here, but this is an index object
    and so it WILL have the length of the octet string as a prefix, so it will
    be prefixed with 04. But probably waht you show is OK.

3. lmpNbrRetransmitDelta OBJECT-TYPE
  SYNTAX        Unsigned32
  UNITS        "bps"
  MAX-ACCESS    read-create
  STATUS        current
  DESCRIPTION
      "This object governs the speed with which the sender increases
        the retransmission interval as explained in section 10 of the
        Link Management Protocol specification, which is based on
        RFC 2914. This value is a power used to express the
        exponential backoff. The ratio of two succesive retransmission
        intervals is (1 + Delta)."
 
  Mmm.. "This value is a power..."  So is UNITS "bps" then correct?


4. I had suggested (in an earlier review) to check for naming consistency
  throughout the document. I see things like
    lmpCcXxxx  where these are just scalar objects
    lmpControlChannelTable  as a table
    lmpCcYyyy  where these are columns in that table
    lmpControlChannelPerfTable  (a table that augments previous table
    lmpCcZzzz  where these are columns in thius 2nd table
  Such does not help humans to easily see which objects are in which
  table or not in a table at all. And it increases the risk of future
  name clashes.
 
  I won't block on it though.

5. lmpTeLinkNbrRemoteNodeId OBJECT-TYPE
  SYNTAX        LmpNodeId
  MAX-ACCESS    read-create
  STATUS        current
  DESCRIPTION
      "This is the Node ID of the TE link remote node. This value
        may be learned during control channel parameter negotiation
        phase (in the Config message). Node ID address type must
        be IPv4."

  Mmmmm the datatype is LmpNodeId. The TC does not say at all that
  this has an "address type". Maybe the DESCRIPTION clause for the TC
  needs some expansion/clarification?

6. lmpGlobalLinkVerificationInterval OBJECT-TYPE
  SYNTAX        Unsigned32
  UNITS        "ms"
  MAX-ACCESS    read-write
  STATUS        current
  DESCRIPTION
      "This object indicates how often the link verification
        procedure is executed. The interval is in milliseconds.

  So similar to an earlier comment that "nm" would be better spelled
  out as "nanometers", I think that here the "ms" would be better
  spelled out to "milliseconds".

  But again I won't block on it. I had just hoped that I do not have to
  list every single instance where similar comments apply.

7. lmpNotificationMaxRate
  is the max number of notifications per second. Mmm... that does not give
  very fine control does it. Why not max per minute? That would give much better
  "congestion avoidance" control. I would not be surprised if Transport ADs
  object to the current control mecahnism.
  Also a DEFVAL of zero (meaning no limit) seems not very prudent.

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: maandag 19 juli 2004 16:51
To: 'Adrian Farrel'; Martin Dubuc; 'Thomas D. Nadeau'
Cc: zinin@psg.com; 'Kireeti Kompella'
Subject: RE: draft-ietf-ccamp-lmp-mib-09.txt


Mmm.... can you explain why you did this:

  E:smimibswork>smi?insmilint -l 6 -s -m -inamelength-32 ./LMP-MIB
  ./LMP-MIB:140: [5] {sequence-order} warning: SEQUENCE element #3
    `lmpNbrRetryLimit' does not match order of columnar objects under
    `lmpNbrEntry'
  ./LMP-MIB:676: [5] {sequence-order} warning: SEQUENCE element #51
    `lmpCcChannelStatusRspSent' does not match order of columnar objects
    under `lmpControlChannelPerfEntry'
  ./LMP-MIB:1569: [5] {sequence-order} warning: SEQUENCE element #38
    `lmpTeChannelStatusRspSent' does not match order of columnar objects
    under `lmpTeLinkPerfEntry'

I know it is only a warning message, but it is weird compared to what
we normally see in a MIB module.

Thanks,
Bert

Alex is the Area Advisor for the CCAMP WG.  However, Bert is listed as the Shepherding AD for this document.  If the document needs to be reassigned to Alex, then please update the I-D Tracker, or notify the Secretariat and we will do so.

AD took MIB Doctor role and reviewed a pre-release of
revision 8. So we assume those concerns will have been addressed when the final revision 8 gets posted to the internet-drafts repository.

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: woensdag 31 december 2003 19:43
To: Martin Dubuc; Wijnen, Bert (Bert)
Cc: Adrian Farrel (E-mail); Kireeti Kompella (E-mail); Alex Zinin
(E-mail)
Subject: MIB DOctor review of prelimenary/preview
draft-ietf-ccamp-lmp-mib-08.txt


Martin,

My comments on the rev 8 that you did send me today:

1. I see
    lmpNbrRetransmitDelta OBJECT-TYPE
      SYNTAX        Unsigned32
      MAX-ACCESS    read-create
      STATUS        current
      DESCRIPTION
        "This object governs the speed with which the sender increases
          the retransmission interval."
    What does the value represent, i.e. what is "speed?
    WHat are the UNITS of speed? May want to add a UNITS clause

2. lmpNbrRowStatus
  need to state which objects/columns MUST have a valid value before
  row can be made active.

3. I would rename
    lmpRemoteCcId                      Unsigned32,
    lmpRemoteCcAddressType            InetAddressType,
    lmpRemoteCcIpAddr                  InetAddress,
  into
    lmpCcRemoteId                      Unsigned32,
    lmpCcRemoteAddressType            InetAddressType,
    lmpCcRemoteIpAddr                  InetAddress,
  so that it is easier to see that they are n the CC table, like
  all the other objects in that table

4. Description clause of lmpRemoteCcIpAddr has:
        configuration. For point-to-point configuration, the
        remote control channel address can be of type unknown
        and this object set the zero length string.
  Might be easier to read this way:
        configuration. For point-to-point configuration, the
        remote control channel address can be of type unknown
        in which case this object must be the zero length string.
5.lmpCcAuthentication OBJECT-TYPE
  SYNTAX        TruthValue
  MAX-ACCESS    read-create
  STATUS        current
  DESCRIPTION
      "This object indicates whether the control channel should use
        authentication."
  So what if it is a true value, can someone decide not to use
  authentication? Or would it be better o state "MUST use authentication" ??

6. lmpCcOperStatus has in DESCRIPTION clasue:
      "The actual operational status of this control channel
        interface."
  I thought it is not always an "interface"? Should the word "interface"
  just be removed as with teh AdminStatus DESCRIPTION?

7. lmpCcRowStatus
  pls describe which objects/columns must have appropriate/valid and
  consistent values before row can be activated. Could be something aka:
    "all read-create objects in a row must have valid and consistent
      values before the row can be activated."
  if that is indeed the case. Some values of course can be set from the
  DEFVAL or other defaults as you describe in the specific objects.

  There are more RowStatus objects in the MIB that have similar cocern
  I will not repeat

8 Performance table.
  - Formally, I think every Counter32 object needs to specify which timer
    functions as the discontinuity timer. I see it is in the DESRIPTION
    clause of the ...Entry. I can live with that. Let us see if anyone barks.
  - Formally all descriptors of a counter32 object need to express plurality.
    Not sure they all do. I can live with it though.

9.  lmpTeLinkEntry OBJECT-TYPE
      SYNTAX        LmpTeLinkEntry
      MAX-ACCESS    not-accessible
      STATUS        current
      DESCRIPTION
        "An entry in this table exists for each ifEntry with an
          ifType of teLink(200), i.e. for every TE link. An ifEntry
          with an ifIndex must exist before the corresponding
          teLinkEntry is created. If a TE link entry in the ifTable is
  do you mean teLinkEntry or lmpTeLinkEntry ??
  I think I would s/a TE link entry in the ifTable/
                    an entry in the ifTable with ifType of teLink(200)/
          destroyed, then so is the corresponding entry in the
          teLinkTable. The administrative status value is controlled
  do you mean teLinkTable or lmpTeLinkTable ??
          from the ifEntry. Setting the administrative status to
          testing prompts LMP to start link verification on the TE link.
  TE link, or LMP TE link ??
          Information about the TE link that is not LMP specific is also
          contained in teLinkTable [TELINK-MIB]."
  so that is duplicated info? If so, pls say so and say that agent is
  required to keep data in sync.
      INDEX        { ifIndex }
 
  As you can see I worry a lot here about being very explicit and clear.
  All these tables and types and names/descriptors that look alike for
  a new implementor can be very confusing!
  Pls do check for this confusing-text and/or possible ambuguity for all
  objects in this table and in the lmpLinkVerificationTable

  It would be good to aad something to the lmpTeLinkTable DESCRIPTION clause
  explaining the rleation ships between this table, teLinkTable and
  ifTable. Even if there is no relation, it is confusing enough to
  then state that explicitly.

10.Would it be btetr to rename lmpTeLinkNbrNodeId to lmpTeLinkNbrRemoteNodeId ?

11. lmpLinkVerificationInterval
    add a UNITS clause

12.lmpVerifyAllLinks OBJECT-TYPE
  SYNTAX        INTEGER { verifyAllLinks(1), verifyNewLinks(2) }
  I think I (personally) would use a TruthValue (personal taste)

13.lmpVerifyTransmissionRate and lmpVerifyWavelength
  add UNITS clause. Any reasonable DEFVALs possible?
  Any usefull DEFVALs for other columns in this table?
  In general, DEFVALs may make it much easier to do rowCreation.

14. No RowStatus for the read-create lmpLinkVerificationTable ??

15. IN DESCRIPTION clause of lmpDataLinkEntry
    I see a citation:
        used to get information in the componentLinkTable
        [TELINK-MIB]."
    When the MIB module gets extracted from the RFC, then the citation
    becomes a dangling ptr. Better to use "RFC xxx" or mention the
    exact MIB MODULE name directly instead of as a citation.

    Pls make sure that other citations do not occur in the MIB module.
    By the way, a citation in a comment line is fine (-- [some-citation])

16. Your naming convention/consistency for lmpDataLinkTable is MUCH better
    than for the earlier tables!

17. lmpDataLinkPerfTable
    What is/are the discontinuityTimer object(s)??
    Probably: lmpDataLinkDiscontinuityTime but you do not say so in ENtry
    DESCRIPTION clause
18. lmpNotificationMaxRate
    I think I would put all of the comment lines about the notifications
    into teh DESCRIPTION clause of this object. Personal taste maybe.
    But realize that some NMS systems use the DESCRIPTION clauses as
    online help for operators.

19. For lmpTeLinkPropertyMismatch
        only the first time a mismatch is detected. Otherwise, for a
        given TE link, this notification can occur no more than once
        per verification interval."
    Can you add the objectName for that verification interval.
    Helps peopel to quickly find it.
    Same for lmpDataLinkPropertyMismatch and some other notifications

20. For all StorageType objects,. is there not a suitable DEFVAL,
    probably nonVolatile !!??

21. WHen I see:
      DESCRIPTION
          "Collection of objects needed for LMP interface
          configuration."
      ::= { lmpGroups 2 }

      lmpCcIsInterfaceGroup OBJECT-GROUP
        OBJECTS { lmpCcIsIf }
        STATUS  current
        DESCRIPTION
          "Objects needed to implement control channels that are
          interfaces."
        ::= { lmpGroups 3 }

    I wonder... are those objects "needed"? People can configure
    manually, no? Or via CLI??
    I would maybe word it different (personal taste, so I will
    not block on this):

          "Collection of objects that represent then LMP interface
          configuration."

    and:

          "Objects representing control channels that are
          interfaces."
  or:
          "Objects which can be used to configure control channels
          that are interfaces."

    or some such.

22. lmpNotificationGroup
      DESCRIPTION
          "Set of notifications implemented in this module.
          None is mandatory."
    remove the "None is mandatory". That is what you state in the
    MODULE-COMPLIANCE. Here you only group the set of notifications
    together, so they can be used in one or more compliance statements
    where a statement is made about being mandatory, conditional or
    optional.
    I'd also change "implemented" into "defined".
    The MIB Module only defines them, an agent implements them.

23. I see:
    1.3.6.1.2.1.10.xx.1.10.1.9  lmpCcAuthentication  [LMP-MIB]: columnar-object-type
    1.3.6.1.2.1.10.xx.1.10.1.12  lmpCcHelloInterval  [LMP-MIB]: columnar-object-type

    why is there a gap between 9 and 12??
    If there is no good reason, then pls don't
    If there is a reason, pls explain it in comments in the MIB
24. I wonder why
      lmpVerifyTransportMechanism = 1, -- j016OverheadBytes
      lmpVerifyAllLinks          = verifyAllLinks(1)
    instead of:
      lmpVerifyTransportMechanism = j016OverheadBytes(1)
      lmpVerifyAllLinks          = verifyAllLinks(1)
    is that not more consistent?

25. you have in Sect 8.1 (and also the sect before that a TBD)
  ifType        The value that is allocated for LMP is TBD.
                This number will be assigned by the IANA.

    So where is that request to IANA made to assign an ifType for LMP?
    You better get that added, so they know where to look for it.
    ANd if it is in this document, then add an IANA Considerations
    section. Might be good anyway to point out all the TBDs that they
    need to look at. It will just speed up the process at a later stage.

admininstrative
- I'd update the dates to 2004 (copyright, REVISION, LAST-UPDATED etc)

I did not check all the non-MIB text in detail. FOr example I did not check
your examples in detail... did I not do so a few months back? If not, I may
want to still do that.

Anyway... it is now 7:40pm on Dec 31st for me. So I go and have my wine and
fun and won't be back till Jan 2nd.

Thanks,
Bert

Initial MIB-doctor/AD review:
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: maandag 1 september 2003 22:43
To: 'Martin Dubuc'
Cc: Ccamp-wg (E-mail)
Subject: 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