From owner-frnetmib@sunroof.eng.sun.com Mon Oct 1 17:08:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01096; Mon, 1 Oct 2001 17:08:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20204; Mon, 1 Oct 2001 15:03:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02477; Mon, 1 Oct 2001 14:02:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91L2nML003312 for ; Mon, 1 Oct 2001 14:02:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91L2mdV003311 for frnetmib-dist; Mon, 1 Oct 2001 14:02:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-frnetmib@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91L2iML003304 for ; Mon, 1 Oct 2001 14:02:44 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27041 for ; Mon, 1 Oct 2001 14:02:47 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01362 for ; Mon, 1 Oct 2001 14:02:46 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00995; Mon, 1 Oct 2001 17:02:42 -0400 (EDT) Message-Id: <200110012102.RAA00995@ietf.org> To: IETF-Announce: ; Cc: frnetmib@sunroof.eng.sun.com From: The IESG Subject: (FRNETMIB) Last Call: Definitions of Managed Objects for Frame Relay Service Level Definitions to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 01 Oct 2001 17:02:42 -0400 Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ The IESG has received a request from the Frame Relay Service MIB Working Group to consider Definitions of Managed Objects for Frame Relay Service Level Definitions as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by October 15, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-frnetmib-frmrelay-service-06.txt X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Thu Oct 11 11:08:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17781; Thu, 11 Oct 2001 11:08:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24522; Thu, 11 Oct 2001 08:05:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20175; Thu, 11 Oct 2001 08:01:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BF1MML006560 for ; Thu, 11 Oct 2001 08:01:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BF1LXD006559 for frnetmib-dist; Thu, 11 Oct 2001 08:01:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-frnetmib@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BF1JML006552 for ; Thu, 11 Oct 2001 08:01:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26775 for ; Thu, 11 Oct 2001 08:01:20 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.41]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA25919 for ; Thu, 11 Oct 2001 09:01:09 -0600 (MDT) Received: from no.name.available by mail.visualnetworks.com via smtpd (for patan.Sun.COM [192.18.98.43]) with SMTP; 11 Oct 2001 15:01:19 UT Received: by rock-mail.visualnetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Oct 2001 11:06:35 -0400 Message-ID: <2D46FF96461CD41195FE00D0B747435C02D0A1EA@rock-mail.visualnetworks.com> From: "Nisbet, Tom" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) Questions and comments on the FRSLD-MIB draft Date: Thu, 11 Oct 2001 11:06:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ I have several questions and comments on the FRSLD-MIB draft that was Published as draft-ietf-frnetmib-frmrelay-service-06.txt. IMPLEMENTATION SPECIFIC OBJECTS Section 3.5 states that no implementation is suggested in the document. However, the data and configuration tables contain objects that seem to be implementation dependent. Specifically, the frsldPvcCtrlEntry contains PacketFreq, DelayFrSize, and DelayTimeout objects. The data and sample data tables contain a MissedPolls object. The use of these is not adequately explained. REFERENCE MODEL EXAMPLES Several of the examples in section 3.6.2.1 seem to suggest configurations that cannot provide the data needed to do the FDR and DDR calculations. The second examples in 3.6.2.1.1 and 3.6.2.1.2 and 3.6.2.1.3 all place the Offered and Delivered counts for a single flow on different devices. To calculate DDR and FDR, the counts need to be synchronized. This is particularly evident when using the frsldPvcSampleTable. To calculate FDR and DDR, the two devices would need to collect their samples for exactly the same time periods. SAMPLE TABLE ORGANIZATION I don't understand the concept of discontinuities in the sample table that justify the use of start and stop times. Are the discontinuities caused by DLCIs transitioning in and out of an INVALID state? If so, how does this effect the sample index? Should it increment for each time interval, or only for intervals that contain sample data? MEASUREMENT OF TRAFFIC DELIVERED WITHIN CIR It is relatively easy to calculate delivered frames, but difficult to calculate it within a CIR or EIR range. If a device cannot differentiate, how should it populate the DeliveredE and DeliveredC objects? It might make sense to just use one counter and leave the other at zero, but that condition could also occur normally. Should we add a capabilities bit for this? There has not been much discussion of this draft on the list. How many people are implementing this? I'd be interested in other people's experience. Thanks, Tom Nisbet tnisbet@visualnetworks.com X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Fri Oct 12 15:10:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07308; Fri, 12 Oct 2001 15:10:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04097; Fri, 12 Oct 2001 13:08:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06001; Fri, 12 Oct 2001 12:08:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CJ8AML012964 for ; Fri, 12 Oct 2001 12:08:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CJ89XK012963 for frnetmib-dist; Fri, 12 Oct 2001 12:08:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-frnetmib@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CJ87ML012956 for ; Fri, 12 Oct 2001 12:08:07 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21586 for ; Fri, 12 Oct 2001 12:08:09 -0700 (PDT) Received: from equinox.tx.fnc.fujitsu.com (equinox.tx.fnc.fujitsu.com [167.254.254.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04271 for ; Fri, 12 Oct 2001 12:08:09 -0700 (PDT) Received: from miranda.tx.fnc.fujitsu.com (localhost [127.0.0.1]) by equinox.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id OAA15357 for ; Fri, 12 Oct 2001 14:07:53 -0500 (CDT) Received: from tdd1550.tx.fnc.fujitsu.com (tdd1550.tddeng00.fnts.com [167.254.248.27]) by miranda.tx.fnc.fujitsu.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05510 for ; Fri, 12 Oct 2001 14:07:50 -0500 (CDT) Received: from fnc.fujitsu.com (localhost [127.0.0.1]) by tdd1550.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id OAA08195 for ; Fri, 12 Oct 2001 14:07:50 -0500 (CDT) Message-ID: <3BC73F86.1F97F389@fnc.fujitsu.com> Date: Fri, 12 Oct 2001 14:07:50 -0500 From: Robert Steinberger X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: frnetmib@sunroof.eng.sun.com Subject: Re: (FRNETMIB) Questions and comments on the FRSLD-MIB draft References: <2D46FF96461CD41195FE00D0B747435C02D0A1EA@rock-mail.visualnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ Content-Transfer-Encoding: 7bit Tom This MIB was thoroughly discussed in the working group over the past 2 years, and I believe you were present at some of the meeting during which it was discussed. It has been through working group last call, and there were comments on the list both during last call and the general review process. All of the issues, some of which were very similar to yours, have been worked out. As you know, implementation reports come later in the process, and the number of companies actually implementing an internet draft is not really as relevant as those implementing a draft standard. See further comments in line below. Rob. "Nisbet, Tom" wrote: > I have several questions and comments on the FRSLD-MIB draft that was > Published as draft-ietf-frnetmib-frmrelay-service-06.txt. > > IMPLEMENTATION SPECIFIC OBJECTS > Section 3.5 states that no implementation is suggested in the document. > However, the data and configuration tables contain objects that seem > to be implementation dependent. Specifically, the frsldPvcCtrlEntry > contains PacketFreq, DelayFrSize, and DelayTimeout objects. The data > and sample data tables contain a MissedPolls object. The use of these > is not adequately explained. This issue was discussed previously in both e-mail on the list and during meetings. It was decided that these would be handled as optional items. See the capabilities section of the MIB. > > REFERENCE MODEL EXAMPLES > Several of the examples in section 3.6.2.1 seem to suggest configurations > that cannot provide the data needed to do the FDR and DDR calculations. > The second examples in 3.6.2.1.1 and 3.6.2.1.2 and 3.6.2.1.3 all place > the Offered and Delivered counts for a single flow on different devices. > To calculate DDR and FDR, the counts need to be synchronized. > > This is particularly evident when using the frsldPvcSampleTable. To > calculate FDR and DDR, the two devices would need to collect their > samples for exactly the same time periods. Synchronization mechanisms are not part of FRF.13. It is true that accuracy demands some synchronization. In fact, this was also discussed in the process. Some companies will simply provide better accuracy than others. > > > SAMPLE TABLE ORGANIZATION > I don't understand the concept of discontinuities in the sample table > that justify the use of start and stop times. Are the discontinuities > caused by DLCIs transitioning in and out of an INVALID state? If so, > how does this effect the sample index? Should it increment for each time > interval, or only for intervals that contain sample data? The sample index should increment as stated, "once for each new bucket in the table". The start and end times are recorded to allow for discontinuities. The discontinuities are caused by the fact that frsldSmplCtrlStatus follows the frsldPvcCtrlStatus in respect to activity. If frsldPvcCtrlStatus becomes notReady, no samples will be collected. > > > MEASUREMENT OF TRAFFIC DELIVERED WITHIN CIR > It is relatively easy to calculate delivered frames, but difficult to > calculate it within a CIR or EIR range. If a device cannot differentiate, > how should it populate the DeliveredE and DeliveredC objects? It might make > sense to just use one counter and leave the other at zero, but that > condition > could also occur normally. Should we add a capabilities bit for this? Perhaps in a future release of this MIB we could add items related to the OAM agreement, but this MIB concerns solely with in and out of CIR. It is not concerned with EIR. If an implementation is not capable of determining CIR status, it is not really compliant with those statistics. If the device cannot differentiate, neither of the statistics, DeliveredC or DeliveredE, are correct. Reporting a number in DeliveredC states that octets or frames were delivered within CIR. If you are reporting a number that is not correct, it is a problem. > > > There has not been much discussion of this draft on the list. How many > people are implementing this? I'd be interested in other people's > experience. See comments above. > > > Thanks, > Tom Nisbet > tnisbet@visualnetworks.com > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with > X-Info: 'unsubscribe frnetmib' in the body of the message. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Fri Oct 12 17:15:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09824; Fri, 12 Oct 2001 17:15:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29746; Fri, 12 Oct 2001 14:14:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19183; Fri, 12 Oct 2001 14:14:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CLDsML013742 for ; Fri, 12 Oct 2001 14:13:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CLDsOh013741 for frnetmib-dist; Fri, 12 Oct 2001 14:13:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-frnetmib@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CLDpML013734 for ; Fri, 12 Oct 2001 14:13:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20482 for ; Fri, 12 Oct 2001 14:13:51 -0700 (PDT) Received: from viva.vivacenet.com ([64.221.212.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20324 for ; Fri, 12 Oct 2001 15:14:48 -0600 (MDT) Received: from viva.vivacenet.com [10.2.0.5] by viva.vivacenet.com (SMTPD32-5.05) id ADBC7F70030; Fri, 12 Oct 2001 14:16:44 -0700 Received: from 192.168.168.12 by viva.vivacenet.com (InterScan E-Mail VirusWall NT); Fri, 12 Oct 2001 14:16:42 -0700 Message-Id: <5.1.0.14.2.20011012170945.035cbc20@viva> X-Sender: Andy.Malis@viva X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Oct 2001 17:13:05 -0400 To: "Nisbet, Tom" From: "Andrew G. Malis" Subject: Re: (FRNETMIB) Questions and comments on the FRSLD-MIB draft Cc: frnetmib@sunroof.eng.sun.com In-Reply-To: <2D46FF96461CD41195FE00D0B747435C02D0A1EA@rock-mail.visualn etworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="=====================_667707302==_.ALT" --=====================_667707302==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Tom, As Robert said, these issues have been previously discussed. I suggest you read the WG minutes in the IETF proceedings (http://www.ietf.org/proceedings/directory.html) and the email archive (ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/). Thanks, Andy ------- At 10/11/2001 11:06 AM -0400, Nisbet, Tom wrote: >I have several questions and comments on the FRSLD-MIB draft that was >Published as draft-ietf-frnetmib-frmrelay-service-06.txt. > > >IMPLEMENTATION SPECIFIC OBJECTS >Section 3.5 states that no implementation is suggested in the document. >However, the data and configuration tables contain objects that seem >to be implementation dependent. Specifically, the frsldPvcCtrlEntry >contains PacketFreq, DelayFrSize, and DelayTimeout objects. The data >and sample data tables contain a MissedPolls object. The use of these >is not adequately explained. > > >REFERENCE MODEL EXAMPLES >Several of the examples in section 3.6.2.1 seem to suggest configurations >that cannot provide the data needed to do the FDR and DDR calculations. >The second examples in 3.6.2.1.1 and 3.6.2.1.2 and 3.6.2.1.3 all place >the Offered and Delivered counts for a single flow on different devices. >To calculate DDR and FDR, the counts need to be synchronized. > >This is particularly evident when using the frsldPvcSampleTable. To >calculate FDR and DDR, the two devices would need to collect their >samples for exactly the same time periods. > >SAMPLE TABLE ORGANIZATION >I don't understand the concept of discontinuities in the sample table >that justify the use of start and stop times. Are the discontinuities >caused by DLCIs transitioning in and out of an INVALID state? If so, >how does this effect the sample index? Should it increment for each time >interval, or only for intervals that contain sample data? > > >MEASUREMENT OF TRAFFIC DELIVERED WITHIN CIR >It is relatively easy to calculate delivered frames, but difficult to >calculate it within a CIR or EIR range. If a device cannot differentiate, >how should it populate the DeliveredE and DeliveredC objects? It might make >sense to just use one counter and leave the other at zero, but that >condition >could also occur normally. Should we add a capabilities bit for this? > > >There has not been much discussion of this draft on the list. How many >people are implementing this? I'd be interested in other people's >experience. > >Thanks, >Tom Nisbet >tnisbet@visualnetworks.com >X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with >X-Info: 'unsubscribe frnetmib' in the body of the message. --=====================_667707302==_.ALT Content-Type: text/html; charset="us-ascii" Tom,

As Robert said, these issues have been previously discussed.  I suggest you read the WG minutes in the IETF proceedings (http://www.ietf.org/proceedings/directory.html) and the email archive (ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/).

Thanks,
Andy

-------

At 10/11/2001 11:06 AM -0400, Nisbet, Tom wrote:
I have several questions and comments on the FRSLD-MIB draft that was
Published as draft-ietf-frnetmib-frmrelay-service-06.txt.


IMPLEMENTATION SPECIFIC OBJECTS
Section 3.5 states that no implementation is suggested in the document.
However, the data and configuration tables contain objects that seem
to be implementation dependent.  Specifically, the frsldPvcCtrlEntry
contains PacketFreq, DelayFrSize, and DelayTimeout objects.  The data
and sample data tables contain a MissedPolls object.  The use of these
is not adequately explained.


REFERENCE MODEL EXAMPLES
Several of the examples in section 3.6.2.1 seem to suggest configurations
that cannot provide the data needed to do the FDR and DDR calculations.
The second examples in 3.6.2.1.1 and 3.6.2.1.2 and 3.6.2.1.3 all place
the Offered and Delivered counts for a single flow on different devices.
To calculate DDR and FDR, the counts need to be synchronized.

This is particularly evident when using the frsldPvcSampleTable.  To
calculate FDR and DDR, the two devices would need to collect their
samples for exactly the same time periods.

SAMPLE TABLE ORGANIZATION
I don't understand the concept of discontinuities in the sample table
that justify the use of start and stop times.  Are the discontinuities
caused by DLCIs transitioning in and out of an INVALID state?  If so,
how does this effect the sample index?  Should it increment for each time
interval, or only for intervals that contain sample data?


MEASUREMENT OF TRAFFIC DELIVERED WITHIN CIR
It is relatively easy to calculate delivered frames, but difficult to
calculate it within a CIR or EIR range.  If a device cannot differentiate,
how should it populate the DeliveredE and DeliveredC objects?  It might make
sense to just use one counter and leave the other at zero, but that
condition
could also occur normally.  Should we add a capabilities bit for this?


There has not been much discussion of this draft on the list.  How many
people are implementing this?  I'd be interested in other people's
experience.

Thanks,
Tom Nisbet
tnisbet@visualnetworks.com
X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with
X-Info: 'unsubscribe frnetmib' in the body of the message.
--=====================_667707302==_.ALT-- --------------InterScan_NT_MIME_Boundary-- X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Fri Oct 12 17:33:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10041; Fri, 12 Oct 2001 17:33:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07652; Fri, 12 Oct 2001 14:32:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22780; Fri, 12 Oct 2001 14:32:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CLW5ML013799 for ; Fri, 12 Oct 2001 14:32:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CLW5jh013798 for frnetmib-dist; Fri, 12 Oct 2001 14:32:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-frnetmib@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CLW3ML013791 for ; Fri, 12 Oct 2001 14:32:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07326 for ; Fri, 12 Oct 2001 14:32:04 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA28387 for ; Fri, 12 Oct 2001 15:33:00 -0600 (MDT) Received: from no.name.available by mail.visualnetworks.com via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 12 Oct 2001 21:32:00 UT Received: by rock-mail.visualnetworks.com with Internet Mail Service (5.5.2650.21) id <4WTLT5K8>; Fri, 12 Oct 2001 17:37:22 -0400 Message-ID: <2D46FF96461CD41195FE00D0B747435C02D0A1F8@rock-mail.visualnetworks.com> From: "Nisbet, Tom" To: "'Andrew G. Malis'" Cc: frnetmib@sunroof.eng.sun.com Subject: RE: (FRNETMIB) Questions and comments on the FRSLD-MIB draft Date: Fri, 12 Oct 2001 17:37:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15366.12300AB4" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15366.12300AB4 Content-Type: text/plain I have read the last two years of email archive and have seen some discussion of my first issue, but nothing on the others. I don't think I stated the problems clearly and will follow up with more details. In any case, I apologize for showing up late to the party. However, I do think that there are real issues here. Tom -----Original Message----- From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] Sent: Friday, October 12, 2001 5:13 PM To: Nisbet, Tom Cc: frnetmib@sunroof.eng.sun.com Subject: Re: (FRNETMIB) Questions and comments on the FRSLD-MIB draft Tom, As Robert said, these issues have been previously discussed. I suggest you read the WG minutes in the IETF proceedings (http://www.ietf.org/proceedings/directory.html ) and the email archive ( ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/). Thanks, Andy ------- At 10/11/2001 11:06 AM -0400, Nisbet, Tom wrote: I have several questions and comments on the FRSLD-MIB draft that was Published as draft-ietf-frnetmib-frmrelay-service-06.txt. IMPLEMENTATION SPECIFIC OBJECTS Section 3.5 states that no implementation is suggested in the document. However, the data and configuration tables contain objects that seem to be implementation dependent. Specifically, the frsldPvcCtrlEntry contains PacketFreq, DelayFrSize, and DelayTimeout objects. The data and sample data tables contain a MissedPolls object. The use of these is not adequately explained. REFERENCE MODEL EXAMPLES Several of the examples in section 3.6.2.1 seem to suggest configurations that cannot provide the data needed to do the FDR and DDR calculations. The second examples in 3.6.2.1.1 and 3.6.2.1.2 and 3.6.2.1.3 all place the Offered and Delivered counts for a single flow on different devices. To calculate DDR and FDR, the counts need to be synchronized. This is particularly evident when using the frsldPvcSampleTable. To calculate FDR and DDR, the two devices would need to collect their samples for exactly the same time periods. SAMPLE TABLE ORGANIZATION I don't understand the concept of discontinuities in the sample table that justify the use of start and stop times. Are the discontinuities caused by DLCIs transitioning in and out of an INVALID state? If so, how does this effect the sample index? Should it increment for each time interval, or only for intervals that contain sample data? MEASUREMENT OF TRAFFIC DELIVERED WITHIN CIR It is relatively easy to calculate delivered frames, but difficult to calculate it within a CIR or EIR range. If a device cannot differentiate, how should it populate the DeliveredE and DeliveredC objects? It might make sense to just use one counter and leave the other at zero, but that condition could also occur normally. Should we add a capabilities bit for this? There has not been much discussion of this draft on the list. How many people are implementing this? I'd be interested in other people's experience. Thanks, Tom Nisbet tnisbet@visualnetworks.com X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. ------_=_NextPart_001_01C15366.12300AB4 Content-Type: text/html Message
I have read the last two years of email archive and have seen some discussion of my first issue, but nothing on the others.  I don't think I stated the problems clearly and will follow up with more details.
 
In any case, I apologize for showing up late to the party.  However, I do think that there are real issues here.
 
Tom
-----Original Message-----
From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com]
Sent: Friday, October 12, 2001 5:13 PM
To: Nisbet, Tom
Cc: frnetmib@sunroof.eng.sun.com
Subject: Re: (FRNETMIB) Questions and comments on the FRSLD-MIB draft

Tom,

As Robert said, these issues have been previously discussed.  I suggest you read the WG minutes in the IETF proceedings (http://www.ietf.org/proceedings/directory.html) and the email archive (ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/).

Thanks,
Andy

-------

At 10/11/2001 11:06 AM -0400, Nisbet, Tom wrote:
I have several questions and comments on the FRSLD-MIB draft that was
Published as draft-ietf-frnetmib-frmrelay-service-06.txt.


IMPLEMENTATION SPECIFIC OBJECTS
Section 3.5 states that no implementation is suggested in the document.
However, the data and configuration tables contain objects that seem
to be implementation dependent.  Specifically, the frsldPvcCtrlEntry
contains PacketFreq, DelayFrSize, and DelayTimeout objects.  The data
and sample data tables contain a MissedPolls object.  The use of these
is not adequately explained.


REFERENCE MODEL EXAMPLES
Several of the examples in section 3.6.2.1 seem to suggest configurations
that cannot provide the data needed to do the FDR and DDR calculations.
The second examples in 3.6.2.1.1 and 3.6.2.1.2 and 3.6.2.1.3 all place
the Offered and Delivered counts for a single flow on different devices.
To calculate DDR and FDR, the counts need to be synchronized.

This is particularly evident when using the frsldPvcSampleTable.  To
calculate FDR and DDR, the two devices would need to collect their
samples for exactly the same time periods.

SAMPLE TABLE ORGANIZATION
I don't understand the concept of discontinuities in the sample table
that justify the use of start and stop times.  Are the discontinuities
caused by DLCIs transitioning in and out of an INVALID state?  If so,
how does this effect the sample index?  Should it increment for each time
interval, or only for intervals that contain sample data?


MEASUREMENT OF TRAFFIC DELIVERED WITHIN CIR
It is relatively easy to calculate delivered frames, but difficult to
calculate it within a CIR or EIR range.  If a device cannot differentiate,
how should it populate the DeliveredE and DeliveredC objects?  It might make
sense to just use one counter and leave the other at zero, but that
condition
could also occur normally.  Should we add a capabilities bit for this?


There has not been much discussion of this draft on the list.  How many
people are implementing this?  I'd be interested in other people's
experience.

Thanks,
Tom Nisbet
tnisbet@visualnetworks.com
X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with
X-Info: 'unsubscribe frnetmib' in the body of the message.
------_=_NextPart_001_01C15366.12300AB4-- X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Sat Oct 13 22:33:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10494; Sat, 13 Oct 2001 22:33:56 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA29586; Sat, 13 Oct 2001 19:32:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03540; Sat, 13 Oct 2001 19:32:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9E2WCML016320 for ; Sat, 13 Oct 2001 19:32:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9E2WCvp016319 for frnetmib-dist; Sat, 13 Oct 2001 19:32:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-frnetmib@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9E2WAML016312 for ; Sat, 13 Oct 2001 19:32:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA06431 for ; Sat, 13 Oct 2001 19:32:11 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.41]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA07862 for ; Sat, 13 Oct 2001 20:31:43 -0600 (MDT) Received: from no.name.available by mail.visualnetworks.com via smtpd (for patan.Sun.COM [192.18.98.43]) with SMTP; 14 Oct 2001 02:32:00 UT Received: by rock-mail.visualnetworks.com with Internet Mail Service (5.5.2650.21) id <4WTLT6KC>; Sat, 13 Oct 2001 22:37:22 -0400 Message-ID: <2D46FF96461CD41195FE00D0B747435C02D0A1FA@rock-mail.visualnetworks.com> From: "Nisbet, Tom" To: "'Robert Steinberger'" , frnetmib@sunroof.eng.sun.com Subject: RE: (FRNETMIB) Questions and comments on the FRSLD-MIB draft Date: Sat, 13 Oct 2001 22:37:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ Rob, I probably didn't state the issues clearly. I'll provide additional details below. Other than the first issue, I don't believe the others have been covered. Please see my comments inline. Tom Robert Steinberger wrote: > > Tom > > This MIB was thoroughly discussed in the working group over the past 2 > years, and I believe you were present at some of the meeting during > which it was discussed. It has been through working group last call, > and there were comments on the list both during last call and the > general review process. All of the issues, some of which were very > similar to yours, have been worked out. > > As you know, implementation reports come later in the process, and the > number of companies actually implementing an internet draft is not > really as relevant as those implementing a draft standard. > > See further comments in line below. > > Rob. > > "Nisbet, Tom" wrote: > > > I have several questions and comments on the FRSLD-MIB draft that was > > Published as draft-ietf-frnetmib-frmrelay-service-06.txt. > > > > IMPLEMENTATION SPECIFIC OBJECTS > > Section 3.5 states that no implementation is suggested in the document. > > However, the data and configuration tables contain objects that seem > > to be implementation dependent. Specifically, the frsldPvcCtrlEntry > > contains PacketFreq, DelayFrSize, and DelayTimeout objects. The data > > and sample data tables contain a MissedPolls object. The use of these > > > is not adequately explained. > > This issue was discussed previously in both e-mail on the list and > during meetings. It was decided that these would be handled as optional > items. See the capabilities section of the MIB. > Making the objects optional doesn't really solve the problem. If the objects can be implemented, then they should be described. We can't expect people to count missed polls if we don't state what a poll is or how one can be missed. The description of the frsldPvcCtrlDelayTimeout object is a bit unclear on this. For example, what does it mean for a delay frame to be updated? > > > > REFERENCE MODEL EXAMPLES > > Several of the examples in section 3.6.2.1 seem to suggest configurations > > that cannot provide the data needed to do the FDR and DDR calculations. > > The second examples in 3.6.2.1.1 and 3.6.2.1.2 and 3.6.2.1.3 all place > > the Offered and Delivered counts for a single flow on different devices. > > To calculate DDR and FDR, the counts need to be synchronized. > > > > This is particularly evident when using the frsldPvcSampleTable. To > > calculate FDR and DDR, the two devices would need to collect their > > samples for exactly the same time periods. > > Synchronization mechanisms are not part of FRF.13. It is true that > accuracy demands some synchronization. In fact, this was also > discussed in the process. Some companies will simply provide > better accuracy than others. > It isn't a question of accuracy. Some of the example configurations will not provide the data necessary to do the calculations. I'll put together a detailed example of this. > > > > > > SAMPLE TABLE ORGANIZATION > > I don't understand the concept of discontinuities in the sample table > > that justify the use of start and stop times. Are the discontinuities > > caused by DLCIs transitioning in and out of an INVALID state? If so, > > how does this effect the sample index? Should it increment for each time > > interval, or only for intervals that contain sample data? > > The sample index should increment as stated, "once for each new bucket > in the table". The start and end times are recorded to allow for > discontinuities. The discontinuities are caused by the fact that > frsldSmplCtrlStatus follows the frsldPvcCtrlStatus in respect to activity. > If frsldPvcCtrlStatus becomes notReady, no samples will be collected. > It is unclear to me what advantage this has over a simpler mechanism such as the RMON History Table or the DS1 MIB's Interval Table. I'll put together a more detailed set of questions that may clear this up. > > > > > > MEASUREMENT OF TRAFFIC DELIVERED WITHIN CIR > > It is relatively easy to calculate delivered frames, but difficult to > > calculate it within a CIR or EIR range. If a device cannot differentiate, > > how should it populate the DeliveredE and DeliveredC objects? It might make > > sense to just use one counter and leave the other at zero, but that > > condition > > could also occur normally. Should we add a capabilities bit for this? > > Perhaps in a future release of this MIB we could add items related to > the OAM agreement, but this MIB concerns solely with in and out of CIR. > It is not concerned with EIR. If an implementation is not capable of > determining CIR status, it is not really compliant with those statistics. > > If the device cannot differentiate, neither of the statistics, > DeliveredC or DeliveredE, are correct. Reporting a number in DeliveredC > states that octets or frames were delivered within CIR. If you are reporting > a number that is not correct, it is a problem. > This is exactly what led me to ask if anyone was currently implementing the MIB. At first glance, the statistics look to be very straightforward and easy to implement. However, I believe that it is not possible to non-intrusively measure delivered frames with respect to ingress CIR. This was discussed at some length in the FRF.13 working group. There seem to be three possibilities: A) It is easy and I'm the only one who hasn't figured it out yet. B) People are not as concerned as I am about either modifying customer traffic or putting a burdensome amount of additional measurement traffic on the link. C) Not many people are implementing this yet and there will be quite a few suprises when everyone finally attempts this. If the answer is A or B, then there is no problem. I suspect that this is not the case. > > > > > > There has not been much discussion of this draft on the list. How many > > people are implementing this? I'd be interested in other people's > > experience. > > See comments above. > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue Oct 16 08:24:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11678 for ; Tue, 16 Oct 2001 08:24:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10210; Tue, 16 Oct 2001 06:21:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13314; Tue, 16 Oct 2001 05:21:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GCLpOI001478 for ; Tue, 16 Oct 2001 05:21:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GCLpAg001477 for frnetmib-dist; Tue, 16 Oct 2001 05:21:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-frnetmib@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GCLmOI001470 for ; Tue, 16 Oct 2001 05:21:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20124 for ; Tue, 16 Oct 2001 05:21:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26800 for ; Tue, 16 Oct 2001 05:21:50 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11580; Tue, 16 Oct 2001 08:21:44 -0400 (EDT) Message-Id: <200110161221.IAA11580@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: frnetmib@sunroof.eng.sun.com From: The IESG Subject: (FRNETMIB) Protocol Action: Definitions of Managed Objects for Circuit to Interface Translation to Proposed Standard Date: Tue, 16 Oct 2001 08:21:44 -0400 Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ The IESG has approved the Internet-Draft 'Definitions of Managed Objects for Circuit to Interface Translation' as a Proposed Standard. This document is the product of the Frame Relay Service MIB Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This is a MIB that defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules. Working Group Summary There was consensus in the WG for advancing the document. Protocol Quality The document has been reviewed for the IESG by Erik Nordmark, Bert Wijnen and Michael MacFaden. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Mon Oct 29 11:52:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19500; Mon, 29 Oct 2001 11:52:13 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06101; Mon, 29 Oct 2001 08:51:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03963; Mon, 29 Oct 2001 08:48:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TGmqQO002878 for ; Mon, 29 Oct 2001 08:48:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9TGmq45002877 for frnetmib-dist; Mon, 29 Oct 2001 08:48:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-frnetmib@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TGmnQO002870 for ; Mon, 29 Oct 2001 08:48:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20915 for ; Mon, 29 Oct 2001 08:48:51 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19879 for ; Mon, 29 Oct 2001 10:12:43 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19404; Mon, 29 Oct 2001 11:48:43 -0500 (EST) Message-Id: <200110291648.LAA19404@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , frnetmib@sunroof.eng.sun.com From: The IESG Subject: (FRNETMIB) Protocol Action: Definitions of Managed Objects for Frame Relay Service Level Definitions to Proposed Standard Date: Mon, 29 Oct 2001 11:48:43 -0500 Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ The IESG has approved the Internet-Draft 'Definitions of Managed Objects for Frame Relay Service Level Definitions' as a Proposed Standard. This document is the product of the Frame Relay Service MIB Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document defines MIB objects for managing the Frame Relay Service Level Definitions. Working Group Summary There was consensus in the WG to advance this document. The document is the last document in the WGs deliverables. Protocol Quality The document for reviewed for the IESG by Michael MacFaden, Bert Wijnen, and Erik Nordmark. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message.