[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Adslmib] FW: [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt
Hello Manachem et al,
For years, I have written software for xDSL access equipment. I have written xDSL drivers and xDSL middleware for DSLAMs and multi-service access equipment such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So my perspective is that of somebody who has to marry MIBs to xDSL chip vendors' API. I have never been an NMS developer.
This is what I see as important, from most important to least important.
1. Ratify and publish the VDSL2 MIB as an RFC.
2. Have the MIB match G.997.1 as much as possible.
3. Simplify the MIB, because it is extremely time-consuming to understand, let alone implement.
4. Use TruthValues instead of TCs.
I see the TruthValue vs TC argument as being akin to arguing over whether or not a developer has followed corporate coding standards. It is a valid concern, but not so important that it should delay the ratification of the document which has been fairly stable for over a year now.
And for what it's worth, I realize that my concerns #2 and #3 are at odds with each other. #2 is more important than #3.
Vic Sperry
Calix Networks
-----Original Message-----
From: adslmib-bounces at ietf.org [mailto:adslmib-bounces at ietf.org] On Behalf Of Menachem Dodge
Sent: Wednesday, February 25, 2009 10:38 AM
To: adslmib at ietf.org
Subject: [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
_______________________________________________
Adslmib mailing list
Adslmib at ietf.org
https://www.ietf.org/mailman/listinfo/adslmib