CONFIRMED IEEE 802.1 WORKING GROUP MINUTES OF THE MARCH 1995 MEETING WEST PALM BEACH, FLA Working Group Plenary Attendees: Floyd Backes (VM) John Boal(BM) Laura Bridge (VM) Alan Chambers (VM) Steve Cooper (VM) Andy Davis (VM) John Grinham (BM) Jonathan Howard (BM) Hal Keen (VM) Srinivas Kola (BM) Bill Lidinsky (VM, Chair) Jorg Ottensmeyer (VM) Mick Seaman (VM) Rosemary Slager (VM) Bruce Taber (Observer) Peter Wang (BM) (VM - Voting Member, BM - Building Member, L- Liaison) 1. MONDAY PLENARY, March 6, 1995 1.1. AGENDA o Voters and voting - Keen o Documents - Keen o Details for this meeting - Lidinsky - Have 2nd room all day Tuesday Ongoing Responsibilities, Overview and Arch, Functional Req, ... o Minutes approval: Orlando and Tahoe meetings - Bridge o Executive Committee Report - Lidinsky o PAR Extensions or Revisions - Lidinsky - June 1997 for extensions - 802.1j Managed Objects for MAC Bridges - 802.1d MAC Bridge editorial & tech. corrections o 802.1 Minutes - Lidinsky - 802 Operating Rules - minutes required within 45 days - 802.1 really needs them o OATS Progress - Backes - Only 2 liaisons so far - 802.5 o MUTS Progress (Multimedia Task Subgroup) - Cooper o FRTS Progress (Functional Req. Task Subgroup) - Lidinsky - Only 2 liaisons so far - 802.5 - Need to form Task Group? o Internetworking Progress - Lidinsky/Seaman - 802.1G/D12 Remote Bridging Ballot Letter ballot conducted Have begun to process responses at this meeting - 802.1H/D5 MAC Bridging Ethernet v.2 in 802 LANs Will begin to prepare dossier for IEEE stds board (REVCOM) at this mtg. - 802.1j/D4 Managed Objects for MAC Bridges Ballot will begin immediately after this meeting - 802.1d Technical and Editorial Corrections Will 802.1 have balloted and completed draft to IEEE Stds Bd by June '97? o ISO Responses - Lidinsky - List of needed responses early this week. Amendment to 10742 (Doc 9217). Informal views to SC6. Formal position to Exec. Committee by Thursday o 802 Operating Rules - Lidinsky o Electronic Distribution of 802.1 Documents - Lidinsky - All documents to be in machine readable form - Everyone to be able to print postscript - Everyone to have FTP access - 802.1 WWW server? o Technical Plenary - Lidinsky - 802.3/802.1 Full Duplex and Flow Control - Functional Req. - Overview and Architecture - Multimedia 1.2. MINUTES The following proposal created by Mick Seaman was presented at the Opening Plenary. ------------------------------------------------------------- 802.1 Minutes Plan, as discussed 6-March-95, 802.1 Opening Plenary West Palm Beach meeting. Output of each meeting will comprise: 1. The ACTION list, supplemented by foils and information written at the meeting and reviewed at the closing plenary. The ACTION list will be distributed by the Secretary by email after the meeting. 2. The BRIEF MINUTES, which will comprise: a. the agendas of opening and closing plenarys as shown by the chair at those plenarys. b. the resolutions of the final plenary. c. Such discussion notes as are supplied by the leaders/participants to the secretary *at the meeting*, these notes will be identified as to source, the Secretary will include them at his/her discretion, and may or may not be responsible for checking and/or modifying the content. The BRIEF MINUTES will be distributed by the Secretary before the next meeting, and will be available at the next meeting for production at a final markup for 802.1 records. 1.3. PARS FOR 802.1 MULTIMEDIA SUPPORT IN MAC BRIDGES Mick Seaman distributed two draft PARs for multimedia support in MAC Bridges. The PARS, included as Attachment A, were distributed on the 802.1 email exploder following the November Plenary meeting. 2. WEDNESDAY TECHNICAL PLENARY, MARCH 8, 1995 2.1. AGENDA 8:30 - 9:30 Full Duplex and Flow Control 802.3 and 802.1 Tom Slykhouse made presentation 9:30 - 10:00 Multimedia report from 802.1 Mick Seaman made presentation 10:00 - 10:30 BREAK! 10:30 - noon Functional Requirements report from 802.1 Floyd Backes made presentation 3. THURSDAY MORNING SESSION, MARCH 10, 1994 3.1. RESOLUTION OF WORKING GROUP BALLOT COMMENTS Alan Chambers, the editor, introduced the "Proposed Disposition of comments on ballot of P802.1G/D12". ACTION - Alan Chambers to produce a further document "Summary of voting and comments" to formally capture the ballot results and comments discussed at the meeting. The meeting reviewed and agreed the proposed changes, none of which altered the technical content of the P802.1G. 3.2. MAC SERVICE DEFINITION _ PROGRESSION OF WORK Interworking Task Group discussion Thursday, March `95 Plenary - Mick Seaman o P802.1M o Scope? - Initial Scope - Connection Oriented MACs - Service Provision Binding - Extensibility, Setting Expectations o Purpose - Guidance - Framework for LAN Enhancements and Extensions + Bridged Local Area Networks + Multicasts + Multimedia - Facilitate Interworking, Interoperability - Incorporate Advancements in the Art, Recent Standards, etc. o At the High Level, Two Major Different Types of Services - Fill in existing gaps and Holes - Invent/Accommodate Future Developments o Organization of Work, Distinct Agenda Items A. Conservative Package Organize per "Enhancements to MAC Service Definition Slide" B. New Future Developments Identify Requirements/Users, Call for Comments o Formal Progression A. Start Work on Proposed PAR ACTION: Mick Seaman B. Write a Liaison Statement to Other Dotgroups and Discuss at Next Technical Plenary (Future Development) ACTION: Steve Cooper 4. THURSDAY PLENARY, MARCH 10, 1994 4.1. AGENDA o Voters and voting - Keen o Documents - Keen o Minutes - Bridge - Approve Tahoe Nov '94 minutes o PAR Extensions - 802.1d, 802.1G, 802.1j Requested extension to 6/97, 9/96, 6/97 respectively o 802.1 Minutes and Document Plan - Lidinsky o Initial Agenda Items requested for Exec Thursday night - Lidinsky - Liaisons - Sponsor ballot for 802.1G - Info on future PARs for 802.1 multimedia - Functional Requirements - Revision of IEEE/ANSI Std 802-1990 (Overview and Arch) o Functional Requirements - Backes - Status report to 802.1 and Exec o Overview and Architecture - Backes - Status report to 802.1 and Exec - PAR? o Internetworking - Chambers/Seaman o Multimedia - Cooper/Seaman o Ongoing Responsibilities? - Backes o Three 802.3 PARs - Lidinsky o Two 802.9 PARs - Lidinsky o 802.12 Universal Address Administration 4.2. DOCUMENTS The following 802.1 documents were added at this meeting: P802.1-95/003 - MAC Service Definition P802.1-95/011 - IEEE 802.1 Working Group Minutes of the November 1994 Meeting 4.3. MINUTES The November 1994 meeting minutes were reviewed and corrections were identified. The minutes were accepted as corrected. Moved: Keen, Seconded: Chambers None opposed. 4.4. 802 FUNCTIONAL REQUIREMENTS The following material was developed during the 802.1 Interworking Task Group sessions of the March `95 Plenary and presented by Floyd Backes during the 802.1 Closing Plenary. This reflects the informal position of 802.1 on the 802 Functional Requirements. --------------------------------------------------- The 802 Functional Requirements serve as guidelines for the development of 802 Standards. -facilitate interoperability -provide stability -minimize overlap 802.1 and 802.x liaisons have discussed the current 802 Functional Requirements (FRD) document (12/91). It comprises: 1. A list of standards to be adhered to or to be consulted. 2. Rules for MAN Interworking (apparently because no appropriate, i.e. ITU recommendation) reference exists (see 1. above) 3. Stipulations concerning safety, which might be met by adopting a suitable reference, see 1. above) 4. Material which has already been identified for inclusion in an expanded MAC Service Definition, e.g. consideration of multiple stations, QoS, geographical extent 5. Interoperability requirements, which should be satisfied by reference to 4. 6. A set of redundant items or items which have been superseded by other standards. 7. Operational Procedures for use by P802. We believe that these contents and their uses should be replaced by: A. A reference list for guidance to 802 developers (items 1,2,3 & 6) B. An improved MAC Service Definition which should be included in A. (items 4 & 5) C. The "5 Criteria" for evaluating new PARs (item 7) The development of new and different standards should also give rise to new work to formulate appendices to B if and as required. B needs to be a full fledged standard in its own right, following the precedent set by ISO 7498. This status will ensure that appropriate development and review procedures are employed. Since the FRD has an important secondary function of communicating the scope and current guidelines envisaged by P802, amendments and extensions to B. should be developed by 802.1 in conjunction with the International Community (ISO) as is currently the practice with other 802.1 Interworking Standards. The list A. should be open for public review. 802.1 will undertake to produce the list, on which approved standards may appear, in conjunction with 802.x liaisons. Enhancements to MAC Service Definition 1. Size (number of stations) and geographical scale of LANs 2. QOS - undetected error rate - throughput - data transparency - fairness - priority - data loss - time bounds - ordering/sequencing - frame duplication 3. Availability - addition and removal of devices - failure recovery 4. Multicast Service 5. MSDU Size 6. Flow Control and Rate Control 7. Addressing Documents needed for distribution to facilitate this work: - 15802 part 1 (a.k.a. 10039) **ACTION - Alan, provide 15802 to 802.1 on the FTP server within 30 days after this meeting. - <.1D section 2 - we have it> 4.6. INTERWORKING 4.6.1 802.1G REMOTE MAC BRIDGING REOLUTION: P802.1 instructs the editor for Remote MAC Bridging, Mr Alan Chambers ....... <> Moved: Chambers, Seconded: Y: 9, N: 0, A: 0 4.6.2 ISO COORDINATION REOLUTION: P802.1 Requests that the following documents be submitted as LMSC contributions to SC6/WG1 at the forthcoming meeting Moved: Ottensmeyer, Seconded: Bridge Y: 9, N: 0, A: 0 4.6.3. 802.1 INTERWORKING - NEW WORK PLAN Mick Seaman presented the following new work plan for the Interworking task Group. ----------------------- This plan reflects the proposed organization of work arrived at through discussion at the March `95 802 Plenary. It is intended to form the basis for organizing the agenda and focusing work and contributions thru the July `95 and subsequent meetings. S1. MAC Service Enhancements S1.1 PAR Development * S1.2 S1.3 S1.4 S1.5 S1.6 S1.7 S1.8 S1.9 S2. Future MAC Services S2.1 Liaisons and information dissemination * S2.2 Scope and partitioning of work S2.3 S2.4 S2.5 T1. Traffic Class Expediting/Dynamic Multicast Filtering T1.1 PAR Development T1.2 Enhanced Network Architecture, Mcast Scope T1.3 Target Network Topologies T1.4 Multicast and Priority Registration T1.5 End Station Uses of Enhanced MAC Services (Recommendation) T1.6 Public Network Protocols - Consideration & Relationships T1.7 Enhanced Bridge Operation - Basic Enhancements T1.8 Enhanced Bridge Operation - Full Support T1.9 Catalog of Target Applications and application Requirements 4. END STATION USES OF ADVANCED SERVICES o Use and Dynamic Allocation of Mcast Addresses - Why do I want to do this (protocol designer)? - What is reasonable protocol delay, How many mcast addressed packets do I transmit (designer) o Separation of multicast address from protocol ID. o Application considerations - Video Conferencing - "Security"/Privacy applications - Data Distribution in bulk o Priority Level Advice (user_priority) for Applications. o How many mcast addresses should be supported - by clients? (low number) - by server? (higher number) o What is expected client load, How many interrupts, etc. o Time Bound expectations and QoS in general o End station architecture and expediting in the end station (also carry over new MAC service) o Stations with multiple unicast addresses (needs to be strictly limited for high volume devices) 7. ENHANCED BRIDGE OPERATION a. What can be done now b. New PAR work -------------- Discussion of what can be done now, summarized: Basis of work is the "Traffic Class Expediting" foil from the November`94 meeting. o New user_priority -> Access Priority mapping rules may vary in effectiveness depending on the network topology, e.g., if Token Ring is microsegmented so that there are only bridges on the backbone, having all bridges use access priority of 4 minimum serves little purpose other than to truncate the priority space. o Number of queues may vary depending on the characteristics of the output port, e.g. 2 queues for each 10 Mbps port, only 1 queue for each 100 Mbps port -> need to represent system characteristics. o The database information can only be specified in very loose terms, and the ways of putting information in the database would need to be outside the scope of the document. Need to be aware/sensitive of shared resource conflict issues. o Provision also needs to be made for discard functions, e.g. how long has a particular frame of a given class been in the queue, and information to feed the discard function. o Need to establish what the "maximum functionality" forwarding process is, and what subsets are viable. o Discard policies may include rate limiting functions, not shown on "Traffic Class Expediting" at all. (This item should be covered in the overall architecture.* o Activation of discard functions on receipt rather than transmit is and option to explore, function of overall congestion. o Disentangling may not be possible for discard, feeding in current real world numbers is essential -> work item. 4.6.4. 802.1 INTERWORKING ACTIONS, MARCH `95 Mick Seaman presented the action items from this meeting for the Interworking Task Group. OLD WORK: o P802.1G: AC - Revise disposition of Comments AC - Produce summary of voting AC - Revise text, Submit to WPL and place on email exploder WPL - Initiate sponsor ballot WPL - Advise IEEE of need to form ballot Group o P802.1D: WPL - Inform IEEE of need to reaffirm 802.1D `as is' for 1995, thru Kelly McQuillan o P802.1d: WPL - Inform IEEE of intent to complete revisions PAR by __/97 MJS - Produce initial draft/list of proposed revisions and circulate via email exploder to .1 prior to July `95 meeting. o P802.1H: WPL - Forward to REVCOM by 5-May-95 SC - Carry .1H to IETF, receive acknowledgment to/for Lidinsky o P802.1j: AC- Send out ballot thru .1 exploder NEW WORK: o S1.1 MAC Service Extensions - PAR Development: MJS - Draft new PAR, circulate to .1 by email exploder prior to July `95 meeting. o S2.2 Future MAC Services - Proposed Liaisons: SC- Draft information liaison to dot groups, email to .1 exploder prior to next meeting, intent - discuss at Technical Plenary of next meeting. o T1.1 Traffic Class Expediting/Dynamic Multicast Filtering - PAR Development: All - Comments via email exploder by April 23 MJS - PAR to Secretariat by April 30 WPL - Forward PAR to 802.0 by deadline for July Meeting 4.6.5. PAR FOR 802.1 MULTIMEDIA SUPPORT IN MAC BRIDGES RESOLUTION: Progression of a new PAR for a Supplement to Media Access Control (MAC) Bridges: Traffic Class Expediting and Dynamic Multicast Filtering. P802.1 instructs Mr. M. Seaman to revise the proposed draft PAR to take into account comments received from P802.1 members, and to submit the revision to the P802.1 Secretariat by April 30, 1995. P802.1 requests its Secretariat to submit the revised PAR to P802.0 30 days prior to the July `95 plenary meeting of P802. Proposed: M. Seaman, Seconded: R. Slager Y-9, N-0, A-0 ---------------------------------------------------------------------- ATTACHMENT A) PARS FOR 802.1 MULTIMEDIA SUPPORT IN MAC BRIDGES The following draft PARs were distributed through the 802.1 email exploder following the November `94 Plenary, and in hardcopy at the Opening Plenary of the March `95 meeting. ================================================ Following our 802.1 discussion at the November '94 meeting in Tahoe, there are preliminary drafts for two new PARs to cover the subjects of Traffic Class Expediting and Dynamic Multicast Filtering. I tentatively propose that we partition the work between: 1. a new document, which: (a) describes the architecture for both traffic class expediting and dynamic multicast filtering - looked at from the point of view of the bridged network as a whole and the (enhanced) services that are provided (b) specifies the protocol to be used by end stations in support of these features and in appendices: (c) provides a tutorial on overall end station behavior, including the very significant issue of dynamic MAC address allocation if we go for something like the open host group model (d) describes our rationale, mainly based on a collation of material from the meetings we use to develop the standard. This should not only be informative to the user/reader of the standard, but should serve us as a record of the track we take. (e) describes how this whole scheme would fit within a hierachical multicast model at the network layer (e.g. the emerging IETF work on multicast). 2. a new supplement and set of revisions to 802.1D including: (a) references to document 1. above. (b) updates to 2. .. Service .. to acknowledge 1. above. (c) updates to 3. .. Operation .. for both expediting and filtering. (d) adds new BPDU formats to chapter 5. to encode the information to be passed between bridges (e) specifies how the bridge interacts with the end station protocol defined in 1. above. (f) specifies the bridge to bridge protocols to convey the information used for traffic class expediting and dynamic multicast filtering and in appendices: (g) describes bridged network reconfiguration and dynamic protocol issues. (h) describes network scaling and protocol performance issues. This partitioning attempts to deal with the following perceived facts: (i) the changed behavior of bridges has to be reconciled with 802.1D, therefore a completely separate document is inappropriate (ii) putting everything that the end stations have to do, and an explanation of the architectural enhancements to 802 LANs into .1D would make that document a monster (iii) there may well be common protocol mechanisms between traffic class expediting and dynamic multicast filtering so it would be artificial and suboptimal to separate them at this stage (iv) we don't have an existing document which really talks about the LAN service provided to end stations. IEEE Std 802 is not it. The nearest we have is the MAC Service Definition (ISO/IEC 10039), but that only talks about instances of service provision between two end stations - a very limited starting point for describing an entire bridged local area network, hence the need for a new document 1. above. ============ IEEE Standards PROJECT AUTHORIZATION REQUEST (PAR) 1. Date of Request: 2. Assigned Project#: 802.1p 3. Does this PAR revise a previously approved PAR: NO 4. Description of Proposed Document: New Standard Full Use 5. Project Title: Traffic Class and Dynamic Multicast Filtering Services in Bridged Local Area Networks 6. Scope of Propose Standard: Specification of services provided by Bridged Local Area Networks to 802 end stations to support timely delivery of selected classes of traffic. Specification of services provided by Bridged Local Area Networks to 802 end stations to allow them to constrain multicast traffic, i.e. Group addressed frames, to those areas of the network necessary for the frames to reach stations belonging to a target group. Specification of protocol(s) used by end stations to register for such services. Guidelines for the use of such services by 802 end stations. 7. Purpose of Proposed Standard: To improve support of time critical and multicast intensive applications, including `multi-media' interactive applications, across bridged LANs. To reduce the degree to which the level of multicast traffic and the loading levels selected for timely information delivery limit the number of attached stations and the throughput of Bridged Local Area Networks. To facilitate Bridged Local Area Network support of the 'hierarchical multicast' capabilities developed for internets, in a way that is compatible with their emerging network layer protocols. 8. SPONSOR: LMSC 9. Name of group that will write the standard: IEEE Project 802.1 Working Group 10. Target Completion Date: May 1997 11. Proposed Coordination: Method of Coordination: SCC10 (IEEE Dictionary) Circulation of Drafts ISO/IEC JTC1 SC6 Circulation of Drafts Liaison Membership IETF Circulation of Drafts 12. Are you aware of any patent, copyright, or trademark issues? No. Are you aware of any standards or projects with a similar scope? No. 13. Copyright Agreement for IEEE Standards I hereby acknowledge my appointment as Official Reporter to the IEEE Project 802.1 Committee to write/revise a Standards Publication (entitled or to be entitled) IEEE Std. 802.1p Use of Traffic Class and Dynamic Multicast Filtering Services in Bridged Local Area Networks In consideration of my appointment and the publication of the Standards Publication identifying me, at my option, as an Official Reporter, I agree to avoid *knowingly* incorporating any copyrighted or proprietary material of another without such other's consent and acknowledge that the Standards Publication shall constitute a "work made for hire" as defined by the Copyright Act, and, that as to any work not so defined, I agree and do hereby transfer any right or interest I may have in the copyright to said Standards Publication to IEEE. Name W.P. Lidinsky_______________________ (signature of chair of working group) Title Chair, IEEE Project 802.1 Working Group Date July 1995 14. Person delegated to receive communications and conduct liaison with interested bodies: (This is normally the chair of the working group. If not, please indicated IEEE position.) Name William P. Lidinsky Telephone 708-840-8067 Company Fermilab, M/S 234 Fax 708-840-2783 Address P.O. Box 500 Telex City Batavia State IL Zip 60510 E Mail 15. Submitted By: (This is normally the sponsor's liaison to the Standards Board. If not, please indicate IEEE position and relationship to the sponsor.) ============ IEEE Standards PROJECT AUTHORIZATION REQUEST (PAR) 1. Date of Request: 2. Assigned Project#: 802.1q 3. Does this PAR revise a previously approved PAR: NO 4. Description of Proposed Document: New Standard Full Use 5. Project Title: Supplement to Media Access Control (MAC) Bridges: Traffic Class Expediting and Dynamic Multicast Filtering 6. Scope of Propose Standard: Specification of mechanisms in MAC Bridges to expedite delivery of time critical traffic and to limit the extent of high bandwidth multicast traffic within a Bridged Local Area Network. Specification of protocol mechanisms in MAC Bridges to support dynamic registration for these services by end stations. Specification of protocols between MAC Bridges to efficiently convey registration information in a Bridged Local Area Network. 7. Purpose of Proposed Standard: To improve support of time critical and multicast intensive applications, including `multi-media' interactive applications, across bridged LANs. To reduce the degree to which the level of multicast traffic and the loading levels selected for timely information delivery limit the number of attached stations and the throughput of Bridged Local Area Networks. To facilitate Bridged Local Area Network support of the 'hierarchical multicast' capabilities developed for internets, in a way that is compatible with their emerging network layer protocols. 8. SPONSOR: LMSC 9. Name of group that will write the standard: IEEE Project 802.1 Working Group 10. Target Completion Date: May 1997 11. Proposed Coordination: Method of Coordination: SCC10 (IEEE Dictionary) Circulation of Drafts ISO/IEC JTC1 SC6 Circulation of Drafts Liaison Membership IETF Circulation of Drafts 12. Are you aware of any patent, copyright, or trademark issues? No. Are you aware of any standards or projects with a similar scope? No. 13. Copyright Agreement for IEEE Standards I hereby acknowledge my appointment as Official Reporter to the IEEE Project 802.1 Committee to write/revise a Standards Publication (entitled or to be entitled) IEEE Std. 802.1q (Supplement to IEEE Std. 802.1D-1993) Media Access Control (MAC) Bridges: Traffic Class Expediting and Dynamic Multicast Filtering In consideration of my appointment and the publication of the Standards Publication identifying me, at my option, as an Official Reporter, I agree to avoid *knowingly* incorporating any copyrighted or proprietary material of another without such other's consent and acknowledge that the Standards Publication shall constitute a "work made for hire" as defined by the Copyright Act, and, that as to any work not so defined, I agree and do hereby transfer any right or interest I may have in the copyright to said Standards Publication to IEEE. Name W.P. Lidinsky_______________________ (signature of chair of working group) Title Chair, IEEE Project 802.1 Working Group Date July 1995 14. Person delegated to receive communications and conduct liaison with interested bodies: (This is normally the chair of the working group. If not, please indicated IEEE position.) Name William P. Lidinsky Telephone 708-840-8067 Company Fermilab, M/S 234 Fax 708-840-2783 Address P.O. Box 500 Telex City Batavia State IL Zip 60510 E Mail 15. Submitted By: (This is normally the sponsor's liaison to the Standards Board. If not, please indicate IEEE position and relationship to the sponsor.) ================================================== ---------------------------------------------------------------------- ATTACHMENT B) 802.1 MINUTES AND DOCUMENT PLAN This plan is presented at the 802.1 closing plenary on Thursday afternoon, 9 March 1995 at West Palm Beach. -------------------------------------------------------------------- 802.1 MINUTES AND DOCUMENT PLAN =============================== Bill Lidinsky 8 March 1995 This plan applies only to 802.1 meetings held in conjunction with 802 full plenary meeting which are held three times each year. The goals of this plan are: 1) An ACTION_LIST for use by members of 802.1 within two weeks after the end of the 802.1 meeting. 2) The collection of all SUPPLEMENTARY MATERIAL 3) A set of DOCUMENTS distributed and created at the 802.1 meeting, appropriately numbered and placed on the 802.1 FTP server. DOCUMENTS in machine readable form to be put on the server within three weeks of the meeting. 4) A set of BRIEF_MINUTES for reference by members of 802.1 by the next 802.1 meeting. These minutes will also be placed onto the 802.1 FTP server. ACTION_LIST ----------- The 802.1 Recording Sec. will review an action list with members of 802.1 at the end of the closing 802.1 plenary, and distribute the ACTION_LIST by email via the 802.1 email exploder within 2 weeks of the end of the meeting. In addition, items in the ACTION_LIST to be carried to the 802 Exec. Comm. will be provided by the Recording Sec. (or other members of 802.1 he or she designates) to the 802.1 Chair (viewgraphs and two paper copies if needed for formal submission) immediately at the end of the 802.1 closing plenary. The 802.1 Chair will put the ACTION_LIST on the FTP server. SUPPLEMENTARY MATERIAL ---------------------- SUPPLEMENTARY MATERIAL will consist of a) material for which there exists a machine readable form at the meeting e.g., -resolutions generated by computer -notes committed to machine readable form during the week -viewgraphs generated by computer -viewgraphs generated by hand but copied during the meeting -contributions generated in machine form This type a) SUPPLEMENTARY MATERIAL will be provided to the Recording Sec. in both hard copy and machine form at the time that it is discussed if possible, but should be provided by the close of the 802.1 plenary. Material not provided will not be circulated further and may jeopardize action items. b) material for which there exists no machine readable form. This type b) SUPPLEMENTARY MATERIAL will be provided to the Recording Sec. in hard copy form at the time that it is discussed. Material not provided will not be circulated further and may jeopardize action items. The Recording Sec. will create four copies of the above SUPPLEMENTARY MATERIAL (in both forms where possible) before the end of the week of the meeting and distribute the copies to the 802.1 Chair, Vice Chair, and Operating Sec., and Recording Sec. (Copying of disks will be done either by the recording secretary or other members of 802.1 at the request of the Recording Sec.) SUPPLEMENTARY MATERIAL of type a) will be placed on the 802.1 FTP server within three weeks of the meeting. The 802.1 Chair will investigate the effort and form in which type b) SUPPLEMENTARY MATERIAL might by put onto the FTP server. But, in general type b) SUPPLEMENTARY MATERIAL will be available only from the originator of that SUPPLEMENTARY MATERIAL. DOCUMENTS --------- DOCUMENTS related to the work of 802.1 will be submitted in hard copy duplicate plus machine readable form (where available) to the 802.1 Operating Sec. Tyep a) DOCUMENTS are those having both forms; type b) DOCUMENTS have only paper form. The 802.1 Operating Sec. will provide selected copies to the 802 Executive Committee Executive Sec. for inclusion in the IEEE Document List. The 802.1 Operating Secretary will (with the help of other members of 802.1 to copy disks if needed) will provide the collected set of machine readable DOCUMENTS to the 802.1 Chair for inclusion in the 802.1 FTP server. Type a) DOCUMENTS will go on-line within three weeks of the end of the meeting. The 802.1 Chair will investigate the effort and form in which type b) DOCUMENTS might by put onto the FTP server. But in general type b) DOCUMENTS will be available only from the originator of that DOCUMENT. BRIEF_MINUTES ------------- BRIEF_MINUTES will be composed of: a. the agendas of opening and closing plenarys as shown by the 802.1 Chair at those plenarys. b. the resolutions of the closing plenary. c. Such discussion notes as are supplied by the leaders and participants to the secretary *at the meeting*. Copies of the resolutions to be forwarded to the 802 Exec. Comm. will be provided to the 802.1 Chair by the Recording Sec. at the end of the 802.1 closing plenary. The above notes will be identified as to source by the person providing the notes. The Recording Sec. will include them at his/her discretion, but will not be responsible for checking or modifying the content. The brief minutes will be distributed by the Secretary before the next meeting, and will be available at the next meeting for production as a final markup for 802.1 records. The Recording Sec. will provide copies of items in the BRIEF_MINUTES that are machine readable to the 802.1 Chair for placement on the 802.1 FTP server as partial BRIEF_MINUTES. This will be done as soon as practical. ---------------------------------------------------------------------- ATTACHMENT C) FUNCTIONAL REQUIREMENTS PURPOSE The following is the contents of a foil on Functional Requirements created by Lidinsky that reflects a perspective on this topic that is not held by 802.1 as a whole. The presentation given by Backes during the Thursday Closing Plenary reflects the informal position of 802.1. --------------------------------------------------- Lidinsky - 8 March 1995, West Palm These are a brief discussion of possible Functional Requirements purposes. they are based upon a viewgraph presented at an 802.1 WG meeting on 7 March 1995. The viewgraph has been embellished for clarification. (1) Define the scope and requirements of 802 projects. i.e., define 802's "turf" Used to test the validity of projects and to determine whether they move from proposed to officially sactioned activities. (2) If a project doesn't meet the Functional Requirements, the either a. get an exception, or b. terminate the proposed activity (3) If a pattern of specific exemptions emerges, then seek to revise the Functional Requirements. The "trick": Do (1) so as to minimize the effort of (3) while making the test implied in (1) and (2) easy. Other Functional Requirement purposes: - a vehicle to provide stability over time - a vehicle to minimize overlap