Re: [MIB-DOCTORS] AD review ofdraft-ietf-adslmib-vdsl2-06.txt

Hi Scott,

A few comments and clarification questions: 

> Our choice of 
> using a TC rather than a TruthValue does not significantly 
> impact the NMS developer.

Well, it does add the need to support a new TC, rather than the
TruthValue TC which is already supported by any management application.
There should be good reasons to do it. 

> If we cannot guarantee that the MIB values are the same as 
> the values specified in the source document then I believe 
> that this will lead to negative consequences that are worse 
> than the minor sin of using a TC instead of TruthValue.

Can you explain this? What are the negative consequences? 

> The source document ( G.997.1 ) is a work in progress and can 
> be revised in subsequent publications. It is permissible to 
> add new enumerated values at the end of an existing 
> enumerated type because this type of change is backward 
> compatible. If the ITU add a new enumerated value to an 
> existing boolean parameter then we would be forced to change 
> the type from TruthValue to a TC which would have negative 
> consequences for NMS developers.

This would be indeed a strong argument in favor of using another TC than
TruthValue. I do not see however how this argument applies to
Xdsl2LineSnrMode (can any other state than virtual noise enabled or
disabled ever exist?) and to Xdsl2LineReset (which seems to have two
states: reset or idle = no reset). How could these two be extended in
the future? 

Thanks and Regards,

Dan


> -----Original Message-----
> From: Scott Baillie [mailto:[email protected]] 
> Sent: Sunday, February 22, 2009 2:58 PM
> To: [email protected]
> Cc: Andy Bierman; Bert Wijnen (IETF); David B Harrington; 
> 'Menachem Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); 
> MIB Doctors (E-mail)
> Subject: Re: [Adslmib] [MIB-DOCTORS] AD review 
> ofdraft-ietf-adslmib-vdsl2-06.txt
> 
> Hi All,
> 
> As one of the draft MIB editors I thought I would chime in on 
> the issue of the use of the TruthValue type for boolean parameters.
> 
> I agree that the use of primitive data types where possible 
> is a desirable thing. I also agree that defining a new type 
> that is equivalent to an existing primitive type is undesirable.
> In the case of the VDSL2 MIB, there is a reason why the MIB 
> authors have chosen to define a new type rather than use a 
> standard type ( see below ).
> 
> I do not entirely agree with the position put forward by 
> David ( 2009-Feb-16 ) regarding NMS developers.
> NMS developers have to support standard data types and new 
> data types ( TC's ) when dealing with any MIB. Our choice of 
> using a TC rather than a TruthValue does not significantly 
> impact the NMS developer.
> 
> Also, the long section in David's message regarding 
> interoperability of the SNMP protocol is a way overblown 
> response to our minor sin of using a TC rather than a 
> TruthValue. Our choice of using a TC does not diminish the 
> vendor-neutral, and managed-technology-neutral nature of the 
> SNMP protocol.
> 
> I would like to state the 2 main reasons why we chose to 
> define a new TC rather than use a standard TruthValue type.
> 
> 
> Reason 1
> --------
> The VDSL2 MIB is largely based on the ITU document G.997.1.
> The ITU document specifies all of the VDSL2 management 
> parameters and their values. At the moment, the current VDSL2 
> draft exactly matches all of the parameters in the ITU 
> document and exactly matches all of their values. This is a 
> huge advantage, it means that there is one source document 
> you can turn to when managing XDSL technology.
> If we were to use the TruthValue type as suggested then we 
> would lose the tight coupling between the source document ( 
> G.997.1 ) and the SNMP MIB that we currently enjoy.
> If we cannot guarantee that the MIB values are the same as 
> the values specified in the source document then I believe 
> that this will lead to negative consequences that are worse 
> than the minor sin of using a TC instead of TruthValue.
> 
> 
> Reason 2
> --------
> The source document ( G.997.1 ) is a work in progress and can 
> be revised in subsequent publications. It is permissible to 
> add new enumerated values at the end of an existing 
> enumerated type because this type of change is backward 
> compatible. If the ITU add a new enumerated value to an 
> existing boolean parameter then we would be forced to change 
> the type from TruthValue to a TC which would have negative 
> consequences for NMS developers.
> 
> 
> Summary
> -------
> We recognise that the use of standard types is preferable
> where possible but in the case of the VDSL2 MIB, the advantages
> of having the MIB identical to the source document far
> out weigh the advantages of using standard types.
> 
> 
> 
> Regards,
> 
> Scott.
> 
> 
> 
> 
> 
> 
>