Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt

[Scott Baillie <sbaillie at bigpond.net.au>]

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.