draft-ietf-ccamp-lmp-mib-08.txt

----- Original Message -----
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Martin Dubuc" <dubuc.consulting@rogers.com>; "Wijnen, Bert (Bert)"
<bwijnen@lucent.com>
Cc: "Adrian Farrel (E-mail)" <adrian@olddog.co.uk>; "Kireeti Kompella
(E-mail)" <kireeti@juniper.net>; "Alex Zinin (E-mail)" <zinin@psg.com>
Sent: Wednesday, December 31, 2003 1:43 PM
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
>

[Martin] This object represents the exponential backoff or ratio of two
successful retransmission intervals. There is no real unit here. It is a
constant used in calculating the retransmission interval. Description of how
exponential backoff works is explained shortly in section 10.1 of LMP draft
and in RFC 2914. A reference to the draft is already included in the
lmpNbrRetransmitDelta object specification. I have added a bit more text to
explain this in the description clause and have pointed to section of LMP
draft and RFC 2914.

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

[Martin] Have followed advice given in point 7 below.

> 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
>

[Martin] Done.

> 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.

[Martin] Done.

> 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"
??
>

[Martin] MUST use. I have changed text.

> 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?
>

[Martin] Right. Done.

> 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

[Martin] This is indeed the case. I changed all RowStatus accordingly.

>
> 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.
>

[Martin] Good point. References should be to lmpTeLinkEntry and
lmpTeLinkTable in text. Actually, there is no duplication between the two
tables (teLinkTable and lmpTeLinkTable). I have removed the word "also"
because this might suggest some sort of duplication, which does not exist. I
have added some text to describe relationship between lmpTeLinkTable and
teLinkTable in the lmpTeLinkTable.

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

[Martin] Yes. Changed.

> 11. lmpLinkVerificationInterval
>     add a UNITS clause
>

[Martin] Done.

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

[Martin] OK. Changed.

> 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.
>

[Martin] I have added UNITS clause. There are unfortunately no default
values in this MIB. This stems mostly from the vast array of transmission
gear that can implement this MIB.

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

[Martin] No, because this table is extension of lmpTeLinkTable.

> 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])
>

[Martin] Done.

> 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

[Martin] Have added text 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.
>

[Martin] I moved comments in DESCRIPTION clause.

> 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
>

[Martin] Done.

> 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.
>

[Martin] Yes, this makes it a bit clearer.

> 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.
>

[Martin] OK.

> 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

[Martin] There is no reason. Have removed gap.

> 24. I wonder why
>       lmpVerifyTransportMechanism = 1, -- j016OverheadBytes
>       lmpVerifyAllLinks           = verifyAllLinks(1)
>     instead of:
>       lmpVerifyTransportMechanism = j016OverheadBytes(1)
>       lmpVerifyAllLinks           = verifyAllLinks(1)
>     is that not more consistent?
>
[Martin] Not really. lmpVerifyTransportMechanism is actually a bitfield, so
I have shown the integer value that corresponds to the least significant bit
(bit 0) only being set. Maybe there is a better way to express bitfields.
Any suggestions?

> 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.
>

[Martin] I have requested an ifType for LMP a few months ago. I haven't
heard from IANA yet. What should I do?

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

[Martin] Done.

> 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.
>

[Martin] I am not sure if you have checked the examples in the past. But it
may be worth checking them again anyway because the MIB has changed since
the initial review.

> 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.
>

[Martin] Thanks for your effort reviewing the MIB. I will post the new
version shortly.

> Thanks,
> Bert
> p.s. Have a great 2004!
>
> > -----Original Message-----
> > From: Martin Dubuc [mailto:dubuc.consulting@rogers.com]
> > Sent: woensdag 31 december 2003 14:52
> > To: Wijnen, Bert (Bert)
> > Subject: Re: lmp mib status?
> >
> >
> > Bert,
> >
> > Here is 08.
> >
> > Martin
> >
> > ----- Original Message -----
> > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> > To: "'Martin Dubuc'" <dubuc.consulting@rogers.com>; "'Wijnen,
> > Bert (Bert)'"
> > <bwijnen@lucent.com>
> > Sent: Tuesday, December 30, 2003 11:56 AM
> > Subject: RE: lmp mib status?
> >
> >
> > > Martin, did you say you have a rev 8 ready to submit?
> > > If so, why do you not send that one to me, so I can
> > > check the latest you have?
> > >
> > > Thanks,
> > > Bert
> > >
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert)
> > > > Sent: zondag 14 december 2003 23:47
> > > > To: Martin Dubuc; Wijnen, Bert (Bert)
> > > > Subject: RE: lmp mib status?
> > > >
> > > >
> > > > Sorry to have to report that my plate keeps pretty overloaded.
> > > > It may take another week or so.
> > > >
> > > > Thanks,
> > > > Bert
> > > >
> > > > > -----Original Message-----
> > > > > From: Martin Dubuc [mailto:dubuc.consulting@rogers.com]
> > > > > Sent: zondag 14 december 2003 19:52
> > > > > To: Wijnen, Bert (Bert)
> > > > > Subject: Re: lmp mib status?
> > > > >
> > > > >
> > > > > Bert,
> > > > >
> > > > > Do you have an idea when you will be able to review LMP MIB?
> > > > >
> > > > > Martin
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> > > > > To: <dubuc.consulting@rogers.com>; <tnadeau@cisco.com>
> > > > > Cc: <bwijnen@lucent.com>
> > > > > Sent: Tuesday, December 02, 2003 8:05 PM
> > > > > Subject: RE: lmp mib status?
> > > > >
> > > > >
> > > > > > I have to appologize, but there is just to much on my agenda
> > > > > > this week to get to it. SO either go ahead and post the new ID
> > > > > > or wait till next week.
> > > > > >
> > > > > > Thanks,
> > > > > > Bert
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: dubuc.consulting@rogers.com
> > > > > [mailto:dubuc.consulting@rogers.com]
> > > > > > > Sent: donderdag 27 november 2003 1:50
> > > > > > > To: tnadeau@cisco.com
> > > > > > > Cc: bwijnen@lucent.com
> > > > > > > Subject: Re: lmp mib status?
> > > > > > >
> > > > > > >
> > > > > > > Tom,
> > > > > > >
> > > > > > > I was just about to submit a new version with minor changes,
> > > > > > > but Bert asked that I hold off until he reviews the MIB once
> > > > > > > more. I am waiting for his comment to submit an updated
> > > > > > > version that would also address anything he would
> > raise. Bert
> > > > > > > mentioned that he did not have time to review until after
> > > > > > > IETF. Hopefully he will get back to me soon so that we can
> > > > > > > progress to the next level.
> > > > > > >
> > > > > > > Martin
> > > > > > >
> > > > > > > >
> > > > > > > > From: "Thomas D. Nadeau" <tnadeau@cisco.com>
> > > > > > > > Date: 2003/11/24 Mon PM 12:04:39 EST
> > > > > > > > To: "'Martin Dubuc'" <dubuc.consulting@rogers.com>
> > > > > > > > Subject: lmp mib status?
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > What is the status of the LMP MIB?
> > > > > > > > I thought we had a last call in CCAMP that
> > > > > > > > is finished. Has the MIB been updated now?
> > > > > > > >
> > > > > > > > --Tom
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 1
> > > > > > >
> > > > >
> > > >
> >