Internet Standards

home *** CD-ROM | disk | FTP | other *** search

/ Internet Standards / CD1.mdf / MISC / MERIT / 1993 / 93_214.TXT < prev next >

Wrap

Text File | 1993-06-28 | 38.0 KB | 952 lines

X3S3.3/93-214 Draft Minutes - X3S3.3 176th Meeting April 20-22, 1993 Penta Hotel, Orlando, Florida Opening of Meeting: Mr. Chapin opened the meeting at 10:00 AM of April 20. The attendance list and meeting attendance record were circulated. Mr. Taylor noted that the document register has been updated substantially in the past several weeks. A paper copy will be distributed sometime today. The Seoul meeting has been moved up one week to September 13-23. Due to the shift in schedule, X3S3.3 will have to submit a delegates list to X3S3 next week. A delegates list was then circulated. If the X3S3 meeting can be moved, the delegates list will also be circulated at the next meeting. Chairman and vice-chairman for X3S3.3 expire on July 27. If you or your organization are willing to accept/fill the vice-chair position, let Lyman know (Ed Taylor has resigned out of this meeting). Vice-chair is responsible for distribution of documents, which is the biggest overhead. SC6 documents (unless generated by US or UK) are generated in paper only and therefore will always have to be copied and distributed (at least for time being). There are a fair amount of ballots which need to be dealt with at this meeting. This afternoon will be devoted to ballot comments. If ballot comments are completed by this afternoon, all of Wednesday and Thursday will be devoted to Multicast and ECFF discussions. Approval of minutes: 93-18, Minutes from 174th meeting in Menlo Park, CA No one had copies and therefore vote was deferred. 93-153, Minutes of Multicast Workshop in Arlington, VA Questions were raised by Ed about de-enrollment and de- allocation; Lyman referred him to 93-180 for definition/explanation of each term. Dave Marlow questioned why HSTP has an X under central/decentral. A vote was deferred until the table characterizing each protocol could be checked for accuracy. Both minutes were held over for further review. Approval will be Thursday during approval of output documents. The Chair asked and got permission to proceed in absence of approved minutes from prior meeting. Ballot Responses: In attendance: Lyman Chapin (BBN) Dave Katz (cisco Systems) Cyndi Jung (3Com) Bill Goodrick (Stricom - Army) Margaret Loper (IST) Eugene W. Geer (Bellcore) Kevin L. Thompson (Mitre) Samir Saad (AT&T Bell Labs) Dave marlow (NSWC) Phil Irey (NSWC) Ed Taylor (IBM) Steven C. Andersen (Paramax) James Moulton (ONS) Doug Montgomery (NIST) Joel Snyder (DECUS) Marc Cohn (Raychem) The group recognized the ingenuity of Joel Snyder in providing a long shoe string and making the appropriate hanging fixture for the flip chart paper. Lyman Chapin proceeded to review the list of Ballots and NB comments for consideration at this meting. Ballots and NB Comments: 1. 8348/DAM5 93-103 2. 8348/PDAM7 93-105 3. 8473/PDAM7 93-104 4. 9542/PDAM2 93-106 5. 8473-1 2nd edition 93-143 (Chapin noted that this version only contains the subnetwork independent functions; other parts will contain the subnetwork dependent functions that used to be contained within the base document) There was a question on whether to hold this off until the June meeting to allow members time to do a thorough review. Jim Moulton suggested writing up a pseudo set of comments for e-mail distribution and allow the members to use that as a starting point. Chapin will take this as an action item to do. 6. CLNP Multicast Scope Control 93-107 7. Defect Reports 10733/001-003 93-132 No one present was familiar with this item. Gene Geer will get with the editor to get more background for the group to make a decision. 8. Defect Report 10589/002 93-130 Chapin indicated that these defects were generated by the 10589 Editing Group and are most likely to be real defects. Recommended that we just vote YES w/no comments. Agreed! 9. Internet Society Liaison 93-148 Lyman outlined the background of the liaison initiative with the Internet Community. The question for the group is what kind of response to forward back. It would be much better to have concrete proposals rather than to just say "we should communicate back and forth". One proposal that was floating in the London Meeting was to let the technical work be done by the IETF similar to the IEEE 802 procedures with ISO. Another alternative is for ISO to refer to the Internet Standards. Chapin noted that there is dislike within the Internet community for the large number of checks and balances within the ISO community which extend the time required to get standards approved. Also, it was noted that the Internet community is only interested in Internet Routeing, Transport, and possibly security. Lyman - note that many people in London were in favor of liaisons with the Internet community based on ISO CLNP being adopted as the replacement for IP (i.e. TUBA). Marlow suggested outlining a list of reasonable activities to have done within the IETF that are IETF- significant. Lyman will generate a first-pass listing and scenarios for consideration. Will have available at our June meeting. 10. NP (for comment) on CLNP Extensions 93-94 This is not an actual NP. Just being circulated for NB comment. Options include support as-is, add flow identifiers, etc. Any other options to consider? Essentially this is headed for version 2 of CLNP. It was agreed that the 32-bit time stamp needs more definition. Proposed response: Circulate for Ballot WRT base text attached, the time stamp is under-specified. Specify same as IP time stamp. Agreed! Document 93-196 11. 8602/DAM1 (PICS) 93-114 Ballot has not been issued at this point. There are no apparent issues. Chapin recommended that we just authorize a "YES" vote when the ballot is issued. Agreed (Yes w/o comments). 12. 10736/DAM1 (Sec. Assoc. Estab) 93-13 Dave Marlow with get with Dale Walters to get input. Ballot will close prior to next X3S3 meeting. 13. DIS 11577 (NLSP) 93-11 14. 9542 Five-year review No problems indicated. Response will be "Yes w/o comment" 15. NP for 8073 non-blocking expedited 93-115 H. Lee proposed USA response of Yes to first 5 questions with Lee as editor. No to last 2 questions (contribution available or available within 90 days). Approved! 16. 10737/PDAM1 (NCMS Management) 93-116 Gene Geer with get with Andy Knapp for further input. 17. PDTR 13594 (LL Security Model) Dave Marlow will get input from Dale Walters. Defect Reports: 1. 8073/076 93-108 Moulton recommended reject. Agreed. Document 93-197 2. 8073/127 93-109 Agreed that the defect report is harmless. It also references an earlier edition of 8073 (1988). Response is that US would like to see defect cast in terms of the new edition of 8073 to determine validity. Document 93-198. 3. 8073/148 93-110 Proposed USA Position will be to agree with Editor's proposed disposition. Document 93-199. Comments: 1. Transport Multipeer Service 93-188 2. Proposed amendment to 8072 for MPDT 93-189 and 93-124 3. ECFF Issues 93-190 and SC6/N7969 4. Proposed progression of work on CL 93-183 transport multicast Joint Meeting with Task Group 7: Task Group Joint Meetings Fred Burg indicated that a September '93 meeting would not be required of TG7. Chapin indicated that TG3 agreed to cancel its September meeting. If required, any agreements could be reached by E-mail and forwarded to X3S3. Also Fred noted June meeting dates. TG3 will meet Wednesday thru Friday (2-4). November 2-4 meeting will be moved to Boulder. January '94 meeting has been volunteered for Tucson (Joel Snyder). First Week (January 4-6). CCITT Meeting Results (Helsinki) Fred Burg reported. Significant output is the name change to WTSC. CCITT and CCIR are being realigned. CCITT and part of CCIR form Telecommunications Sector. Fred noted the new format for contributions. Eliminate Roman Numerals. Real name of contact person included in lower left corner. Normal method for approving recommendations is same as accelerated approval procedures used previously. If SG agrees that standard is ready, then it can be balloted immediately and issued as recommendation. Must be pre-warned at previous meeting. Two-thirds approval required. Multicast Workshop (Marlow) Minutes contained in 93-153. Major goal was to come up with agreed-to terminology to sort out various projects. Noted comments from Japan in which there was concern with terminology (1 to N, N to 1, etc). Further discussion will begin at 9:00 AM Wednesday April 21. Wednesday, April 21 Multicast Discussion: Document List for Multicast Discussion: Arlington Workshop Minutes 93-153 Arlington Workshop Papers 93-175 thru 180 Explanation of Terms (Day) 93-105 Backup (FYI) 93/155-159, 161, 162, 164- 174, 9, 10 Last SC21 Work (Multipeer Add. to RM) 93-160 Services and Protocol Marlow 8072 92-384 Marlow 8602 92-383 Moulton MPTS 93-125, 193, 194 Moulton MPTP 93-126 HSTS 92-381 HSTP 92-424 Thompson TP4 ext. (8073) 93-191, 192 ECFF Guidelines 93-8 SC6 Summary 93-190 Lyman opened the discussion by reviewing the purpose/intent of the Multicast Workshop. +----+ | | <- This is the multicast "solution space." +----+ The purpose of the workshop was to define the terms and taxonomy of multicast and to identify where each of the multicast proposals (i.e., TP4 ext., TP5, HSTP, 8602) fit in the multicast "solution space". By characterizing each proposal using common terms and taxonomy, we have a better understanding of what each proposal is and what it is not. At the Arlington workshop John Day gave a presentation on architectural issues which established 3 phases: Enrollment, Allocation, and Data Transfer (see 93-180 & 153 for details and explanation of terms). These terms were briefly discussed. Lyman then opened-up the discussion to the task group: At the Arlington workshop, we used an analogy of that meeting to explain the phases, and we focused on enrollment of that one meeting. This bothered Fred Burg. He noted that a group is associated with a list (finite or known), and in Arlington we used one mailing list of X3S3.3 and how got created - it shouldn't have been looked at in isolation. That mailing list involved some enrollment activity, and that list was part of a much larger group, X3S3. We focused too much on S33 list. Maybe that was wrong. Jim Moulton gave the group his definition of the phases. Enrollment establishes the state of the information that will become shared when allocation begins. Allocation begins when the first member grabs the shared information. Lyman, at flip chart, defined the phases as follows: Enrollment Allocation Data Transfer + creates the shared + establishes an + dimensions state that makes it instance of a group possible to embark conversation upon Allocation + criterion based Since there was much confusion in Arlington over what the Enrollment phase actually was, Doug Montgomery was concerned that we shouldn't draw the line too fine. Of course, everyone's perspective on the phases will be skewed somewhat depending on their view of the world and their model of multicast. Jim Moulton wanted to know if we could reach agreement that these indeed are the 3 phases of multicast and that, from now on, we will describe multicast in these terms. Lyman noted that if you have a multicast proposal on the table you have to understand the model and feel comfortable with the model before you can accept to use it. A question was raised by Dave Marlow on Enrollment. He noted that we can describe the CL multicast in terms of the model, but is it useful? Lyman answered by saying "not for your corner of the solution space." Enrollment is not so much a phase as it is a state of where you are before Allocation begins. Doug Montgomery agreed that the three phases are still a useful model for the CL case. Enrollment describes what happens with the routers, etc. Is the union of the cases we are interested in sufficiently close to fit in this model? That's the question. We don't want the model to preclude any progress being made on any one particular model. Steve Anderson thought the model was so new with new terms that SC6 would just argue about the model and terms and never make progress (in Seoul). He was concerned that we would spend all of our time teaching everyone the new terms and maybe we should modify just the existing MPDT Addendum and work from there. Lyman pointed out that we're already in that case. This architecture won't muddy the water - there is no clear point of reference for multicast in SC6. Dave Marlow stated that we should continue with the architecture model; however, he doesn't think a service or protocol specification should have to be documented that way. Lyman quoted "Architectures are not ends in themselves." By buying into this you will agree to defend and promote your proposal by these terms. It will not be an evaluation criteria, just a tool. Then what does this buy you? A common set of terms for characterizing the protocols. Jim Moulton added, BTW Enrollment is not something you see in a service specification. Fred Burg concurred. Marc Cohn was concerned that this architecture didn't cover the hard architectural principles like error control and connectivity (1xn, nxn, ...). Lyman referred him to 93-180. Jim Moulton pointed out that this architecture doesn't solve the problems, it identifies the problems. Remember, this is only a cut through the solution space, we aren't expecting each proposal to cover everything. This architecture isn't a layered proposal, you can't take Fred's Allocation and Marc's Data Transfer and combine them. Doug Montgomery added that we should view this as a process taxonomy. There are lots of issues that transcend this process model (e.g., 1xn, nxn). Steve Anderson was concerned that we're only looking at mechanisms for protocols, and we should be focused on what the services are (1xn, nxn, best effort, etc). Lyman noted that this is precisely what we are doing. In fact, section 2.0 of 93-180 does just that. Yes, there is a majority of mechanisms in the document right now. But that is not to mean that protocols are the only thing we are classifying. Jim Moulton added that since the Arlington meeting focused mostly on protocols, the classification (in 93-153) reflects that. Dave Katz asked Steve what he would propose as an alternative? Dave noted that we have a starting point, why not refine the model and stop the pissing match. We will continue to refine this model, but not let the architecture take over. Lyman then asked how we want to proceed today? We can continue to refine the model or accept the model and start describing/discussing the services and protocols. We then went around the room: [Doug Montgomery] Good start, but not finished with the architecture. Let's not turn this into a war of attrition (e.g., XTP showed up 5 years ago!). [S3.7 members] Seems more productive to go with the model that continue pointless argument. [Fred Burg] Refining terms from Arlington is useful, not to say work should stop on protocols until it is finished though. [Marc Cohn] Has had a hard time understanding the model - thinks we should look at the 4 step rule in SC6 to determine how to proceed with proposals. We should drive for progress in areas that we understand. For more extensive multicast proposals, we should look at a path to get there - there is not just one discrete path we should follow. We should evaluate each proposal on it's own merits. There are very complex problems that need to be solved and require much more work. Our role is to standardize solutions, not create solutions. [Bill Goodrick] This group is fortunate to have Lyman as a leader and negotiator. [Jim Moulton] Framework is good starting point to help define where proposals are going. It should not be over constraining or broad. Let's not preclude discussion on proposals which include complex issues. This model should not exclude any proposal from being discussed. Proposal should be evaluated on it's technical merit. Should not hold up simple solutions; however, should not create a ton of service specifications which are incompatible (goal). [Doug] We should beware of creating too many multicast Transport protocols! Could be perceived negatively by SC6 (i.e., short term, mid term, and long term solutions all progressed). Don't want to create protocols that no one will use. [Margaret Loper] Agrees with everyone so far. Accept the model and would like to move onto discussing services and protocols. In the 1.5-2 years she's been participating in this group there has been virtually no progress (wrt to Transport multicast). Getting very frustrated with the counterproductive fights. Would like to see us make progress for once. Also, would like to see each proposal evaluated on it's own merits. We should accept that not every application needs the same kind of multicast so need to consider different types of protocols. [Lyman] While that's true, we're not here to tailor standards to specific environments. We are here to standardize protocols that meet the requirements of the 95%, not the 5%. [Samir Saad] Good starting point, but concerned about making progress. [Gene Geer] Good starting point. [Steve Anderson] Believes that progress was made at the Arlington meeting. Should look at what SC6 NBs have looked at and want. Would like to put all services in a bucket and painfully evaluate each one. Don't focus on abstractions, look at users requirements. Recognize that there are other activities (e.g., IETF, proprietary) in multicast and that they will progress faster that we will. That our process is flawed and someone else will get the 95% of the market and our standard is a moot point. [Kevin Thompson] Haven't been comfortable about model because haven't understood implications. Still don't understand how it applies to extending existing standards. Now, feels more comfortable. Would like to discuss terms in 93-180 and refine them this afternoon and move on from the discussion of the model itself. [Cyndi Jung] Not comfortable with Transport multicast, not sure where ULA is going. Doesn't know how it will all hold together (ISIS, IDRP). Not sure how everything will work with ISOC and its implications. Not worried about Transport yet, terminology not a problem. Like a bottoms up approach. If you don't have Network layer stuff, what does Transport matter? [Dave Katz] Taxonomy is important - there has to be a level setting. If we ever hope to have a productive discussion, you have to have a level field. [Dave Marlow] Also worried about Network layer. Doesn't understand how taxonomy applies to services. Would like to work on something practical. Goals for Seoul - way to describe services. If we can't do this in the U.S., how do we hope to do it in SC6? Look at what we have. [Phil Irey] Taxonomy is useful, don't want to see it get in the way of progress. What do we have and what are we taking to Seoul: Network Layer Multicast ~ 8473 8473/PDAM7 (92-308) scope control (start email thread) ~ 8348 8348/DAM5 (group network addresses - handle in June) 8348/PDAM7 (multicast network service - handled in 93- 202) ~ 9542 9542/PDAM2 (handled in 93-205) ~ 10589 (ISIS) take advantage of existing work in Q5/7 ~ 10747 (IDRP) take advantage of existing work in IDMR/IETF Transport Layer Multicast ~ Proposed progression (93-183) CLTS (8072/Am?) CLTP (8602/Am?) ~ Multicast Transport Service (93-189) Cohn: 93-201 HSTS: 92-381 Moulton: 93-124, 125, 193, 194 ~ Multicast Transport Protocol HSTP: 92-424 Moulton: 93-126 Thompson: 93-191, 192 Multipeer Architecture Terminology/Concepts: 93-180 Moulton: 93-175 Japan: 93-188 Multicast Workshop: 93-153 Lyman stated that he wanted to take a taxonomy paper, but 93-180 would have to be revised between now and June. Also need to work on ISIS and IDRP (at the Network layer), but have no resources to devote to it right now (worried). Joel Snyder said that some work was going on in CCITT which could be useful; would have to be reformatted though. Ballot Responses (Continued): 8348/DAM5 (93-103) All the major comments were from the UK - all issues were resolved in London. Changes: (1) Before London, group network addresses had mixed format (1 abstract syntax with 2 values). UK was unhappy - wanted mixed format changed to Hex representation. French had similar comment. So, no longer mixed format. (2) UK asked that values reserved for future also be specified (added table AY). (3) Terminology change: unicast network addresses changed to individual network addresses. Dave Katz recognized that we will now need new encoding rules for Hex abstract syntax. Lyman noted that this is a pandora's box. We can push off until June because DAM ballot is 6 months. We have time to figure it out but must start an email thread to solve this before June. 8348/PDAM7 (93-105) Changes: Added new Chapter 18 covering scope control. Lyman asked whether it was intentional to describe multicast as transfer instead of transmission? Dave Marlow could not remember. French were working on definitions, but not sure if that was one they worked on. Lyman suggested that we should change transfer to transmission and make it a definition, not a description (transmission is already used throughout anyway). A question brought up in London was "Do you need additional scope control over what address semantics provide?" Yes, we anticipate the possibility. Start email thread: need to have scope control mechanisms that operate other than what addresses provide. Need concrete examples. Do we want to use multipeer or multicast in this? Change primitives in Annex A to multicast from multipeer (for consistency). Saved by procedure (unusual)! Can submit comments now and submit additional comments to Seoul as late contribution. Scope section needs to be wordsmithed. Agreed, vote Yes with comments. Ballot comments on 8348/PDAM7 are contained in 93-202. 8473/PDAM7 (93-104) Changes: scope control got pulled out in London. Lyman saved PDAM ballot. French had questions on scope control that Dave Marlow couldn't answer. The PDAM now only mentions scope control as a service provided. Jim Moulton thinks we should vote No with substantial comments. ~ Restore scope control (need worked-out examples: sending to unknown group, but local policy prohibits sending outside of a domain; requires that you know the address administrative policy in a domain outside of your local domain). Someone in London felt that scope control was routing and outside the domain of 8473; believed that scope control belongs in ES-IS and IS-IS. Need to find out from Dave Oran what the source routing field and routing domain address are expected to do. Source routing allows you to do tunneling. Need to work on this between now and june US comments on specific concepts for scope control are contained in 93-107. Need an email thread on 93-107. ~ NSEL = 0 provides a means to do CLNP encapsulation. May want a more generalized encapsulation scheme to provide a means to tunnel using unicast addresses between sites. Response held over to June. ~ Major specific values for section 6.14 Table 5, need new PDU type code. U.S. suggests 11101. ~ Note on combining unicast and multicast should be taken out (contact Joel Halpern). Should disallow group addresses in source or destination or source routing field of a unicast data transfer PDU. Vote No with comments; ballot comments on 8473/PDAM7 are contained in 93-203. 9542/PDAM2 (93-106) Close to no changes at London meeting from Menlo Park meeting. Dave Katz had editorial and organization comments on the document. Dave Katz will work with Dave Marlow to create the ballot comments. Vote Yes with comments; comments are contained in 93-205. Meeting Adjourned until 8:30 AM Thursday, April 22. Thursday, April 22 Agenda: Multicast until 10:30, then short break and approve documents. Multicast: Jim Moulton made a proposal for what to take to Seoul. He suggested that we start email threads on 3 or 4 topics and then turn them into contributions: 1 - Architecture model. Define the solution space we're trying to solve; lay the ground work for other contributions (not an NP to produce a multicast architecture - just a road map). 2 - Transport multicast service based on comments to N7445. Will start with answers to 93-201 (Jim will start this thread). 3 - Separate threads on 4 proposals for protocols, i.e. 8602, extensions to TP4, TP5, and HSTP. Lyman suggested that the June meeting then be used to thoroughly review what happened on each email thread. We will want to make sure that each proposal is technically sound before sending it forward. This will be the only way to gain confidence in SC6 for any proposal. Marc Cohn felt that the crux of the problem was moving the service definition separately from protocol work. We should try to find compromise. What are we going to do with ECFF as a NB - scrap it and do just multicast, or continue it? Lyman suggested that maybe we should gear the multicast thread to discuss that? Jim Moulton opposed that idea. Lyman stated that we will not go to Seoul without resolving that question; however, we have such a small group at this meeting that any decision may not stick. A suggestion was made by Marc Cohn to keep multicast and efficiency together; after all, multicast is the primary efficiency mechanism. We should try to resolve technical differences and move forward. Jim Moulton noted that in multicast there is not one solution for everyone. Doubt we will be able to combine the two and have something out of the June meeting. Lyman warned the group that we have to be careful what we progress, because we are already on the edge. Steve Anderson was concerned that if we don't keep multicast and efficiency together we will have multiple amendments which will get us no where. Any multicast which results from the combined work will have degenerative modes which will cover all modes of operation. Steve felt that for Seoul, we should input an architecture document and comments against N7445. It is too late to have a mutually agreed meta service definition. Before we entertain any proposals, we need to get our act together. Doug Montgomery noted that, for Seoul, we shouldn't send paper just to send paper. Let's not loose site of the connectionless work; let's finish this and there will be multicast in OSI! Then we can take our time to carefully decide which proposals we want to send forward. Marc Cohn jumped in and stated that the world is dominated by TCP/IP, OSI isn't here because we don't provide anything over and above what the Internet offers. This is our chance to do something new and lead. Lyman cautioned him that this is precisely one of OSI's problems. We try to jump ahead and not recognize what already exists and works. We don't listen to the research community, the implementors, and industry. There was consensus out of London on the 3 issues: QoS, efficiency, and multicast. Marc Cohn felt this meant there was consensus to pursue a combined effort. He stated that he was NOT tied to HSTP, it was just a starting place. Lyman countered with the fact that there is wide spread consensus that if you are going to add anything to Transport, just add multicast. Jim Moulton stated that he agreed with Steve! Just send an architecture document and comments on the service definition. Lyman cautioned that wouldn't frame the question sufficiently enough to have a productive meeting in Seoul. The issue of modifying existing standards was raised by Dave Marlow. The proposals on the table are all heading toward a specific multicast solution. How do we define what should go forward? Maybe it's not bad to take four proposals forward and just let SC6 know these are all points in the solution space and see what NBs are interested in. We should have no problem discussing all the proposals in Seoul; just let them know what the U.S. is looking at. Agreed for Seoul: ~ Network Layer Multicast ~ CL Transport Multicast (8072/8602 + PICS - US should support NP in Seoul) ~ CO Transport multicast: sufficient agreement to have U.S. position that there should be a CO Transport multicast - we disagree on the semantics new capabilities: have identified some of the things that this might be (in U.S. and elsewhere) ECFF ------------------------------------> new features | - - - - - - - - - - - - - - - - - - - - - | +---------------> multicast After drawing the above figure on the flip chart, Lyman stated that there was reason to draw a line (between new features and multicast) and say that multicast is something that should be done and new capabilities are things that need to be researched. No consensus on what the new capabilities are and if they are ready to be standardized. Steve Anderson jumped in to say that there are people who support that there needs to be more than just multicast work going on. In London there was almost an NP approved to start this work. And besides, the French are trying to start a NWI on efficiency. We have to decide if we are going to support this work. After the work starts, we can decide what the actual services will be. Then Dave Marlow asked, what will we do if we have an NP to look at new services? Will we vote No? It's not are there enough advocates to do the work - it's are there enough advocates working against it. (There are enough people working against doing work on new services.) Lyman suggested that if the two were split and both had NPs, there would probably be no problem pursuing them in parallel. Steve Anderson argued that HSTS is based on a real product which has trial implementations, so it's not just a research problem. But Lyman noted that there is no consensus as to if they need to exist in a Transport protocol. Dave Marlow felt that there are more research questions in CO multicast than in the new services. It's not a question of research in these areas -it's a question of should it be standardized. Research means what should be the next evolutionary step for a Transport protocol stated Lyman. Kevin Thompson didn't agree that CO Transport multicast was a research problem, only parts are. What ever happened to the 4 step process? Lyman answered by saying that it's not gone, it's a political process to convince several NBs that you really need to do work on something. It's not a plan for submitting projects, it's a plan for doing our homework to convince people of new work. Jim Moulton suggested that we do both in parallel with the provision that they will reach PDAM or DIS ballot at relatively the same time. Then fold them together at the end. Lyman stated that was disingenuous - it wouldn't happen. There are more people that want to see multicast solved, even if it's a harder problem. Multicast will progress faster than new capabilities. Marc Cohn disagreed that they are separate. QoS and efficiency will drive the new capabilities. We aren't going to escape solving QoS for multicast, so why not solve it for the hard case? Lyman noted that there is historical precedence to not solve QoS. Dave Marlow jumped in as said that he was at the ECFF meeting in London. The other contributions from NBs were mostly new capabilities, not much pure multicast. Most NBs wanted new capabilities. So do we have to split them off today? The French want both; why not wait until Seoul and see what other NBs want to do. Why should the U.S. drive the boat in separating the two? We could participate but not serve as editor for them. The other proposals are interesting but less real than what the U.S. is proposing. There is very little chance that the other proposals will ever be real products. They're just government funded research/academic projects. Jim Moulton felt that for Seoul, he didn't think there was any chance of pursuing a project where multicast and new capabilities were combined. There are two camps with differing opinions which can't be resolved. A silent member of the group spoke up. Bill Goodrick stated that he didn't know how we can do anything without structure. There are two views, why not let them go their separate ways? We aren't going to make any progress like this, keeping them together. Lyman noted that it would work if there weren't procurement consequences down the line. Any decision we make will have a definite impact on what we are going to pursue long term. Again, Steve Anderson spoke up to say that there was not a consensus that everyone wants CO multicast. There are two proposals which do not depend on any other mechanism and would rather not be linked to efficiency, stated Jim Moulton. We would like to be convinced that any new combined work would allow multicast to progress unencumbered from efficiency. Lyman now believes that pure CO multicast will not garner enough momentum to progress quickly (exact mirror or efficiency problem). Jim Moulton continues by saying that multicast is a part you can carve out and make progress on. It will not influence any work in new capabilities area. Do something that is widely applicable and of general use suggested Doug Montgomery. Doesn't believe that there is a dire need for CO multicast, so why split the work? Can't understand how the work will proceed if it splits and doesn't see the need to split it. Would rather see us progress an architecture document. We may very well be dead in the water anyway. Steve Anderson commented that if the CO transport service ended up as multicast only, he would rather see extensions to existing services rather than a new protocol. In principle, it probably wouldn't be different from TP5 but more along the lines of TP4 extensions. Approval of Output Documents and Ballot Responses: 93-196 (Comments on NP Ballot 8473 extensions) Yes with project editor Lyman Chapin 6 Yes 7 No with comment that timestamp is under specified. 93-202 (Comments on 8348/PDAM 7) Yes with comments 93-203 (Comments on 8473/PDAM 7) No with comments 93-205 (Comments on 9542/PDAM 2) Change "is required" to "shall"; add Lyman's text (modified in real time). Yes with comments 93-206 (Comments on 11577 - NLSP) (NLSP)/combines CO and CL too much. Hughes Aircraft comments (15H and 14H) are out because no real savings. There may be additional comments, but will all be minor; X3S3 will then decide if additional comments will be accepted. No unless majors are changed. 93-207 (Comments on 10736/DAM 1) No unless major comments resolved. 93-208 (Comments on N7951) 14H (Hughes Aircraft comment) is gone since out of 93-206; add major comment. No unless major comments resolved. 93-209 (Comments on Defect Report 10733/003) Response to 93-132. Yes with comments. 93-18 (Minutes of 174th X3S3.3 Meeting in Menlo Park, CA - January 5-7, 1993) Approved as written. 93-153 (Minutes of the Multicast Workshop in Arlington, VA - April 7-8, 1993) Approved as written. The members of task group 3 would like to express their appreciation to Mr. Ed Taylor for serving as vice-chair for 3 years. The meeting was adjourned at 12:00 PM.