Subject: RE: [Adslmib] six objects - redux

From: "Say, Sabit" <[email-masked]>
Date: Wed, 30 Apr 2003 13:13:44 -0700

Correct this and you are done:
vdslLineConfUpstreamTargetSlowBurstProtection OBJECT-TYPE

other comments for clarification:

1) Is it clear from the range and the variable type that the 0-1275 range is
in increments of 5 [microseconds]? 

2) 0 to 50 for % overhead makes sense.
Or if you do not want any range checking, you can define it as 0 to 63.75 in
0.25 increments.

3) For the burst protection configuration, target is more appropriate as you
now have it, similar to SNR margin. Notice that the main measure of SNR
margin is also a target. It may not be achieved, but the PMD layer will try
to obtain it. That means you may ask whatever you want but may not get it;
but if you do not get it, initialization will not fail. 

4) The reported parameters do not have upstream/downstream attached to them,
but I presume they can be reported for both. Is that correct?

-----Original Message-----
From: Bob Ray [mailto:[email-masked]]
Sent: Wednesday, April 30, 2003 3:17 PM
To: Randy Presuhn
Cc: adslmib mail list; Sabit Say; Moti Morgenstern; Rajesh Abbi
Subject: Re: [Adslmib] six objects - redux

Randy asks:

a) Given that the units are "%", shouldn't the range be constrained to
0..100?

It should have SOME constraint.  Ok to use 0..50 per Rajesh's
suggestion?

b) For the SNMP toolkits I'm familiar with, this would be a pain to
implement.  Given the semantics of the object, I think it would be
better to replace this line with
+  For interleaved channels, a value of zero shall be returned."

Ok.

c) Would a DEFVAL make sense here, or is the intent that this MUST be
supplied for the row to be activated?

I've put in DEFVALs of { 0 } for these.  I don't know of a way to
specify two default values - some value in 1..50 (or 1..1275) if 
appropriate and 0 if not.  So, I guess 0 works.  Complaints from the
crowd?

Suitably modified objects below.

Bob Ray 

--------------------------------------------------------

    vdslChanCurrFastFecOverhead  OBJECT-TYPE
        SYNTAX       Gauge32 (0..50)
        UNITS        "%"
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "Actual Forward Error Correction (FEC) redundancy 
            related overhead for a fast channel.  This parameter
            is not applicable to an interleaved (slow) channel.
            For interleaved channels, a value zero should be returned."
        ::= { vdslChanEntry 4 }

    vdslChanCurrSlowBurstProtection OBJECT-TYPE
        SYNTAX       Gauge32 (0..1275)
        UNITS        "microseconds"
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "Actual level of impulse noise (burst) protection 
            for an interleaved (slow) channel.  This parameter is 
            not applicable to fast channels.  For fast channels, 
            a value of zero should be returned."
        REFERENCE    "ITU-T G.997.1"          -- section 7.3.2.3
        ::= { vdslChanEntry 5 }

    vdslLineConfDownstreamTargetSlowBurstProtection OBJECT-TYPE
        SYNTAX       Unsigned32 (0..1275)
        UNITS        "microseconds"
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "Specifies the target level of impulse noise (burst) 
            protection for an interleaved (slow) channel."
        DEFVAL       { 0 }
        REFERENCE    "ITU-T G.997.1"          -- section 7.3.2.3
        ::= { vdslLineConfProfileEntry 41 }

    vdslLineConfUpstreamTargetBurstProtection OBJECT-TYPE
        SYNTAX       Unsigned32  (0..1275)
        UNITS        "microseconds"
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "Specifies the target level of impulse noise (burst) 
            protection for an interleaved (slow) channel."
        DEFVAL       { 0 }
        REFERENCE    "ITU-T G.997.1"          -- section 7.3.2.3
        ::= { vdslLineConfProfileEntry 42 }

    vdslLineConfDownstreamMaxFastFecOverhead OBJECT-TYPE
        SYNTAX       Unsigned32 (0..50)
        UNITS        "%"
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "This parameter provisions the maximum level of Forward
            Error Correction (FEC) redundancy related overhead to
            be maintained for the Fast channel."
        DEFVAL       { 0 }
        ::= { vdslLineConfProfileEntry 43 }

    vdslLineConfUpstreamMaxFastFecOverhead OBJECT-TYPE
        SYNTAX       Unsigned32 (0..50)
        UNITS        "%"
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "This parameter provisions the maximum level of Forward
            Error Correction (FEC) redundancy related overhead to
            be maintained for the Fast channel."
        DEFVAL       { 0 }
        ::= { vdslLineConfProfileEntry 44 }
_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 30 Apr 2003 13:46:27 -0700

Hi -

> From: "Say, Sabit" <[email-masked]>
> To: <[email-masked]>; "Randy Presuhn" <[email-masked]>
> Cc: "adslmib mail list" <[email-masked]>; "Sabit Say" <[email-masked]>; "Moti Morgenstern" <[email-masked]>; "Rajesh
Abbi" <[email-masked]>
> Sent: Wednesday, April 30, 2003 1:13 PM
> Subject: RE: [Adslmib] six objects - redux
...
> in increments of 5 [microseconds]?

Neither the DESCRIPTION nor the SYNTAX as currently written imposes
such a constraint.  Are you saying that a request to set this variable to
a value of 4 must be rejected?

> Or if you do not want any range checking, you can define it as 0 to 63.75 in

The current definition would not permit anything other than whole number
values.  If supporting 0.25 increments is important, then the UNITS should
reflect this so the values can be scaled appropriately.  Also, which is
the *real* architectural upper bound, 50 or 63.75?

...

Randy

---

From: Bob Ray <[email-masked]>
Date: 30 Apr 2003 15:56:17 -0500

> vdslLineConfUpstreamTargetSlowBurstProtection OBJECT-TYPE

Got it.  Thanks. Was also missing the word "of" in the
vdslChanCurrFastFecOverhead description.  That, or change
"a value of zero" to "the value zero" elsewhere.  But that
leads to a metaphysical trench, I think (is there one and
only one one?).   <- lame humor

> in increments of 5 [microseconds]? 

Nope.  In the object description its in increments of 1 microsecond.
If I change it to increments of 5 microseconds, the range is changed
to (0..255).  That is, UNITS gets changed to UNITS "5 microseconds".

> Or if you do not want any range checking, you can define it as 0 to 63.75 in

Similarly, would result in a range of (0..255) with UNITS of 0.25%. 

I suppose the (0..255) ranges are the more accurate translations of 
the underlying mechanisms.  Rajesh will argue about anything greater
than 50%.

> but I presume they can be reported for both. Is that correct?

The vdslChanCurrXXXX objects are for each ifIndex and vdslLineEntity
(Vtuc, Vtur).  As fast and interleave channels will each have an
ifEntry, and as each end of the line (Vtuc, Vtur) will have an
entry in the vdslChanTable, then, yes, it is reported for Upstream
(Vtur -> Vtuc) and Downstream (Vtuc -> Vtur).  Perhaps better object
names:

    vdslChanTxOverhead          (NOTE: "Tx")
    vdslChanTxBurstProtection   (NOTE: "Tx")

this would indicate which channel and in which direction the objects
refer (when taken in the context of their ifIndex and vdslLineEntity).

Bob Ray

p.s.  I need a beer.

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 30 Apr 2003 17:18:44 -0400

Since the parmeter vaues do not reflect exact configuration - only Minimum/Maximum
and Target values, it does not make sense to put unnecessary constraints on the steps.
The units should be simple (normally used).  So I agree with Randy that we should simply
use % and microseconds as the units in incements of 1 (1% or 1 microsecond).

Enough from me.  Bob, go get a beer !

;-)

Rajesh