|
If the
consensus of the Working Group is that the correction from dBm to dB is
equivalent to fixing a typo I have no problem with approving the Errata.
Dan
Dan and others.
Initially my reading was that a change of the SYNTAX was
proposed/suggested.
That is clearly a NO-GO without deprecating the object and
creating a new one.
My current understanding is that the only change suggested
is to
change the UNITS clause from 0,25dBm into 0,25
dB.
If we look at the object in RGV3728, then we
see:
vdslPhysCurrSnrMgn
OBJECT-TYPE
SYNTAX Integer32
(-127..127)
UNITS
"0.25dBm"
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"Noise Margin as seen by this Vtu with respect to
its
received
signal in 0.25dB. The effective range
is
-31.75 to
+31.75 dB."
REFERENCE "T1E1.4/2000-009R3, Part 1, common
spec"
::= { vdslPhysEntry 5
}
And so, the spec does show a discrepancy between the UNITS
clause
and the DESCRIPTION clause. So if the subject matter experts
agree
that 0,25dB is the correct units for this object, then I am
fine to consider
the UNITS clause to have a typo and so to correct this as an
errata.
Hope this helps,
Bert
----- Original Message -----
Sent: Monday, June 01, 2009 10:36
AM
Subject: Re: [Adslmib] RFC3728 (1788)
(RFC Errata System)
I am afraid that such a change is not possible in an errata
without
deprecating the object and defining a new object.
According to RFC 2578, Section 10.2
(6) A UNITS clause
may be added.
It is not clear if the UNITS clause can just be changed
as Menachem
proposes. If both dB and dBm are valid units it looks like a
change in
the semantics of the object. Even if this was just a typo I
doubt the
change would be acceptable.
Deprecating an object and
defining a new one requires a revision of the
MIB module. Such change
cannot be made in an errata.
I would like to hear Bert's opinion.
Dan
> -----Original Message-----
> From:
adslmib-bounces at ietf.org
> [mailto:adslmib-bounces at ietf.org] On Behalf Of Menachem
Dodge
> Sent: Monday, June 01, 2009 9:59 AM
> To: Scott Baillie;
Bert Wijnen (IETF)
> Cc: adslmib at ietf.org
> Subject: Re:
[Adslmib] RFC3728 (1788) (RFC Errata System)
>
> Hi,
>
> So I believe there is now consensus that:
>
> The UNITS clause should be changed to "0.25dB" (instead
of
> "0.25dBm").
>
> No other changes are needed to any
of the other clauses.
>
>
>
> Are there any
objections to accepting this errata?
>
> Best Regards,
>
Menachem
>
>
>
> -----Original
Message-----
> From: adslmib-bounces at ietf.org
>
[mailto:adslmib-bounces at ietf.org] On Behalf Of Scott Baillie
> Sent:
Thursday, May 28, 2009 8:07 PM
> To: Bert Wijnen (IETF)
> Cc: adslmib at ietf.org
> Subject: Re:
[Adslmib] RFC3728 (1788) (RFC Errata System)
>
> Hi
All,
>
> I think the UNITS clause should be changed to
"0.25dB"
> and this is not an incompatible change.
>
>
The MIB object in question holds a noise margin value and is
>
expressed in dB. The MIB object does not represent a power
> level,
it represents a ratio of power levels.
> Because the MIB object
represents a ratio there is no need to
> mention power levels at all
in the UNITS clause or in the
> DESCRIPTION clause.
>
>
I have a few comments about some of the previous posts :
>
>
>Without an explicit or implicit reference level, decibel (dB) is
> >undefined as it represents a ratio. In our case (as with
the ITU
> >document), the reference level is explicitly specified
in the UNITS
> >clause. If it were not, it would be implied
by the context.
> That is,
> >we are measuring
changes in audio levels in telephone
> circuits. This
>
>has a VERY long and established history (the bel is named after
>
>Alexander Graham Bell, a decibel being one tenth of a bel).
>
> I understand that it is convenient to use dBm when expressing
> power levels in telephone circuits but the MIB object in
>
question is a noise margin, not a power level.
>
> >However,
if one felt forced, compelled, to be more specific, then,
>
>changing "dB" in the DESCRIPTION clause to "dBm" would be the more
> >accurate change.
>
> That change would be
completely incorrect.
>
> >Burt the reported proposal for
the fix was going to change
> Integer32 to
> >Gaug32, or so
I understood. That would be really bad I think.
>
> No need to
change the SYNTAX clause.
>
> Regards,
>
>
Scott.
>
> On Thu, 2009-05-28 at 00:01 +0200, Bert Wijnen
(IETF) wrote:
> > I can possibly live with updatinmg the
description clause.
> > Burt the reported proposal for the fix was
going to change
> Integer32
> > to Gaug32, or so I
understood. That would be really bad I think.
> >
>
> If the SYNTAXes and the value-ranges) all stay the same,
> then
I guess
> > that formally it would still be a semantic change, but
it
> is a matter
> > of wording change that I could
probably accept if the WG really has
> > consensus on
this.
> >
> > Bert
>
> ----- Original Message
-----
> > From:
Randy Presuhn
> >
To: adslmib at ietf.org
>
> Sent: Wednesday, May
27, 2009 8:36 PM
>
> Subject: Re: [Adslmib]
RFC3728 (1788) (RFC Errata System)
>
>
>
>
>
> Hi -
>
>
>
> > From: "Ray, Robert
E. (MSFC-NNM05AB50C)"
>
> <robert.e.ray at nasa.gov>
>
> > To: "Menachem
Dodge" <Menachem.Dodge at ecitele.com>;
>
> "Romascanu, Dan (Dan)"
<dromasca at avaya.com>;
>
> <adslmib at ietf.org>
>
> > Cc: <smadar_t at rad.com>
>
> > Sent: Wednesday,
May 27, 2009 10:50 AM
>
> > Subject: Re:
[Adslmib] RFC3728 (1788) (RFC Errata System)
>
> ...
>
> > Because of this, I
disagree completely with the
> Bert and Dan
>
> on this because
>
> > I don't think the
semantics are changed at all.
> I think the
>
> context, and
hence
> > > the
reference level, is completely stated. We are, after
>
> all, dealing
with
> > >
telephone wires.
>
>
>
> Agreed.
>
>
>
> > However, if one
felt forced, compelled, to be
> more specific,
>
> then, changing
>
> > "dB" in the
DESCRIPTION clause to "dBm" would be the more
>
> accurate
change.
> >
...
> >
>
> Agreed. It's a
case of the notation used in the DESCRIPTION
>
> clause
>
> being well-understood
within the specialist community, but
>
> being
>
> potentially ambiguous
outside of that community. If the
>
> change
>
> is deemed necessary,
it's nothing more than a clarification.
>
>
>
> Randy
>
>
>
>
_______________________________________________
>
> Adslmib mailing
list
> > Adslmib at ietf.org
>
> https://www.ietf.org/mailman/listinfo/adslmib
>
>
>
>
>
>
>
>
>
______________________________________________________________
>
>
>
>
>
> No virus found in this
incoming message.
>
> Checked by AVG - www.avg.com
>
> Version: 8.5.339 /
Virus Database: 270.12.42/2137 - Release
>
> Date: 05/27/09
07:50:00
> >
_______________________________________________
> > 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
>
_______________________________________________
> 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
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus
Database: 270.12.49/2149 - Release Date: 06/01/09
17:55:00
|