From owner-frnetmib@sunroof.eng.sun.com Mon Apr 3 10:44:18 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18036; Mon, 3 Apr 2000 10:44:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11904; Mon, 3 Apr 2000 08:40:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA02802; Mon, 3 Apr 2000 07:39:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e33Edbr25471 for frnetmib-dist; Mon, 3 Apr 2000 07:39:37 -0700 (PDT) Message-ID: <21FECF4891C9D311859D00508B8BB564230C@EXRAD1> From: Orly Nicklass To: frnetmib@sunroof.eng.sun.com Subject: RE: (FRNETMIB) minor corrections for mfrmib Date: Mon, 3 Apr 2000 16:21:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" 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/ ken, following Adelaide minutes, below are the two issues need to be fixed in the draft- 01: 1-section 2.3.5 " The ifStackTable is then used to show the relationships between the various interfaces. HigherLayer | LowerLayer ------------+----------- 0 | 1 1 | 2 2 | 3 2 | 4 3 | 5 3 | 6 4 | 0 5 | 0 6 | 0 7 | 0 " the table should be mapped correctly to reflect the figure above it, for example: HigherLayer | LowerLayer ------------+----------- 0 | 1 1 | 2 1 | 3 2 | 4 2 | 5 3 | 6 3 | 7 4 | 0 5 | 0 6 | 0 7 | 0 2-All places where bundleIfIndexMappingIndex is used, its type should be Integer32 and not InterfaceIndex as listed. Orly 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 Apr 7 15:29:18 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16249; Fri, 7 Apr 2000 15:29:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02618; Fri, 7 Apr 2000 13:28:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA17953; Fri, 7 Apr 2000 12:27:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e37JRHG29521 for frnetmib-dist; Fri, 7 Apr 2000 12:27:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e37JR8N29514 for ; Fri, 7 Apr 2000 12:27:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA17849 for ; Fri, 7 Apr 2000 12:27:07 -0700 (PDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05454 for ; Fri, 7 Apr 2000 12:27:06 -0700 (PDT) Received: from amalis ([152.148.173.102]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id PAA08465; Fri, 7 Apr 2000 15:27:02 -0400 (EDT) Message-Id: <4.2.2.20000407151948.026b7910@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 07 Apr 2000 15:20:39 -0400 To: frnetmib@sunroof.eng.sun.com, minutes@ietf.org From: "Andrew G. Malis" Subject: (FRNETMIB) Final minutes, frnetmib WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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/ Frame Relay Service MIB WG (frnetmib) Tuesday, March 28, 1300-1515 ============================ Chair: Andy Malis Minutes by Andy Malis 1. Administrivia, current documents status Andy presented the agenda and the current status of the documents. The only active WG document that was not already on the agenda was draft-ietf-frnetmib-atmiwf-05.txt, which is waiting for the Frame Relay Service MIB to complete due to cross-references - otherwise, it is ready to be published as an RFC. 2. Rob Steinberger and Orly Nicklass, draft-ietf-frnetmib-frmrelay-service-00.txt, Definitions of Managed Objects for Frame Relay Service Level Definitions See: http://www.frforum.com/5000/Approved/FRF.13/frf13.pdf http://search.ietf.org/internet-drafts/draft-ietf-frnetmib-frmrelay-serv http://search.ietf.org/internet-drafts/draft-ietf-frnetmib-frmrelay-service- 00.txt Rob presented the open issues from the last meeting. To address them, the document was renamed, he detailed the delay data from the sample table, got an IANA experimental ID (104), and added a capabilities object to identify which objects can be written. He also cleaned up some typos, fixed a problem in the nroff file, and some other minor changes, such as a revisions section to the MODULE, and added working group info to the contact list. The current open issues are: - typo in section 2.7.1: "dive" should be "divide" - SmplIndex should be SmplControlIndex for consistent naming - some objects have Data in their name twice to match the terminology in FRF.13. We could change it, but it wouldn't match FRF.13. We decided to not change it. Rob asked for WG last call for Proposed Standard. Ken Rehbehn felt that it should be experimental rather than PS, due to other ongoing work on service tracking MIBs. He said that it would be premature at this time to make it a Proposed Standard, until the IETF has a more mature service tracking framework. Thomas Narten said that it could be experimental for now, and it wouldn't be a big deal to change it to PS later on down the line. Peter Bodeit said that having it PS would help network operators, since it would be easier to get the functionality from vendors. It was also noted that there is currently no WG home for the service tracking MIB work. The WG consensus was to go for PS and revisit the issue when it comes time to advance the MIB to Draft Standard, to see if it needs updating based upon activities elsewhere in the IETF. Thomas gave advice on how to get an assignment in the MIB II branch (you make it clear in the MIB text that the assignment is required). 3. Prayson Pate, Bob Lynch, and Ken Rehbehn, draft-ietf-frnetmib-mfrmib-01.txt, Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function See: http://www.frforum.com/5000/Approved/FRF.16/frf16.pdf http://search.ietf.org/internet-drafts/draft-ietf-frnetmib-mfrmib-00.txt Version -01, the current version, was sent out on 3/17. The authors would like to go to next week's FRF meeting, collect any comments there, and then ask for last call. Changes from last time were: - minor formatting fixes - added ranges, REFERENCE, and UNITs where needed - returned a deleted object, the number of links in a bundle - clarified dependencies of the creation operation. There is no more functionality that should be added. It's had about three spins for review. Orly had some comments and questions on the MIB that she will send to the email list. It will go for last call following the FRF meeting and the resolution of Orly's comments. 4. Ken Rehbehn, recent updates to draft-ietf-frnetmib-frs-mib-10.txt, Definitions of Managed Objects for Frame Relay Service See: http://search.ietf.org/internet-drafts/draft-ietf-frnetmib-frs-mib-10.txt This MIB completed WG last call on 11/30, the IESG last call issued 12/8, Erik Nordmark's comments came on 12/30, Dave Perkin's comments came on 1/5, and a new revision was issued on 3/8. The minor changes from -09 were: many editorial modifications, completeness of REFERENCES, size ranges, move comments into DESCRIPTION clauses, and combined the lists of changes since RFC 1604 into a single complete list. More significant changes: removed the "stack" picture, which was replaced by more explicit text; removed the frLportVCSigPointerAdmin object; changed the notification OBJECT IDENTIFIER to avoid conflict with the obsolete trap; and reorganized the compliance groups. Ken gave a comprehensive description of the changes in the compliance groups. Andy discussed the fact that since new requirements have been added to the compliance groups, the FR service MIB will most probably have to recycled at Proposed rather than advanced to Draft. This is mostly a result of the new frPVCConnectStatusNotif NOTIFICATION. There is one last issue that needs resolution: frLportFragSize Integer32 (0..8184) will be changed to have a maximum size of 4096 to make it consistent with other MIBs. Ken's question: should he spin a new draft with these changes, and should there be second WG last call? We felt a second WG last call was not necessary. Ken is going to spin a version -11 to have a clean text for the IESG and the RFC Editor. 5. Open discussion With no further discussion, we adjourned. ________________________________________________________________________ Andrew G. Malis amalis@lucent.com phone:978 952-7414 fax:978 392-2074 Lucent Technologies 1 Robbins Road Westford, MA 01886 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 Apr 10 07:36:54 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05792; Mon, 10 Apr 2000 07:36:54 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA28425; Mon, 10 Apr 2000 05:34:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA19205; Mon, 10 Apr 2000 04:33:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3ABXXd00476 for frnetmib-dist; Mon, 10 Apr 2000 04:33:33 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3ABXM700469 for ; Mon, 10 Apr 2000 04:33:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA19171 for ; Mon, 10 Apr 2000 04:33:20 -0700 (PDT) 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 FAA28116 for ; Mon, 10 Apr 2000 05:33:19 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05355; Mon, 10 Apr 2000 07:33:17 -0400 (EDT) Message-Id: <200004101133.HAA05355@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: frnetmib@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (FRNETMIB) I-D ACTION:draft-ietf-frnetmib-frs-mib-11.txt Date: Mon, 10 Apr 2000 07:33:17 -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/ --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Frame Relay Service MIB Working Group of the IETF. Title : Definitions of Managed Objects for Frame Relay Service Author(s) : K. Rehbehn, D. Fowler Filename : draft-ietf-frnetmib-frs-mib-11.txt Pages : 89 Date : 05-Apr-00 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the frame relay service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-frnetmib-frs-mib-11.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-frnetmib-frs-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-frnetmib-frs-mib-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000406142508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-frnetmib-frs-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-frnetmib-frs-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000406142508.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 Apr 13 06:54:23 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26351; Thu, 13 Apr 2000 06:54:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA19334; Thu, 13 Apr 2000 04:53:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA01784; Thu, 13 Apr 2000 03:53:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3DAqrF03495 for frnetmib-dist; Thu, 13 Apr 2000 03:52:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3DAqk703488 for ; Thu, 13 Apr 2000 03:52:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA01773 for ; Thu, 13 Apr 2000 03:52:44 -0700 (PDT) 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 EAA19038 for ; Thu, 13 Apr 2000 04:52:44 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26196; Thu, 13 Apr 2000 06:52:43 -0400 (EDT) Message-Id: <200004131052.GAA26196@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: frnetmib@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (FRNETMIB) I-D ACTION:draft-ietf-frnetmib-mfrmib-02.txt Date: Thu, 13 Apr 2000 06:52:43 -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/ --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Frame Relay Service MIB Working Group of the IETF. Title : Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function Author(s) : P. Pate, B. Lynch, K. Rehbehn Filename : draft-ietf-frnetmib-mfrmib-02.txt Pages : 38 Date : 12-Apr-00 This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. This MIB also include conformance and notification information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-frnetmib-mfrmib-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-frnetmib-mfrmib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-frnetmib-mfrmib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000412124721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-frnetmib-mfrmib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-frnetmib-mfrmib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000412124721.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 Wed Apr 19 11:19:30 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07986; Wed, 19 Apr 2000 11:19:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11661; Wed, 19 Apr 2000 09:17:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA23685; Wed, 19 Apr 2000 08:16:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3JFFwv07494 for frnetmib-dist; Wed, 19 Apr 2000 08:15:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3JFFo707487 for ; Wed, 19 Apr 2000 08:15:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA23612; Wed, 19 Apr 2000 08:15:50 -0700 (PDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10895; Wed, 19 Apr 2000 09:15:49 -0600 (MDT) Received: from malisa2 ([152.148.90.98]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id LAA08438; Wed, 19 Apr 2000 11:15:47 -0400 (EDT) Message-Id: <4.2.2.20000419110806.024b1570@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 19 Apr 2000 11:15:44 -0400 To: frnetmib@sunroof.eng.sun.com, Thomas Narten , Erik Nordmark , scoya@ietf.org From: "Andrew G. Malis" Subject: (FRNETMIB) End of WG last call on draft-ietf-frnetmib-frmrelay-service-00.txt Cc: rsteinberger@paradyne.com, amalis@lucent.com In-Reply-To: <4.2.2.20000329180557.0277e1a0@alpo.casc.com> References: <38E28422.EE0CA013@eng.paradyne.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 ends WG last call on draft-ietf-frnetmib-frmrelay-service-00.txt, with no comments received. This is being forwarded to the IESG to be published as a Proposed Standard RFC. Cheers, Andy ------- At 06:16 PM 3/29/00 -0500, Andrew G. Malis wrote: >This begins WG last call on draft-ietf-frnetmib-frmrelay-service-00.txt, >to conclude 4/19. I'm giving it three weeks due to us still being at the >IETF, next week's Frame Relay Forum meeting, and the Frame Relay 2000 >event in Berlin the week after. As always, comments to the list. > >Thanks, >Andy ________________________________________________________________________ Andrew G. Malis amalis@lucent.com phone:978 952-7414 fax:978 392-2074 Lucent Technologies 1 Robbins Road Westford, MA 01886 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 Wed Apr 19 16:35:11 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14031; Wed, 19 Apr 2000 16:35:11 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10452; Wed, 19 Apr 2000 14:28:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA15316; Wed, 19 Apr 2000 13:28:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3JKS6407773 for frnetmib-dist; Wed, 19 Apr 2000 13:28:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3JKS0707766 for ; Wed, 19 Apr 2000 13:28:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA06327 for ; Wed, 19 Apr 2000 13:28:00 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA10021 for ; Wed, 19 Apr 2000 14:27:57 -0600 (MDT) Received: from shemp by mail.visualnetworks.com via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 19 Apr 2000 20:32:59 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id <2ZF03L01>; Wed, 19 Apr 2000 16:27:47 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8B66@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Cc: Thomas Narten , Erik Nordmark , "Andrew Malis (E-mail)" Subject: (FRNETMIB) Comments - WG last call on draft-ietf-frnetmib-frmrelay-service-0 0.txt Date: Wed, 19 Apr 2000 16:27:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" 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/ Well - I thought I had till today to get my comments in for WG Call for the FR Service MIB. Too much time out of the office to get a more timely response. Here are my comments anyway (it is still April 19)! The Frame Relay Service MIB is not ready to complete WG Last Call. The current draft lacks sufficient detail to enable interoperable implementation of service monitoring for both half-duplex flows over a DLCI. In addition, the current MIB structure needs less complexity. Merging the sample tables and providing a cleaner circuit management model will simplify the MIB and enable interoperability. My biggest beef is that this MIB is outside a generic policy/service management tracking framework that covers multiple aspects of the IETF-specified technology. This MIB should not be on a standards track. Standards Track status should be restricted to a MIB that fits into the evolving framework being produced by the Policy Working Group. This is the wrong time to declare a particular approach to be a "standard". I will continue to urge the working group to keep this as a "Experimental" MIB. I am distressed at the silence on this mail list. The silence indicates a great deal of apathy towards this particular attempt to produce a frame relay service MIB. That alone should give the IESG pause. If we elect to charge ahead, then a lot more work is needed to get this MIB into good shape. See my specific comments below for elaboration. Ken =================================================================== Specific comments follow: 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 2) The frsldPvcDataTable is a table of free-running counters. This means that the time period for the min, max, and average variables in the frsldPvcDataTable would be infinite, making these values meaningless. What's the point? 3) Having separate data and availability history tables does not make sense. A single table is used for free running counters that populate the two separate tables. Likewise, make the MIB simpler by having a single sample table that includes both data and availability. Do users really have a need to do independent history collections of availability and DDR? Would someone, for example, want fifty samples at 15 minute intervals for availability but want only 25 samples for DDR? 4) Provide index mechanisms to support the modeling of a circuit as two half-duplex flows so that delivery success can be reported for the east-to-west direction as well as the west-to-east direction. 5) Add a "theory of operations" section to the introductory sections so that the reader can understand how to setup, tear down, and read the service sample sessions. The theory should describe the operation for each of the permutations of data collection ("cooked" and "raw" - my terms, the current text uses an odd set of collection nomenclature). 6) Why is the collection location distinction between source/destination/intermediate so important? How does the fact that the collection location is "source" versus "destination" versus "intermediate" change how the MIB is used or interpreted? The actions seem the same and each unit has to use implementation-specific mechanisms to pull together the data from the two endpoints. These should all be combined into a single value called "cooked" - because they all share the characteristic that all required data has been collected, correlated, and calculated. This is in contrast the "distributed" model where only information from one end is available. The distributed distinction should be divided into "raw source" and "raw destination". This provides the management system with clear indication that the data needs to be combined with another sample set. 7) the second paragraph of Section 2.6, Distributed is confusing. What does it mean to act for separate source-destination pairs? What does this have to do with the concept of not having access to both source and destination sets of data? 8) Different collection location types are allowed for delay measurement and delivery measurement on the SAME sample - why? This just adds more complexity. 9) Explicitly describe how an agent should respond if access is attempted to an object that is not supported by the particular implementation. 10) Make sure all comments are moved into object DESCRIPTION text. Especially for enumerations. 11) The frssldPvcDataOffered objects will wrap too quickly for high speed frame relay interfaces. Use a high-capacity count. 12) The indexing of the CtrlTable and the frsldPvcCtrlSrcRP and frsldPvcCtrlDstRP objects would imply that a single device cannot do measurements between multiple reference points for the same PVC. For example, you couldn't measure end to end and end to NNI. Is this true? --------------------------------------------------------------- Ken Rehbehn Phone: +1-301-296-2325 Visual Networks Fax: +1-301-296-2302 2092 Gaither Rd EMail: krehbehn@visualnetworks.com Rockville, MD 20850 http://www.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 Wed Apr 19 17:48:53 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14877; Wed, 19 Apr 2000 17:48:52 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01773; Wed, 19 Apr 2000 15:42:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA07737; Wed, 19 Apr 2000 14:41:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3JLfJ407894 for frnetmib-dist; Wed, 19 Apr 2000 14:41:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3JLfB707887 for ; Wed, 19 Apr 2000 14:41:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA23715; Wed, 19 Apr 2000 14:41:03 -0700 (PDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01151; Wed, 19 Apr 2000 15:41:02 -0600 (MDT) Received: from malisa2 ([152.148.90.98]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id RAA04603; Wed, 19 Apr 2000 17:41:00 -0400 (EDT) Message-Id: <4.2.2.20000419171414.025c35d0@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 19 Apr 2000 17:36:58 -0400 To: "Rehbehn, Kenneth" From: "Andrew G. Malis" Subject: (FRNETMIB) Re: Comments - WG last call on draft-ietf-frnetmib-frmrelay-service-00.txt Cc: frnetmib@sunroof.eng.sun.com, Thomas Narten , Erik Nordmark , "Andrew Malis (E-mail)" , scoya@ietf.org In-Reply-To: <0F9AE864A5ECD011B3100060977F354A019E8B66@shemp.visualnetwo rks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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/ Tom and Erik, It looks like I was a bit hasty in pulling the trigger. I'm taking a short vacation on Thursday and Friday, so I pushed this up to the top of my todo list for today! Anyway, we will work on the list to resolve Ken's comments before we can submit this to the IESG, so there's a non-zero probability of a -01 appearing. Please put my email from this morning on hold for now. Ken, Thanks for your comments - especially since you did make the deadline! One thing I will point out for everyone's benefit is that we did discuss the standards track vs. experimental issue in Adelaide, and the rough consensus in the meeting (excluding you, of course) was for the standards track. For the benefit of the people (like me!) that aren't keeping up with the policy work in the IETF, if you could point to any specific drafts regarding their framework to help people see how this doesn't fit that model, that would be a huge help. I would also like to point out that RFC 2026 defines an experimental RFC as "part of some research or development effort", and is meant to be an archival record of the work and for the general information of the community. I really don't think that this MIB fits in with that category - we really are trying to produce a MIB that can be used in production networks. So we should examine the MIB in the context of whether it is ready for PS. If the consensus is that it is ready, then we're set. If the consensus is that it is not, THEN we have a choice - improve it so that it IS ready, or call it research and publish it as experimental. I much prefer the former to the latter. Just my 2 cents. Cheers, Andy -------- At 04:27 PM 4/19/00 -0400, Rehbehn, Kenneth wrote: >Well - I thought I had till today to get my comments in for WG Call for the >FR Service MIB. Too much time out of the office to get a more timely >response. Here are my comments anyway (it is still April 19)! > >The Frame Relay Service MIB is not ready to complete WG Last Call. The >current draft lacks sufficient detail to enable interoperable implementation >of service monitoring for both half-duplex flows over a DLCI. In addition, >the current MIB structure needs less complexity. Merging the sample tables >and providing a cleaner circuit management model will simplify the MIB and >enable interoperability. > >My biggest beef is that this MIB is outside a generic policy/service >management tracking framework that covers multiple aspects of the >IETF-specified technology. This MIB should not be on a standards track. >Standards Track status should be restricted to a MIB that fits into the >evolving framework being produced by the Policy Working Group. This is the >wrong time to declare a particular approach to be a "standard". I will >continue to urge the working group to keep this as a "Experimental" MIB. > >I am distressed at the silence on this mail list. The silence indicates a >great deal of apathy towards this particular attempt to produce a frame >relay service MIB. That alone should give the IESG pause. > >If we elect to charge ahead, then a lot more work is needed to get this MIB >into good shape. See my specific comments below for elaboration. > >Ken > > >=================================================================== > >Specific comments follow: > >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 > >2) The frsldPvcDataTable is a table of free-running counters. This means >that the time period for the min, max, and average variables in the >frsldPvcDataTable would be infinite, making these values meaningless. >What's the point? > >3) Having separate data and availability history tables does not make sense. >A single table is used for free running counters that populate the two >separate tables. Likewise, make the MIB simpler by having a single sample >table that includes both data and availability. Do users really have a need >to do independent history collections of availability and DDR? Would >someone, for example, want fifty samples at 15 minute intervals for >availability but want only 25 samples for DDR? > >4) Provide index mechanisms to support the modeling of a circuit as two >half-duplex flows so that delivery success can be reported for the >east-to-west direction as well as the west-to-east direction. > >5) Add a "theory of operations" section to the introductory sections so that >the reader can understand how to setup, tear down, and read the service >sample sessions. The theory should describe the operation for each of the >permutations of data collection ("cooked" and "raw" - my terms, the current >text uses an odd set of collection nomenclature). > >6) Why is the collection location distinction between >source/destination/intermediate so important? How does the fact that the >collection location is "source" versus "destination" versus "intermediate" >change how the MIB is used or interpreted? The actions seem the same and >each unit has to use implementation-specific mechanisms to pull together the >data from the two endpoints. These should all be combined into a single >value called "cooked" - because they all share the characteristic that all >required data has been collected, correlated, and calculated. This is in >contrast the "distributed" model where only information from one end is >available. The distributed distinction should be divided into "raw source" >and "raw destination". This provides the management system with clear >indication that the data needs to be combined with another sample set. > >7) the second paragraph of Section 2.6, Distributed is confusing. What does >it mean to act for separate source-destination pairs? What does this have to >do with the concept of not having access to both source and destination sets >of data? > >8) Different collection location types are allowed for delay measurement and >delivery measurement on the SAME sample - why? This just adds more >complexity. > >9) Explicitly describe how an agent should respond if access is attempted to >an object that is not supported by the particular implementation. > >10) Make sure all comments are moved into object DESCRIPTION text. >Especially for enumerations. > >11) The frssldPvcDataOffered objects will wrap too quickly for high speed >frame relay interfaces. Use a high-capacity count. > >12) The indexing of the CtrlTable and the frsldPvcCtrlSrcRP and >frsldPvcCtrlDstRP objects would imply that a single device cannot do >measurements between multiple reference points for the same PVC. For >example, you couldn't measure end to end and end to NNI. Is this true? > >--------------------------------------------------------------- >Ken Rehbehn Phone: +1-301-296-2325 >Visual Networks Fax: +1-301-296-2302 >2092 Gaither Rd EMail: krehbehn@visualnetworks.com >Rockville, MD 20850 http://www.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 Thu Apr 20 10:37:45 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11805; Thu, 20 Apr 2000 10:37:43 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21300; Thu, 20 Apr 2000 08:36:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA17356; Thu, 20 Apr 2000 07:36:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3KEZnZ08492 for frnetmib-dist; Thu, 20 Apr 2000 07:35:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3KEZh708485 for ; Thu, 20 Apr 2000 07:35:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA24839 for ; Thu, 20 Apr 2000 07:35:43 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA28447 for ; Thu, 20 Apr 2000 07:35:41 -0700 (PDT) Received: from shemp by mail.visualnetworks.com via smtpd (for venus.Sun.COM [192.9.25.5]) with SMTP; 20 Apr 2000 14:40:43 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id <2ZF03PDB>; Thu, 20 Apr 2000 10:35:40 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8B67@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: "'Andrew G. Malis'" Cc: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) RE: Comments - WG last call on draft-ietf-frnetmib-frmrelay-servi ce-00.txt Date: Thu, 20 Apr 2000 10:35:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" 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/ > Thanks for your comments - especially since you did make the > deadline! One > thing I will point out for everyone's benefit is that we did > discuss the > standards track vs. experimental issue in Adelaide, and the > rough consensus > in the meeting (excluding you, of course) was for the standards track. > > For the benefit of the people (like me!) that aren't keeping > up with the > policy work in the IETF, if you could point to any specific drafts > regarding their framework to help people see how this doesn't > fit that > model, that would be a huge help. RFC 2758, Definitions of Managed Objects for Service Level Agreements Performance Monitoring, provided some of the best discussion of this issue. Ed Ellesson made an oral presentation at the Policy WG meeting in Adeliade to outline the need for a comprehensive policy monitoring approach. The problem being solved is two-fold: what policies have reached the policy decision point and how are the policies working. This is the same class of problem being addressed by the frame relay service MIB. The issue extends beyond frame relay and should include other connection flows such as VPN security associations, MPLS LSPs, and ATM VCs. The IETF should produce a generic framework for service monitoring of connection flows. Each technology can then augment this framework for technology-specific elements. I don't argue that some variation of the proposed Frame Relay Service MIB should not be published. However, it is premature to stamp it with the imprimatur of IETF "standard". 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 Apr 21 16:04:14 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24839; Fri, 21 Apr 2000 16:04:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09670; Fri, 21 Apr 2000 14:00:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA22141; Fri, 21 Apr 2000 13:00:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3LJxmj09615 for frnetmib-dist; Fri, 21 Apr 2000 12:59:48 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3LJxg709608 for ; Fri, 21 Apr 2000 12:59:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA07807 for ; Fri, 21 Apr 2000 12:59:30 -0700 (PDT) Received: from satori.is.paradyne.com (services.paradyne.com [135.90.253.90]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08930 for ; Fri, 21 Apr 2000 13:59:23 -0600 (MDT) Received: from hermes.eng.paradyne.com ([135.26.1.14]) by satori.is.paradyne.com (Netscape Messaging Server 3.6) with ESMTP id AAA34BA; Fri, 21 Apr 2000 16:01:16 -0400 Received: from eng.paradyne.com (graysnapper.eng.paradyne.com [135.26.4.16]) by hermes.eng.paradyne.com (8.7.5/8.7.3) with ESMTP id PAA11568; Fri, 21 Apr 2000 15:59:02 -0400 (EDT) Message-ID: <3900B35B.39BDAB75@eng.paradyne.com> Date: Fri, 21 Apr 2000 16:00:27 -0400 From: Rob Steinberger Organization: Paradyne Corporation X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Rehbehn, Kenneth" , frnetmib@sunroof.eng.sun.com CC: Orly Nicklass Subject: (FRNETMIB) RE: FRNETMIB) Comments - WG last call on draft-ietf-frnetmib-frmrelay-service-0 0.txt 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 Ken, Thanks for clarifying your problems of this MIB. I will not address your opening comments in this message beyond agreeing that the lack of comments on the list is frustrating. However, this same comment can be said about ALL documents that are currently in or going to last call. We know there are already early implementations and have witnessed people at the IETF meetings from NSPs, device vendors and management software vendors state interest in this particular MIB. I will point out that posting the comments after the Last Call was announced to be closed is a bit difficult to deal with. None the less, it is in the interest of this group to resolve ALL issues and get this document to an acceptable state as quickly as possible. Thanks for the comments. I will address them in-line below. Rob Steinberger Paradyne Networks. "Rehbehn, Kenneth" wrote: > Specific comments follow: > > 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. > > 2) The frsldPvcDataTable is a table of free-running counters. This > means > that the time period for the min, max, and average variables in the > frsldPvcDataTable would be infinite, making these values > meaningless. > What's the point? The min, max and avg values in the data table were discussed in Washington. I pointed the same thing out there, and this correction was acceptable at the time. From the meeting minutes: Rob pointed out an error in the document on frsldPvcDataDelayMin/Max/Avg. The reference is to the free-running table and this should have relevance only to the free running world. This will be corrected. Further, I showed this change again in Adelaide. We can either alter the text to state how the object decay should be handled or add a variable to show the life span of the value. This would bring up implementation issues as to whether to use a sliding window or a polled window. I don't feel comfortable removing the values in that they are needed if the implementation chooses not to do any sampling. What would you prefer? > > 3) Having separate data and availability history tables does not > make sense. > A single table is used for free running counters that populate the > two > separate tables. Likewise, make the MIB simpler by having a single > sample > table that includes both data and availability. Do users really > have a need > to do independent history collections of availability and DDR? Would > > someone, for example, want fifty samples at 15 minute intervals for > availability but want only 25 samples for DDR? The data and availability were both in one table in the pre-draft state of this MIB. However, it was requested at that time that they be separated. The extra table allows more flexibility without adding much complication, so I did not disagree with the request. I can see users wanting day samples of Availability and fifteen minute samples of the other statistics. > > 4) Provide index mechanisms to support the modeling of a circuit as > two > half-duplex flows so that delivery success can be reported for the > east-to-west direction as well as the west-to-east direction. This MIB is described as working with two devices to get the information. The mechanism you describe is implementation specific and requires that a single device can be used to get the statistics for both ends of the PVC. However, if implementations exist that currently do this, it should be covered. This issue is handled in my solution to question 12. If we let the user index on reference points as well, we can add both directions of data by selecting the appropriate reference point. > > 5) Add a "theory of operations" section to the introductory sections > so that > the reader can understand how to setup, tear down, and read the > service > sample sessions. The theory should describe the operation for each > of the > permutations of data collection ("cooked" and "raw" - my terms, the > current > text uses an odd set of collection nomenclature). This section is a good idea, but it comes at the risk of being too implementation specific. It will need to carry the warnings and appropriate nomenclature (SHOULD, MAY, etc.). > > 6) Why is the collection location distinction between > source/destination/intermediate so important? How does the fact > that the > collection location is "source" versus "destination" versus > "intermediate" > change how the MIB is used or interpreted? The actions seem the > same and > each unit has to use implementation-specific mechanisms to pull > together the > data from the two endpoints. These should all be combined into a > single > value called "cooked" - because they all share the characteristic > that all > required data has been collected, correlated, and calculated. This > is in > contrast the "distributed" model where only information from one end > is > available. The distributed distinction should be divided into "raw > source" > and "raw destination". This provides the management system with > clear > indication that the data needs to be combined with another sample > set. Section 2.6 describes the importance of the collection locations. In that two devices are needed to get the information, the management software needs to know where to go to get the appropriate data. > > 7) the second paragraph of Section 2.6, Distributed is confusing. > What does > it mean to act for separate source-destination pairs? What does this > have to > do with the concept of not having access to both source and > destination sets > of data? Data is sent from a source node to a destination node which form a source-destination node pair. If the device collects data only about itself as it acts as both a source and a destination, the data will reflect this. The management software needs to know what the meaning of the statistics is so that it can use them appropriately. > 8) Different collection location types are allowed for delay > measurement and > delivery measurement on the SAME sample - why? This just adds more > complexity. Delay and data calculations can be calculated with different mechanisms. Forcing only one location limits the ability to capture all existing low level implementations. I know of implementations that can separate the collection locations. Restricting this would mean forcing an implementation on existing vendors, violate a goal of the document, and reduce the general use of the MIB. > > 9) Explicitly describe how an agent should respond if access is > attempted to > an object that is not supported by the particular implementation. No Such Name > > 10) Make sure all comments are moved into object DESCRIPTION text. > Especially for enumerations. Comments will be fixed. > > 11) The frssldPvcDataOffered objects will wrap too quickly for high > speed > frame relay interfaces. Use a high-capacity count. The same thing can be said about all current Frame Relay MIBs. Do we fix all of them now, let them all work the same, or just fix this one? > 12) The indexing of the CtrlTable and the frsldPvcCtrlSrcRP and > frsldPvcCtrlDstRP objects would imply that a single device cannot do > > measurements between multiple reference points for the same PVC. For > > example, you couldn't measure end to end and end to NNI. Is this > true? Good point. I can add the reference points as indices and this will be fixed along with the comment as well as issue 4. 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 Wed Apr 26 16:22:16 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04092; Wed, 26 Apr 2000 16:22:15 -0400 (EDT) From: owner-frnetmib@sunroof.eng.sun.com Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12489; Wed, 26 Apr 2000 14:08:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA13894; Wed, 26 Apr 2000 13:07:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3QK7N512394 for frnetmib-dist; Wed, 26 Apr 2000 13:07:23 -0700 (PDT) Date: Wed, 26 Apr 2000 13:07:23 -0700 (PDT) Message-Id: <200004262007.e3QK7N512394@sunroof.eng.sun.com> To: undisclosed-recipients:; Wed, 26 Apr 2000 11:59:56 -0700 X-Lotus-FromDomain: DLNOTES From: "Santa Dasu" To: frnetmib@sunroof.eng.sun.com Message-ID: <882568CD.0067F376.00@Athena.dl.com> Date: Wed, 26 Apr 2000 11:59:52 -0700 Subject: (FRNETMIB) feed back on fr-sla-mib Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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/ Hi I have seen the Frame Relay Service MIB recently. Please see my comments below. thanks santa ------------------------------------------------------------------------- The following are some questions and suggestions on the standard frame relay sla mib. Not having time stamp along with life time counters gives inaccuracies. If a certain counter is continuously updated by an agent. It is better to associate the counter with the time stamp of counter update. For example we want to calculate frames/sec using frame count, using the NMS timestamp gives arise to inaccuracies. Excluded outage time needs to be added. This mib does not seem to have excluded outages as mentioned in FRF.13 It is sufficient to have start or end time for sample period. Having both seems not necessary Delay measurements as mentioned in FRF.13 refer to milliseconds where as the MIB seems to mention them as micro seconds Delivery Ratio and Delay measurements need not be done at the same frequency. Hence separate periods must be provided. why availability and ddr/delay history samples are separated into 2 tables ? Some descriptions for sample statistics in MIB seem to be not easily comprehensible. For example "The change in the value of frsldPvcDataFrOfferedC during this sample interval. The value at the last sample will be subtracted from the current value, and the difference will be contained in this object." seems to actually mean " Framed offered within CIR to the network during the sample interval." 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 Apr 27 11:49:45 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02533; Thu, 27 Apr 2000 11:49:44 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10069; Thu, 27 Apr 2000 09:45:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA19865; Thu, 27 Apr 2000 08:45:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3RFj5813094 for frnetmib-dist; Thu, 27 Apr 2000 08:45:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3RFix713087 for ; Thu, 27 Apr 2000 08:44:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA06885 for ; Thu, 27 Apr 2000 08:44:59 -0700 (PDT) Received: from satori.is.paradyne.com (services.paradyne.com [135.90.253.90]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18239 for ; Thu, 27 Apr 2000 08:44:58 -0700 (PDT) Received: from hermes.eng.paradyne.com ([135.26.1.14]) by satori.is.paradyne.com (Netscape Messaging Server 3.6) with ESMTP id AAA3E6E for ; Thu, 27 Apr 2000 11:46:55 -0400 Received: from eng.paradyne.com (graysnapper.eng.paradyne.com [135.26.4.16]) by hermes.eng.paradyne.com (8.7.5/8.7.3) with ESMTP id LAA12121 for ; Thu, 27 Apr 2000 11:44:40 -0400 (EDT) Message-ID: <390860BD.AAC9E5DC@eng.paradyne.com> Date: Thu, 27 Apr 2000 11:46:05 -0400 From: Rob Steinberger Organization: Paradyne Corporation X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR/ATM Interworking MIB Comments 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 Developers here pointed out that frAtmIwfConnectionTable indexing is confusing. There are 6 indices to the table, but based on the description only one appears to be needed. The wording for frAtmIwfConnIndex is: "A unique index to identify this interworking connection" I realize that it is there to provide the point-to-multipoint connectivity, but you need to read section 3.4 to get that information out. Our developers were viewing each row in the table as an individual connection in that they display a single cross-connect. This problem may be alleviated with a modification to the DESCRIPTION clause. We need to tell the user that this connection index is a group of associated cross connections. We may also have to define better what makes a valid group. However, there is nothing in either the indexing scheme or the text to enforce that a "connection" is either point-to-point or point-to-multipoint. In fact, the connection index can simply be an index of a group of simple connections. All that is stated is that the MUST use the same connection description. It appears to be legal with this scheme to have every connection in the device use the exact same connection index as long as there is only one connection description used. This is not useful. I view frAtmIwfConnIndex as a group of connections with the same connection descriptor as well as a quicker search mechanism for relation of DLCIs and VCLs. We don't want to replace the connection index with the connection descriptor because an alternative purpose for the connection index is to speed up the relational search from the DLCI or VCL to the connection. This may be solved by making the connection descriptor the second index of the table. Alternatively, text can be added to the DESCRIPTION clauses of frAtmIwfConnectionDescriptor and frAtmIwfConnRowStatus to state the limitations. Further, the DESCRIPTION clause of frAtmIwfConnRowStatus is too limiting. There is no need to be operational to configure a cross connection. This limitation prevents the user from configuring the cross connection prior to making the network operational and is not usable in the field. Also, there is no need to check the admin status on deleting a cross connection in that deleting it should have no effect on the administrative status of the links. I think that all of the problems can be fixed by changes to only DESCRIPTION clauses. Rob Steinberger Paradyne Networks X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message.