[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt



Title: 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