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

From: Scott Baillie <[email-masked]>
Date: Sun, 22 Feb 2009 23:57:57 +1100

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.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 22 Feb 2009 14:49:27 +0100

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 

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-masked]] 
> Sent: Sunday, February 22, 2009 2:58 PM
> To: [email-masked]
> 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 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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 23 Feb 2009 11:40:29 +0100

Hi Scott,

See in-line. 

Thanks and Regards,

Dan

> Sent: Sunday, February 22, 2009 8:42 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; 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,
> > 
> > > using a TC rather than a TruthValue does not significantly impact 
> > > the NMS developer.
> > 
> 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. 

> > > will lead to negative consequences that are worse than 
> the minor sin 
> > > of using a TC instead of TruthValue.
> > 
> 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 
> 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. 

> 'Menachem 
> > > Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); MIB Doctors 
> > > (E-mail)
> > > 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.
> 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.
> > > 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.
> > > 
> 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 
> > > 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.
> > > lose the tight coupling between the source document (
> > > 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
> > > -------

---

From: Scott Baillie <[email-masked]>
Date: Mon, 23 Feb 2009 05:42:15 +1100

Hi Dan,

---

From: Scott Baillie <[email-masked]>
Date: Mon, 23 Feb 2009 22:02:03 +1100

Hi Dan,

See my comments in line.

Regards,

Scott.

> 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.
> 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.
> 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.

---

From: Scott Baillie <[email-masked]>
Date: Tue, 24 Feb 2009 00:19:07 +1100

Hi All,

There has been no consensus at this time on the issue of
using the TruthValue type for boolean objects.

Below is a summary of the discussion so far :

- A number of ADSLMIB contributors have requested that
  the TruthValue type be used for parameters that have
  a boolean nature.

- The MIB authors believe that keeping the MIB identical
  to the source document is more important than following
  the convention regarding TruthValue.

Conclusion
----------
When multiple MIB experts unanimously urge me to make a change
I am reluctant to ignore that advice.
In this case though, I do feel justified in my position
and I have considered both sides of the issue and I
am unlikely to change my mind unless some sort of
new evidence comes to light.

Regards,

Scott.

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 23 Feb 2009 08:44:04 -0500

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

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, February 23, 2009 5:40 AM
> To: Scott Baillie

> > > > NMS developers have to support standard data types and new
data 

> parameters

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 23 Feb 2009 14:49:44 +0100

I would be interested to hear if there are other opinions from the ADSL
MIB Working Group, excluding the editors. 

Thanks and Regards,

Dan

> From: David B Harrington [mailto:[email-masked]] 
> Sent: Monday, February 23, 2009 3:44 PM
> To: Romascanu, Dan (Dan); 'Scott Baillie'
> Cc: [email-masked]; 'Andy Bierman'; 'Bert Wijnen (IETF)'; 
> 'Menachem Dodge'; 'Moti Morgenstern'; 'MIB Doctors (E-mail)'
> The WG obviously did consider this issue, then made an 
> engineering decision.
> > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David B 
> > Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors (E-mail)
> > > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David B 
> > > Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors
> (E-mail)
> > is relatively low. On the other hand, operators need to manage 
> > multiple technologies, not only DSL, so the need for consistency in
> terminology
> > 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
> > > > 
> > > >

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 23 Feb 2009 15:01:15 +0100

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-masked] ; '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,

  dbh

  data