The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Sep> msg00010



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MIB Doctor review:draft-ietf-mpls-telink-mib-03.txt

  • From: "Martin Dubuc" <dubuc.consulting@rogers.com>
  • Date: Wed, 3 Sep 2003 08:03:37 -0400
  • X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.103.66.219] using ID <dubuc.consulting@rogers.com> at Wed, 3 Sep 2003 08:04:47 -0400

I will submit shortly a MIB that addresses your comments as version 04.
Embedded is my
response to your original message. I need some feedback from you on the last
points.

Martin

----- Original Message -----
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "'Martin Dubuc'" <dubuc.consulting@rogers.com>; "Mpls (E-mail)"
<mpls@uu.net>
Sent: Monday, September 01, 2003 2:43 PM
Subject: MIB Doctor review:draft-ietf-mpls-telink-mib-03.txt


> - Interesting that title page claims that doc expires feb 2003?
>   You porobably mean feb 2004
>

Yes.

> - I get this WMICng warning:
>   W: f(telink.mi2), (1564,19) MIN-ACCESS value identical to access
>      specified for "teLinkBandwidthUnreserved"
>   Seems to me you can just remove that MIN-ACCESS from the MODULE
>   COMPLIANCE.
>

Done.

> - I see
>     TeLinkSonetSdhIndication ::= TEXTUAL-CONVENTION
>       STATUS       current
>       DESCRIPTION
>           "SONET/SDH indication type."
>       SYNTAX       INTEGER {
>                     standard(0),
>                     arbitrary(1)
>                 }
>    Since we normallyh do not start with zero (but with 1), I assume
>    there is a reason you start with zero. Could that reason be described
>    and is there a doc that explains this, so that you refernece it?
>

Use of zero is done to map to the message definition of the interface
switching capability specific information field as specified in
[GMPLS-OSPF]. I have explained this in the description and added reference
to the document that specifies the message format.

> NITS:
>
> - I see
>     teLinkGroups
>        OBJECT IDENTIFIER ::= { teLinkConformance 1 }
>
>     teLinkCompliances
>        OBJECT IDENTIFIER ::= { teLinkConformance 2 }
>   Normally we do it the other way around, first Compliances, then Groups,
>   See page 35, appendix D of draft-ietf-ops-mib-review-guidelines-02.txt
>

Done.

> - I see in OBJECT-GROUP statement things like:
>      DESCRIPTION
>           "Collection of objects needed for the monitoring of
>            resources associated with TE links."
>   I would think the objects *at least a subset) are also usefull for
>   configuration. How about:
>      DESCRIPTION
>           "Collection of objects for management of
>            resources associated with TE links."
>   Most OBJECT-GROUP descritpion clauses have similar "problem".
>

I have updated the description of the groups that used the word monitoring
in the description.

> - I see:
>     teLinkModuleFullCompliance MODULE-COMPLIANCE
>       STATUS current
>       DESCRIPTION
>        "Compliance statement for agents that support the
>         configuration and monitoring of TE Link MIB module."
>    Mmmm. I would word it a bit different:
>        "Compliance statement for agents that support read-create
>         so that both configuration and monitoring of TE Links can
>         be accomplished via this MIB module."
>    Matter of taste I guess.
>

Have updated text accordingly.

> - I see:
>     teLinkModuleReadOnlyCompliance MODULE-COMPLIANCE
>       STATUS current
>       DESCRIPTION
>        "Compliance statement for agents that support the
>         monitoring of TE link MIB module."
>       MODULE -- this module
>
>       -- The mandatory groups have to be implemented
>       -- by all devices supporting TE links. However, they may all
>       -- be supported as read-only objects in the case where manual
>       -- configuration is unsupported.
>
>       MANDATORY-GROUPS    { teLinkGroup,
>                             teLinkBandwidthGroup,
>                             componentLinkBandwidthGroup }
>
>    It seems to me that that all of those 4 comment lines are redundant.
>    The idea of the MODULE-COMPLIANCE statements is that they are both
>    human and machine readable.
>

I am not sure I understand why the fact that the MODULE-COMPLIANCE
statements are human and machine readable makes these comments redundant.

> - I see hyphenation. That is something the RFC-Editor does not want/like.
>

Hyphenation is done automatically with nroff. I don't know how to turn it
off.
Any idea?

> - Section 6 starts with:
>     6.  Brief Description of MIB Objects
>
>        Sections 6.1-6.4 describe objects pertaining to TE links.  The MIB
>        objects were derived from the link bundling document [BUNDLING].
>   How abaout the section 6.5-6.7 ??
>

I have clarified this in the text.

> Thanks,
> Bert