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

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

Hi Dan,

A few extra comments in line below :

On Sun, 2009-02-22 at 14:49 +0100, Romascanu, Dan (Dan) wrote:
> 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. 
SAB : I feel this argument is a little exaggerated because NMS
    : developers already have to support standard types and
    : user defined types in any given MIB.
    : Adding a few extra TC's to this MIB does not
    : significantly increase the task for NMS developers.
    : We believe that keeping the MIB values in line with
    : the source document is an important enough reason 
    : to define our own TC.
> 
> > 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? 
SAB : There is the potential for negative consequences if a
    : translation is required between the values in the MIB
    : and the source document. On every parameter in the
    : VDSL2 MIB we reference the corresponding parameter in
    : the ITU document.
    : Readers come to expect that the parameters
    : defined in the ITU document are the same ones that
    : are defined in the MIB. If we use the TruthValue type
    : as suggested then 98% of the MIB will be identical to
    : the source document and 2% of the MIB values will require
    : an arbitrary translation.
    : The intention of the authors is to have a direct mapping
    : between the source document and the MIB.
    : The ITU document has been adopted widely by Vendors and
    : there are many solutions available that comply with the ITU
    : specification such as XDSL chip sets and software stacks.
    : If we keep the MIB identical to the ITU document then
    : no translation is required between these compliant systems
    : and a single document is all that is required to understand
    : them all.
> 
> > 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? 
SAB : We are not the authors of the source document so we cannot
    : make any guarantees on their behalf and we cannot anticipate
    : how the ITU document may be changed in the future.
    : I agree that several of the parameters appear to be boolean
    : in nature.
    : If the ITU document uses names like 'reset' and 'idle' then
    : I would prefer to keep those names rather than replace them
    : with 'true' and 'false'. The ITU names carry more meaning
    : and they provide a common vocabulary that can be used and
    : understood by anyone that implements solutions based on
    : the source document.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: Scott Baillie [mailto:sbaillie at bigpond.net.au] 
> > Sent: Sunday, February 22, 2009 2:58 PM
> > To: adslmib at ietf.org
> > 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.
> > 
> > 
> > 
> > 
> > 
> > 
> >