[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Adslmib] FW: [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt
Hi All,
As Dan has requested, your opinions regarding the issue of using a TC rather than a TruthValue, would be highly appreciated.
Thank you kindly.
Menachem
-----Original Message-----
From: adslmib-bounces at ietf.org [mailto:adslmib-bounces at ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, February 23, 2009 3:50 PM
To: David B Harrington; Scott Baillie
Cc: adslmib at ietf.org; Menachem Dodge; MIB Doctors (E-mail); Bert Wijnen (IETF); Andy Bierman; Moti Morgenstern
Subject: Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt
I would be interested to hear if there are other opinions from the ADSL
MIB Working Group, excluding the editors.
Thanks and Regards,
Dan
> -----Original Message-----
> From: David B Harrington [mailto:dbharrington at comcast.net]
> Sent: Monday, February 23, 2009 3:44 PM
> To: Romascanu, Dan (Dan); 'Scott Baillie'
> Cc: adslmib at ietf.org; 'Andy Bierman'; 'Bert Wijnen (IETF)';
> 'Menachem Dodge'; 'Moti Morgenstern'; 'MIB Doctors (E-mail)'
> 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:dromasca at avaya.com]
> > Sent: Monday, February 23, 2009 5:40 AM
> > To: Scott Baillie
> > 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 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.
> >
> >
> > > >
> > > > > 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: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.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> >
>
>
_______________________________________________
Adslmib mailing list
Adslmib at ietf.org
https://www.ietf.org/mailman/listinfo/adslmib