I have been on several design teams over the years, such as one that produced the MPLS Architecture (RFC3031), and a different one that produced the L3VPN Framework Document (RFC4110). In each case the design team was ended when an early draft of the document had been produced and submitted to the working group. Once an Internet Draft is accepted as a WG document, then the document "belongs" to the WG, in the sense that the document gets updated based on WG consensus. In fact, in the rare situation that a document author refuses to make changes to a WG document in violation of clear WG consensus, then the WG chairs have the authority to remove the author and put in different authors. This is just normal IETF process. Thus closing a design team when its work has been completed (which means that an initial draft has been submitted to the WG) is normal IETF process. The work continues in the WG (as happened in this case). Ross -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of John E Drake Sent: Friday, March 04, 2011 10:01 AM To: Brian E Carpenter; Russ Housley Cc: IETF Subject: RE: My comments to the press about OAM for MPLS Hi, I think we should be sad, though, that Huub's feelings were hurt when the team was disbanded. Here is the liaison to the ITU describing the disbanding of the design team: https://datatracker.ietf.org/liaison/593/. Interestingly, I can't find a reply from the ITU. This implies they didn't consider it important at the time. The design team report (http://www.ietf.org/proceedings/75/slides/mpls-17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day. I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): "The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU-T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure. These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP... The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness." Thanks, John Sent from my iPhone > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > Brian E Carpenter > Sent: Thursday, March 03, 2011 12:05 PM > To: Russ Housley > Cc: IETF > Subject: Re: My comments to the press about OAM for MPLS > > On 2011-03-04 06:51, Russ Housley wrote: > > Nurit: > > > >>> Not to mention including the canard that the IETF unilaterally > disbanded > >>> "its group assigned to work with ITU" in 2009. Others with more > detailed > >>> knowledge can explain exactly why this is, er, a lie. > >> Here are some facts: > >> =================== > >> I was member of the MEAD team. > >> A meeting of the MEAD team was scheduled to meet in Munich > >> 12-14 October 2009. It was scheduled right after an ITU-T > >> SG15 plenary meeting (September 28 - October 9) because > >> MEAD team members attended that meeting too. > >> > >> On Friday October 2nd an agenda was distributed for the MEAD > >> team for the meeting in Munich on the MEAD team list mead@xxxxxxxxx > >> On Monday October 5th an email was sent to mead@xxxxxxxx > >> announcing the disbanding of the MEAD team, and that the > >> meeting in Munich should not be considered a MEAD team meeting. > >> > >> The decision to disband the MEAD team was liaised to the ITU-T > >> on the same day (October 5). > >> > >> Do I need to say more. > > > > It does not sound like the shutdown of the MEAD team was smooth. > However, the closure of a design team when their output is being > handled by a working group is quite normal. > > That's the point. A design team is always a short term mechanism and > once it > reports back to the WG, it closes down. Not having been personally > involved, I can't judge whether the process was clear to those > involved, > especially people with more experience in ITU-T than in the IETF. > > Just so we are all talking about the same thing, here is the official > description from BCP 25 (RFC 2418): > > "6.5. Design teams > > It is often useful, and perhaps inevitable, for a sub-group of a > working group to develop a proposal to solve a particular problem. > Such a sub-group is called a design team. In order for a design > team > to remain small and agile, it is acceptable to have closed > membership > and private meetings. Design teams may range from an informal chat > between people in a hallway to a formal set of expert volunteers > that > the WG chair or AD appoints to attack a controversial problem. The > output of a design team is always subject to approval, rejection or > modification by the WG as a whole." > > In other words, what counts in the IETF process is the WG consensus, > not the design team consensus. There are cases where the WG refuses or > significantly changes the design team proposal; RFC 3246 and RFC 3248 > make a good example. > > Brian > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf