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

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

Hi Dan,

See my comments in line.

Regards,

Scott.

On Mon, 2009-02-23 at 11:40 +0100, Romascanu, Dan (Dan) wrote:
> Hi Scott,
> 
> See in-line. 
> 
> Thanks and Regards,
> 
> Dan
>  
> 
> > -----Original Message-----
> > From: Scott Baillie [mailto:sbaillie at bigpond.net.au] 
> > Sent: Sunday, February 22, 2009 8:42 PM
> > To: Romascanu, Dan (Dan)
> > Cc: adslmib at ietf.org; Andy Bierman; Bert Wijnen (IETF); David 
> > B Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors (E-mail)
> > Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
> > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> > 
> > 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.
> 
> We disagree.
> 
> The chances of a network operator to read a source document from ITU-T
> is relatively low. On the other hand, operators need to manage multiple
> technologies, not only DSL, so the need for consistency in terminology
> works in the opposite direction than the one that you are supporting. 
> 
SAB : We ( the MIB authors ) disagree with this objection.
    : The choice of using a TC instead of a TruthValue does not
    : make the VDSL2 MIB inconsistent and it does not require
    : the network operator to read the source document.
    : If a network operator needs to communicate with another
    : ITU compliant vendor then the need for consistency in
    : terminology is important. Our choice of using a TC does
    : not impose an impediment on the network operator.
> 
> > > 
> > > > 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.
> 
> What is the semantics of 'idle' that would be lost? 
> 
SAB : I have always considered that using appropriate names is
    : important. The term 'idle' will be understood by other
    : ITU compliant vendors but 'false' wont be.
> I do not hear a strong argument for new TCs, but an acknowledgement that
> ' that several of the parameters appear to be boolean in nature'. My
> recommendation is to take out these TCs and change the SYNTAX of the
> respective objects in the next version of the document to TruthValue. 
> 
SAB : We never stated that there are no boolean parameters, we just
    : stated that we have a good reason for not using the
    : TruthValue type.
> 
> > > 
> > > 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.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > 
> >