Subject: (FRNETMIB) FR SLA MIB - Issue 1 - Implementation specific config variables

From: "Rehbehn, Kenneth" <[email-masked]>
Date: Tue, 2 May 2000 16:27:00 -0400

> > 1) Section 2.5 states that this document does not suggest or
> > recommend a
> > particular implementation.  The frsldPvcCtrlTable contains several
> > configuration variables that certainly seem to imply specific
> > implementations.  These configuration objects should be removed or
> > the
> > implementation details should be described.  For example:
> >
> >   frsldPvcCtrlPacketFreq
> >   frsldPvcCtrlDelayLoc
> >   frsldPvcCtrlDelayFrSize
> >   frsldPvcCtrlDelayType
> >   frsldPvcCtrlDelayTimeOut
> >
> 
> The delay objects you mention
> 
>        frsldPvcCtrlPacketFreq - Frequency of delay packet - if
>      supported
>        frsldPvcCtrlDelayLoc - Location of delay calculation
>        frsldPvcCtrlDelayFrSize - Size of delay packet - if supported
>        frsldPvcCtrlDelayType - One way or Round Trip Delay
>        frsldPvcCtrlDelayTimeOut - Time out for delay response - if
>      supported
> 
> are put in for the purpose of controlling delay measurement.  They are
> not specific to an implementation nor do they force the user to do
> delay measurement in a specific manner.  Delay is a definition as
> stated in FRF.13, and there needs to be some means of controlling and
> describing how this is measured.  Both control and description are
> important and are part of the basis of the MIB.  The location and type
> are important to adding meaning to how delay is measured, but I will
> address this in a reply to your comment 8.
> 
> Perhaps, we should move some of these variables into a separate groups
> in the compliance section to allow them to be skipped easier.
> 
> In your comment, you gave this list as a "for example."  This suggests
> that this is only a sampling of the objects you have problems with.
> We cannot fully address your issues until your issue list is complete.

I believe a generic SLA MIB (of which this MIB is variation) should focus on
tracking the results of the SLA - not control of the mechanism which
obtained those results.  In the case of delay, frame size and test frequency
may be elements of an SLA - but these are not elements that vary over time
and thus should not be included in this MIB.  

A different MIB should exist to drive delay measurements.  I anticipate a
future FRF.OAM MIB that will instrument such tests.

None of the objects above are valid for this MIB.  They need to be removed.

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.

---

From: "Santa Dasu" <[email-masked]>
Date: Wed, 3 May 2000 10:04:10 -0700

"
I believe a generic SLA MIB (of which this MIB is variation) should focus
on
tracking the results of the SLA - not control of the mechanism which
obtained those results.  In the case of delay, frame size and test
frequency
may be elements of an SLA - but these are not elements that vary over time
and thus should not be included in this MIB.

"

I do not agree with this. It is not necessary to restrict this mib only to
collected statistics.
Even if some configuration info does not change with time, it must remain
in the MIB.

"Rehbehn, Kenneth" <[email-masked]> on 05/02/2000 01:27:00 PM

To:   [email-masked]
cc:    (bcc: Santa Dasu/DLNOTES/US)
Subject:  (FRNETMIB) FR SLA MIB - Issue 1 - Implementation specific config
      variables

> We cannot fully address your issues until your issue list is complete.

I believe a generic SLA MIB (of which this MIB is variation) should focus
on
tracking the results of the SLA - not control of the mechanism which
obtained those results.  In the case of delay, frame size and test
frequency
may be elements of an SLA - but these are not elements that vary over time
and thus should not be included in this MIB.