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