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

From: "Martin Dubuc" <[email-masked]>
Date: Wed, 3 Mar 2004 22:43:46 -0500

I have just submitted version 08 of LMP MIB Internet Draft. This new version addresses Bert's comments. At end of this message are Bert's comments and my response on how the MIB has changed to address these comments.

Additional changes are:
- I have addressed point 20 in message below by adding a DEFVAL to all storage type objects, with nonVolatile(3) value.
- I have also updated the example section (lmpVerifyTransportMechanism) following Bert's suggestion (point 24).
- I have added a IANA Considerations section.
- I have updated the Intellectual Property and Copyright sections to comply to RFC 3667.

Martin

----- Original Message -----
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Martin Dubuc" <[email-masked]>; "Wijnen, Bert (Bert)"
<[email-masked]>
Cc: "Adrian Farrel (E-mail)" <[email-masked]>; "Kireeti Kompella
(E-mail)" <[email-masked]>; "Alex Zinin (E-mail)" <[email-masked]>
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:[email-masked]]
> > 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)" <[email-masked]>
> > To: "'Martin Dubuc'" <[email-masked]>; "'Wijnen,
> > Bert (Bert)'"
> > <[email-masked]>
> > 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:[email-masked]]
> > > > > 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)" <[email-masked]>
> > > > > To: <[email-masked]>; <[email-masked]>
> > > > > Cc: <[email-masked]>
> > > > > 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: [email-masked]
> > > > > [mailto:[email-masked]]
> > > > > > > Sent: donderdag 27 november 2003 1:50
> > > > > > > To: [email-masked]
> > > > > > > Cc: [email-masked]
> > > > > > > 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" <[email-masked]>
> > > > > > > > Date: 2003/11/24 Mon PM 12:04:39 EST
> > > > > > > > To: "'Martin Dubuc'" <[email-masked]>
> > > > > > > > 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
> > > > > > >
> > > > >
> > > >
> >