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

 
Moti,
 
In order to be conformant with the MIB module equipment vendors MUST
implement all the objects which are part of the MANDATORY-GROUPS. 
 
If the editors believe that some objects or tables will not be
mandatory, those need to be included in separate groups. 
 
The clarification about the creation of rows in the mode-specific table
should be included in the DESCRIPTION clause to make the issue clear for
other implementers or users of the document. 
 
Regards,
 
Dan
 


________________________________

	From: Moti Morgenstern [mailto:[email protected]] 
	Sent: Thursday, February 26, 2009 10:23 AM
	To: Victor Sperry
	Cc: Romascanu, Dan (Dan); Menachem Dodge; [email protected]
	Subject: RE: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt
	
	

	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: [email protected] [mailto:[email protected]]
On Behalf Of Victor Sperry
	Sent: Thursday, February 26, 2009 12:05 AM
	To: Romascanu, Dan (Dan); Menachem Dodge; [email protected]
	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:[email protected]] 
	Sent: Wednesday, February 25, 2009 12:14 PM
	To: Victor Sperry; Menachem Dodge; [email protected]
	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: [email protected] on behalf of Victor Sperry
	Sent: Wed 2/25/2009 9:09 PM
	To: Menachem Dodge; [email protected]
	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
[email protected]
https://www.ietf.org/mailman/listinfo/adslmib