RE: Comments on new draft-ietf-atomib-rfc2558bis-01.txt (Fwd)

[Kaj Tesink <kaj@research.telcordia.com>]

At 11:11 AM 2/10/2003 -0500, Senthil Selvi wrote:

> Hi
>
> Quick Question regarding RFC2558 MIb.
>
> Is sonetSESthresholdSet is index based (port Number) or system based .
>
> I don't see an index passed in that MIB.
>
> Could you please explain me in detail

hi senthil,
you're right, there is no index; it is system based;
no change from rfc2558.

kaj

ps - the rationale for this object is in the preamble of the
spec:

Severely Errored Seconds
According to [T1M1.3][T1.231a][TR253][GR253][T1.231b]
at each layer, an Severely Errored Second (SES) is a
second with x or more CVs at that layer, or a second
during which at least one or more incoming defects at
that layer has occurred. The values of x in RFC 1595
[RFC1595] were based on [T1M1.3] and [TR253] (see Appendix B).
These values have subsequently been relaxed in [T1.231a]
[GR253][T1.231b]. In addition, according to G.826 [G.826]
SESs are measured as a percentage of errored blocks.
To deal with these sets of definitions this memo defines
an object sonetSESthresholdSet that determines the
correct interpretation of SES. For backward
compatibility, if this object is not implemented the
interpretation of Appendix B shall apply. Otherwise,
a more recent interpretation is suggested. An agent
is not required to support all sets of definitions.
Note that CV counts should be frozen during SESs.
Note that if a manager changes the value of this
object all SES statistics collected prior to this
change shall be invalidated.








> Thanks
> Senthil
>
>
>
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Saturday, February 08, 2003 3:03 AM
> To: Randy Bush
> Cc: Kaj Tesink; atommib@research.telcordia.com; iesg@ietf.org
> Subject: Re: Comments on new draft-ietf-atomib-rfc2558bis-01.txt (Fwd)
>
> On Fri, 7 Feb 2003, Randy Bush wrote:
>
> > > -  on (a) the question must be asked: does this
> > >    deprecate current objects. the answer is no, because
> > >    the specs that 2558bis is based on are widely implemented.
> >
> > sorry to butt in with pedantry (and sorry to shock friends that did
> > not expect me to be actually reading this:-), but you, possibly
> > unintentionally, slightly beg the question
> >
> >   are there, or might there be, correct implementations of the current
> >   specs which would be made non-conformant by 2558bis?
>
> If you mean "would any correct implementation of rfc 2558 be made
> non-conformant by 2558bis" then the answer is "no, it would not".
> The only non-editorial change that has been made was the addition of
> two more values for the enumerated INTEGER sonetPathCurrentWidth
> (this is one of the changes specifically allowed by the SMI).
> Adding these values will allow (but will not require) support for
> STS-192c/STM-64 and STS-768c/STM-256 rates.  The object in question
> has a MIN-ACCESS of read-only, and implementations need only return
> the values that they actually support.
>
> //cmh

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. In.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj @research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/