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