|
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 From:
adslmib-bounces at ietf.org [mailto:adslmib-bounces at ietf.org] On Behalf Of Victor
Sperry 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] Hi Victor, |