[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt
Hi Victor,
The MIB is an abstract model and it is up to the SNMP
agent implementor to map the hardware they are using to
the abstract model.
It is important that SNMP agent implementations
reject configuration that is not achieveable by the
underlying hardware.
In the case of your example with the 3 broad categories,
my suggestion is :
1. Add multiple rows into xdsl2LineConfProfModeSpecTable
for the desired ADSL operating modes.
Each of these rows will have identical values.
2. Add multiple rows into xdsl2LineConfProfModeSpecTable
for the desired ADSL2+ operating modes.
Each of these rows will have identical values.
3. Add multiple rows into xdsl2LineConfProfModeSpecTable
for the desired VDSL2 operating modes.
Each of these rows will have identical values.
Yes, it is wasteful to have redundant rows but that is
the price you pay for having an abstract model.
Regards,
Scott.
On Thu, 2009-02-26 at 07:40 -0800, Victor Sperry wrote:
> 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
>
> On Feb 26, 2009, at 12:23 AM, "Moti Morgenstern"
> <Moti.Morgenstern at ecitele.com> wrote:
>
>
>
> > 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
> > Sent: Thursday, February 26, 2009 12:05 AM
> > To: Romascanu, Dan (Dan); Menachem Dodge; adslmib at ietf.org
> > Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD
> > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> >
> >
> >
> >
> > 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
> >
> >
> _______________________________________________
> Adslmib mailing list
> Adslmib at ietf.org
> https://www.ietf.org/mailman/listinfo/adslmib