----- Original Message -----
From: "Ross Callon" <rcallon@xxxxxxxxxxx>
To: "John E Drake" <jdrake@xxxxxxxxxxx>; "Brian E Carpenter"
<brian.e.carpenter@xxxxxxxxx>; "Russ Housley" <housley@xxxxxxxxxxxx>
Cc: "IETF" <ietf@xxxxxxxx>
Sent: Friday, March 04, 2011 6:28 PM
> 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).
I think it misleading to call MEAD a Design Team (whatever the acronym stands
for).
As described in, e.g., draft-andersson-mpls-tp-process
" o MEAD team (MPLS Interoperability Design Team): a temporary team
with participants with experience of standards development for
MPLS and transport networks. The MEAD team is chartered to
coordinate the development of MPLS-TP within the IETF and to
coordinate the cooperation between the IETF and the ITU-T"
which goes on to say
" o MPLS-TP document - the following documents count as MPLS-TP documents:
* Internet Drafts that are coordinated by the MEAD team.
....."
and
" Once a document
has become a Working Group document, consensus is decided by the
WG chairs and the MEAD team chair jointly."
MPLS-TP modifies the IETF processes to give a greater say to
ITU-T in such matters as comments, consensus and last calls so it matters
what constitutes a MPLS-TP document, to which one answer
is whatever MEAD considers to be an MPLS-TP document.
(Those not so considered could then go into an IETF
Working Group which followed regular IETF processes).
Coming with an IETF background, I found this an abomination
and was relieved when MEAD disappeared.
That said, the issue at hand is not, IMO, the MEAD team. It is the
standing in the IETF and in the ITU-T of
draft-bhh-mpls-tp-oam-y1731-06
Those familiar with IETF processes will know from its name the standing of
this I-D within the IETF in general, and in MPLS in particular. Those
not familiar have been enlightened by the recent, clear and careful
liaisons of Stewart Bryant to the ITU-T. This is what the ITU-T
seem reluctant to accept.
The discussion of the merit of the approach in this draft has been just
as energetic since MEAD was disbanded as ever it was.
Tom Petch
> 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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf