From owner-ipfc@standards.gadzoox.com Mon Jan 17 13:59:57 2000 Received: from standards.gadzoox.com ([216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05764 for ; Mon, 17 Jan 2000 13:59:52 -0500 (EST) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id KAA08757 for ipfc-list; Mon, 17 Jan 2000 10:44:41 -0800 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from Brocade.COM (asbestos.brocade.com [12.7.224.244]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id KAA08754 for ; Mon, 17 Jan 2000 10:44:38 -0800 Received: from brocade.com (isdn-khasin-2 [192.168.8.106]) by Brocade.COM (8.8.8+Sun/8.8.8) with ESMTP id KAA11433; Mon, 17 Jan 2000 10:49:07 -0800 (PST) Message-ID: <388363CA.FFF80BA2@brocade.com> Date: Mon, 17 Jan 2000 10:47:39 -0800 From: Kha Sin Teow X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: ipfc@standards.gadzoox.com CC: Juergen Schoenwaelder , Murali Rajagopal Subject: Re: review of References: <199912131547.QAA03156@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I got the comments from Juergen on the latest draft of Fabric Element MIB. He had 33 editorial comments, and 2 that are technical. I believe the editorial comments are straightforward to deal with and I would accept the changes. I would like to discuss the two technical comments. > 30. Is fcFxPortC1ConnTime really a Counter32? The description talks > about a cumulative time. A counter only counts events and is not a > type for measuring time intervals. > To the best of my recollection, this was defined to accumulate the number of bytes (including IDLEs and other primitive sequences) associated with the class 1 connection. since one could figure out the byte rate of the connection, one could therefore derive the cumulative time. In retrospect, this seems like an awkward way to keep the time. I propose to change this definition to count the cumulative time in units of milliseconds. > 35. You currently have a single compliance statement, which requires > to implement the config and the status group. It is surprising > that this compliance statement does not require the implementation > of the error group. I also suggest to add a second compliance > statement for those implementations that implement all MIB groups. > > Furthermore, you should check whether write access to read-write > objects is required to be conformant. (You can formally express in > the compliance statement that write access is not needed.) Not > sure this is relevant for this module since there are only a few > writable objects and they seem to be pretty easy to implement. > > Also, some of the tables may be conditionally mandatory. For > example, a device which does not support class 3 frames can not be > expected to implement the class 3 accounting table. In this case, > you probably have to break the OBJECT-GROUPs into smaller pieces. > > Below is a proposal to start from: > > -- compliance statements > fcFeMIBMininumCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The minimum compliance statement for SNMP entities > which implement the FIBRE-CHANNEL-FE-MIB." > MODULE -- this module > MANDATORY-GROUPS { fcFeConfigGroup, fcFeStatusGroup, fcFeErrorGroup } > ::= { fcFeMIBCompliances 1 } > > fcFeMIBFullCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The full compliance statement for SNMP entities > which implement the FIBRE-CHANNEL-FE-MIB." > MODULE -- this module > MANDATORY-GROUPS { fcFeConfigGroup, fcFeStatusGroup, fcFeErrorGroup > fcFeAccountingGroup, fcFeCapabilitiesGroup } > ::= { fcFeMIBCompliances 2 } > I tend to accept what Juergen suggested. However, the issue of supporting "write" access needs to be discussed. I believed the original intent was to make the "write" access optional. and that's what I'll define the conformance statement in the next revision. For your convenience, Jurgen's comments are attached below. Juergen Schoenwaelder wrote: > [I apologize for being so late with my comments.] > > Here is my review for . > There is still some minor work to be done before the MIB can proceed. > But the document looks in general pretty good now - it has improved > quite a bit. Let me know if there are any comments that are unclear. > > Bert, I assumed that the various fibre channel related MIBs will get > rooted directly under mib-2. Please correct me if this is not true. > > 1. The text in the 3rd paragraph on page 5 is pretty clear that > coming and leaving modules do not affect sysUpTime. The last > sentence in the 5th paragraph says that fcFeModuleLastChange > indicates when the last change took place. So I expect that > fcFeModuleLastChange functions as a discontinuity indicator > for all the counters. I think it would be nice to add a > sentence to make this explicit: > > : The object fcFeModuleLastChange acts as the discontinuity > : indicator for all counter objects in this MIB. > > 2. In section 2.1, you write ranges sometimes in () and sometimes > without (). (This is a minor editorial nit and not really > important.) > > 3. What is the "right" name for this MIB module? I understand that we > will have more MIB modules for IP over Fibre Channel and hence we > should carefully pick a naming scheme which can be adopted for > other IPFC MIBs as well. You currently use FCFABRIC-ELEMENT-MIB. > You use a very short prefix (FC) which only people familiar with > Fibre Channel work will be able to understand. Furthermore, you are > using complete words for the rest of the name. I think it would be > more useful to use a words at the beginning and to use a short > acronym on those parts that are Fibre Channel specific. So my > proposal would be FIBRE-CHANNEL-FE-MIB, which has the same length > as the current name but will be more readable by the average > person. Future Fibre Channel MIBs will then use module names like > FIBRE-CHANNEL-DEVICE-MIB or FIBRE-CHANNEL-DEV-MIB. > > 4. Do not import BITS (even if SMICng tells you to do so). > > 5. Please import mib-2 since the final version of the MIB will be > rooted under mib-2. > > 6. Make sure the LAST-UPDATED and REVISION dates are updated. > > 7. Change the DESCRIPTION clause of the REVISION to: > > : DESCRIPTION "Initial version, published as RFC XXXX." > > The RFC editor will fill in the RFC number when the document gets > published. > > 8. The current OID structure looks as follows (note that I changed > comformance to conformance): > > fcFabric > fcFe > fcFeMIBObjects > fcFeConfig > fcFeOp > fcFeError > fcFeAcct > fcFeCap > fcFeMIBConformance > > Here is how I think the structure should be: > > fcFeMIB > fcFeMIBObjects > fcFeConfig > fcFeStatus > fcFeError > fcFeAccounting > fcFeCapabilities > fcFeMIBConformance > > In other words, I propose to change the descriptor of the module > identity macro to fcFeMIB and to drop the fcFe node. I fixed the > spelling of "conformance" and I renamed fcFeOp to fcFeStatus and I > spelled out fcFeAcct and fcFeCap. For the OID value for the module > identity, please use { mib-2 XXXX }. The RFC editor will fill in > the right number. > > 9. Minor indentation problem in the defintion of FcNameId. > > 10. Missing "." in the DESCRIPTION of FcAddressId. > > 11. Use Integer32 instead of INTEGER in the following TCs: > FcRxDataFieldSize, FcBbCredit, FcphVersion, FcFeNxPortIndex > > (As a general rule: Use INTEGER only for enumerations.) > > 12. Please remove any ASN.1 comments which say that a group of objects > is mandatory or optional. Compliance statements are the official > way to express conformance levels. You can have multiple > compliance statements. (And in your case, you probably want to > have two of them - see below). Hence, an ASN.1 comment saying > something is mandatory or optional is problematic. > > 13. You should use SnmpAdminString instead of DisplayString in order > to allow for international character sets. SnmpAdminString is > defined in (and must be imported from) SNMP-FRAMEWORK-MIB. Also > remove the comment in the DESCRIPTION of fcFeModuleDescr that the > value should contain ASCII characters. (The statement was > redundant anyway since this is what DisplayString requires.) > > 14. Please change fcFabricName to fcFeFabricName and change > fcElementName to fcFeElementName. This ensures that you use the > fcFe and fcFx prefixes throughout the MIB without exceptions. > > 15. Why is the fcFxPortEntry indexed by > > INDEX { fcFxPortModuleIndex, fcFxPortIndex } > > and not by > > INDEX { fcFeModuleIndex, fcFxPortIndex } ? > > I do not see why the definition of fcFxPortModuleIndex is needed > at all. > > 16. Minor indentation inconsistency in the OID value assignement of > fcFxPortBbCredit. > > 17. Suggest to add UNITS "buffers" to fcFxPortBbCredit. > > 18. Suggest to add UNITS "bytes" to fcFxPortRxBufSize. > > 19. Suggest to add UNITS "milliseconds" to fcFxPortRatov and fcFxPortEdtov. > > 20. Suggest to add UNITS "milliseconds" to fcFxPortHoldTime. > > 21. Suggest to add UNITS "buffers" to fcFxPortBbCreditAvailable. > > 22. I think fcFxPortOperMode should be read-only instead of read-write. > > 23. As I wrote earlier, I think the "Operation group" should be named > "Status group" since this better reflects the information > contained in this group. This means that some ASN.1 comments must > be updated and that the fcFxOperTable should be changed into a > fcFxStatusTable. > > 24. Suggest to add UNITS "milliseconds" to fcFxPortPhysRttov. > > 25. Please change fcFxlogiTable to fcFxLoginTable, fcFxlogiEntry to > fcFxLoginEntry, FcFxlogiEntry to fcFxLoginEntry. > > 26. The DESCRIPTION of fxFxLoginTable says that it "contains, one > entry for each FxPort in the Fabric Element, serices parameters > established from the most recent Fabric Login, explicit or > implicit". Why has this table a different indexing structure from > the other tables that have one entry per FxPort? Why can't you > use INDEX { fcFeModuleIndex, fcFxPortIndex } ? > > 27. Suggest to add UNITS "buffers" to fcFxPortNxPortBbCredit. > > 28. Suggest to add a UNITS "bytes" to fcFxPortNxPortRxDataFieldSize. I > am not sure this is correct since I do not know how to interpret > the DESCRIPTION of this object. What is meant by "binary value" > here? > > 29. Are the accounting table really augments? I mean, do you really > want to have for every FxPort an entry in all three accounting > tables? Or is it possible that some FxPorts only have entries in > the C1 accounting table while other FxPorts only have entries in > the C2 accounting table? In the second case, do not use AUGMENTS. > Instead repeat the INDEX clause from the fcFxPortTable. > > 30. Is fcFxPortC1ConnTime really a Counter32? The description talks > about a cumulative time. A counter only counts events and is not a > type for measuring time intervals. > > 31. Minor indentation problem in the definition of the > FcFxPortC2AcctEntry SEQUENCE. > > 32. Suggest to add UNITS "buffers" to fcFxPortCapBbCreditMax and > fcFxPortCapBbCreditMin. > > 33. Suggest to add UNITS "bytes" to fcFxPortCapRxDataFieldSizeMax and > fcFxPortCapRxDataFieldSizeMin. > > 34. Suggest to add UNITS "milliseconds" to fcFxPortCapHoldTimeMax and > fcFxPortCapHoldTimeMin. > > 35. You currently have a single compliance statement, which requires > to implement the config and the status group. It is surprising > that this compliance statement does not require the implementation > of the error group. I also suggest to add a second compliance > statement for those implementations that implement all MIB groups. > > Furthermore, you should check whether write access to read-write > objects is required to be conformant. (You can formally express in > the compliance statement that write access is not needed.) Not > sure this is relevant for this module since there are only a few > writable objects and they seem to be pretty easy to implement. > > Also, some of the tables may be conditionally mandatory. For > example, a device which does not support class 3 frames can not be > expected to implement the class 3 accounting table. In this case, > you probably have to break the OBJECT-GROUPs into smaller pieces. > > Below is a proposal to start from: > > -- compliance statements > fcFeMIBMininumCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The minimum compliance statement for SNMP entities > which implement the FIBRE-CHANNEL-FE-MIB." > MODULE -- this module > MANDATORY-GROUPS { fcFeConfigGroup, fcFeStatusGroup, fcFeErrorGroup } > ::= { fcFeMIBCompliances 1 } > > fcFeMIBFullCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The full compliance statement for SNMP entities > which implement the FIBRE-CHANNEL-FE-MIB." > MODULE -- this module > MANDATORY-GROUPS { fcFeConfigGroup, fcFeStatusGroup, fcFeErrorGroup > fcFeAccountingGroup, fcFeCapabilitiesGroup } > ::= { fcFeMIBCompliances 2 } > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 -- ---------------------------------------------------------------------- Kha Sin Teow khasin@Brocade.Com Brocade Communications Systems Tel: 408-487-8180 1901 Guadalupe Parkway Fax: 408-487-8090 San Jose, CA 95131 http://www.Brocade.Com ---------------------------------------------------------------------- From owner-ipfc@standards.gadzoox.com Tue Jan 18 12:16:17 2000 Received: from standards.gadzoox.com ([216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03068 for ; Tue, 18 Jan 2000 12:16:13 -0500 (EST) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id JAA09273 for ipfc-list; Tue, 18 Jan 2000 09:02:32 -0800 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id JAA09270 for ; Tue, 18 Jan 2000 09:02:31 -0800 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Jan 2000 09:10:43 -0800 Message-ID: <312419998E3CD211A52900A0C991A47A22543B@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: FW: 47th IETF - Registration Now Open Date: Tue, 18 Jan 2000 09:10:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk -----Original Message----- From: ietf-registrar@ietf.org [mailto:ietf-registrar@ietf.org] Sent: Tuesday, January 11, 2000 7:44 AM Subject: 47th IETF - Registration Now Open 47th IETF: March 26-31, 2000 - Adelaide, Australia On-line Registration & On-line Payment Procedure Now Available To register for the upcoming IETF meeting, please fill out the On-line Registration form at http://www.ietf.org/meetings/IETF-47.html and click on the Submit button. Following receipt at the server, your browser will display your registration ID, total amount due and payment options. At this point, you may choose the On-line Payment Option using CyberCash, available directly from your browser on your registration confirmation page. We accept VISA, MasterCard and American Express. An e-mail message will also be sent to you confirming your registration information and listing other payment options - 1) reply e-mail using PGP, 2) print & fax, 3) print & snail-mail. You may choose whichever option is most convenient for you. Please contact IETF Registrar if you have any questions concerning registration, payments, etc.: ietf-registrar@ietf.org The registration fee is US$375.00 if RECEIVED by the cut-off of Noon ET, MONDAY, 6 MARCH 2000. After this date/time, a fee of US$475.00 must be paid on-site whether or not you have pre-registered. Full-time students with proper ID will receive US$100 off the registration fee. Failure to provide proper ID on-site will revoke the US$100 credit. CD-ROM (US$10) and Hard Copy (US$65) versions of the meeting Proceedings will be available approximately 8-10 weeks following the meeting. If you would like to receive either or both, check YES in the respective boxes on the registration form. The appropriate amount will be added to the total amount due. Your registration fee includes admission to all working group sessions and plenaries, Sunday evening reception (cash bar), continental breakfast and afternoon coffee breaks each day. CANCELLATION/REFUND POLICY: Refunds are subject to a US$50.00 service charge. Cancellations and requests for refunds must be received by 1700ET, Friday, 17 March 2000. Refund requests will not be honored beyond this point. To cancel and request a refund, contact the IETF Registrar: ietf-registrar@ietf.org If you are unable to access our Home Page on the Web, you will find the same registration form in the ftp/ietf directory (ftp.ietf.org) . The name of the file is: 0mtg-rsvp-form.txt. If you are also unable to access the registration form via ftp, please send e-mail To: mailserv@ietf.org and in the body of the message request FILE /ietf/0mtg-rsvp-form.txt PATH your-email-address@domain The registration form will come to you via e-mail. You can view the IETF Meeting home page at: http://www.ietf.org/meetings The URL for the on-line registration form is: http://www.ietf.org/meetings/reg_form.html ---------------------------------------------------------------------------- Please report problems or send comments to ietf-web@ietf.org . From owner-ipfc@standards.gadzoox.com Tue Jan 25 14:56:10 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06995 for ; Tue, 25 Jan 2000 14:56:08 -0500 (EST) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id LAA13105 for ipfc-list; Tue, 25 Jan 2000 11:39:43 -0800 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id LAA13102 for ; Tue, 25 Jan 2000 11:39:42 -0800 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jan 2000 11:47:55 -0800 Message-ID: <312419998E3CD211A52900A0C991A47A225457@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Cc: "Andrea Westerinen (E-mail)" Subject: Interoperability Test Date: Tue, 25 Jan 2000 11:47:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Folks: The next IPFC meeting is in Adelaide Australia (March 27-31). At this time I would like to invite proposals for an Interoperability Test Suite, planned during the month of April in Palm Springs, California. This event should coincide with a SNIA event at that location. Andrea Westerinen (SNIA Director) has volunteered to provide details on the location, hotel info. etc. The goal of the Interoperability Test is to move the RFC 2625 into a DRAFT STD. status after we have run the tests and weeded out the 'fat' (i.e., unimplemented features will be pulled out). What I would like to see is some email discussion on this started on this item. Based on the comments I receive, I will prepare the Test entrance criteria, so stay tuned. Regards, IPFC WG Chair Murali Rajagopal Senior Manager, Product Engineering Gadzoox Networks, Placentia,CA Tel: 714-577-6805, Fax: 714-524-8508 Email: murali@gadzoox.com <<...>> From owner-ipfc@standards.gadzoox.com Mon Jan 31 09:06:35 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03835 for ; Mon, 31 Jan 2000 09:06:34 -0500 (EST) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id FAA16246 for ipfc-list; Mon, 31 Jan 2000 05:53:04 -0800 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id FAA16243 for ; Mon, 31 Jan 2000 05:53:00 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03670; Mon, 31 Jan 2000 09:00:49 -0500 (EST) Message-Id: <200001311400.JAA03670@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipfc@standards.gadzoox.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipfc-fabric-element-mib-07.txt Date: Mon, 31 Jan 2000 09:00:48 -0500 Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Over Fibre Channel Working Group of the IETF. Title : Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard Author(s) : K. Teow Filename : draft-ietf-ipfc-fabric-element-mib-07.txt Pages : 52 Date : 28-Jan-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 the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfc-fabric-element-mib-07.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-ipfc-fabric-element-mib-07.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-ipfc-fabric-element-mib-07.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: <20000128151216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfc-fabric-element-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfc-fabric-element-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000128151216.I-D@ietf.org> --OtherAccess-- --NextPart--