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

Although I personally think it would be better to use TruthValue in the case of
a boolean, I also do believe that the TCs that are now used are NOT a FATAL flaw.
So... although I am not 100% happy with it, I can live with it.

Bert
  ----- Original Message ----- 
  From: David B Harrington 
  To: 'Romascanu, Dan (Dan)' ; 'Scott Baillie' 
  Cc: [email protected] ; 'Andy Bierman' ; 'Bert Wijnen (IETF)' ; 'Menachem Dodge' ; 'Moti Morgenstern' ; 'MIB Doctors (E-mail)' 
  Sent: Monday, February 23, 2009 2:44 PM
  Subject: RE: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt


  Hi,

  The WG obviously did consider this issue, then made an engineering
  decision.
  I think they have made a reasonable case for using their TCs. 
  I think we should back off and let them publish with their TCs.

  dbh

  > -----Original Message-----
  > From: Romascanu, Dan (Dan) [mailto:[email protected]] 
  > Sent: Monday, February 23, 2009 5:40 AM
  > To: Scott Baillie
  > Cc: [email protected]; 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 Scott,
  > 
  > See in-line. 
  > 
  > Thanks and Regards,
  > 
  > Dan
  >  
  > 
  > > -----Original Message-----
  > > From: Scott Baillie [mailto:[email protected]] 
  > > Sent: Sunday, February 22, 2009 8:42 PM
  > > To: Romascanu, Dan (Dan)
  > > Cc: [email protected]; 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. 
  > 
  > 
  > > > 
  > > > > 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? 
  > 
  > 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. 
  > 
  > 
  > > > 
  > > > 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.
  > > > > 
  > > > > 
  > > > > 
  > > > > 
  > > > > 
  > > > > 
  > > > > 
  > > 
  > > 
  >

_______________________________________________
Adslmib mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/adslmib