Moti, Scott, and the rest,
The intent of row creation in the mode-specific table is clear to me. But I could not see how to implement it with the chips I've looked at. Conexant and Broadcom both supply some mode-specific provisioning items, but the modes are more coarse than what the MIB uses. For example, I may be able to provide three mode-specific settings, ADSL, ADSL2+, and VDSL2. How would I map the MIB to such a chip? I would have to, for example, demand that the operator set exactly all the bits that cover every ADSL technology. If he leaves out one bit, or sets one too many, I would have to reject the Set operation. It didn't seem reasonable to me.
Vic
Sent from my iPhone
Hi Victor,
I agree that the MIB is relatively big and that’s natural for
equipment vendors to decide what tables they wish to implement in each phase of
their product life. Sometimes it can also go down to a per attribute decision.
For example, PM thresholds and notifications will not be the first sections you
implement if you have a Time-To-Market problem because configuration is
normally more important.
Regarding to the mode-specific configuration, you actually touched
a very good issue: Do we really need a row “for
every possible value of xdsl2LConfProfXdslMode”?
So, just to clarify the terminology, you never create rows in
the mode-specific table for “values of xdsl2LConfProfXdslMode”
but only for those DSL modes that are enabled (it’s a bitmap) in the
specific configuration profile. In other words, you need to deal only with the
specific “value” that you use in the related configuration profile.
In the IETF draft MIB only the “default row” is
mandatory. It’s up to the operator to decide that several enabled DSL modes
in the configuration profile are so distinct that they require separate mode-specific
configuration (one or more rows). When that happens the operator creates rows
for those modes, while all other modes are being covered by the same “default”
row.
Regards,
Moti
Hi Dan,
Since you ask, I think the MIB is huge and in some cases
impractical. For example I could not figure out how to implement
xdsl2LineConfProfModeSpecTable for every possible value of
xdsl2LConfProfXdslMode. Equipment vendors will select a subset of the MIB to
implement. But I think it needs to be ratified. It doesn’t need to be
perfect in its first RFC form.
And for the record, I did not implement an SNMP agent. I used
the MIB in a design as a chip-independent driver API. And also for the record,
that approach turned out to be impractical due to time constraints and the need
to remain compatible with older APIs already in our system.
Vic
From: Romascanu, Dan
(Dan) [mailto:dromasca at avaya.com]
Sent: Wednesday, February 25, 2009 12:14 PM
To: Victor Sperry; Menachem Dodge; adslmib at ietf.org
Subject: RE: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt
Hi Victor,
Thank you for your feedback. I am glad to hear that people implementing agents
in this space participate in this work. I have a question not directly related
to the question asked by Menachem. What is your opinion about the size of this
MIB module and its implementability on agents?
Thanks and Regards,
Dan
-----Original Message-----
From: adslmib-bounces at ietf.org on behalf of Victor Sperry
Sent: Wed 2/25/2009 9:09 PM
To: Menachem Dodge; adslmib at ietf.org
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt
Hello Manachem et al,
For years, I have written software for xDSL access equipment. I have written
xDSL drivers and xDSL middleware for DSLAMs and multi-service access equipment
such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So my perspective is
that of somebody who has to marry MIBs to xDSL chip vendors' API. I have never
been an NMS developer.
This is what I see as important, from most important to least important.
1. Ratify and publish the VDSL2 MIB as an RFC.
2. Have the MIB match G.997.1 as much as possible.
3. Simplify the MIB, because it is extremely time-consuming to understand, let
alone implement.
4. Use TruthValues instead of TCs.
I see the TruthValue vs TC argument as being akin to arguing over whether or
not a developer has followed corporate coding standards. It is a valid concern,
but not so important that it should delay the ratification of the document
which has been fairly stable for over a year now.
And for what it's worth, I realize that my concerns #2 and #3 are at odds with
each other. #2 is more important than #3.
Vic Sperry
Calix Networks
|