Subject: Discussion of closure of the MEAD Team

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 6 Oct 2011 16:01:08 +0100

Hi,

Since this topic has diverged somewhat from the IETF last call on
draft-sprecher-mpls-tp-oam-considerations, I have changed the subject line.

> 2.  For MEAD team's decision on OAM, it was recorded in
draft-ietf-mpls-tp-oam-
> analysis as below, but some MEAD members don't agree it, so they quit from
this
> draft, you can see change from draft-ietf-mpls-tp-oam-analysis-00 to
draft-ietf-
> mpls-tp-oam-analysis-02.
> 
> "This document reports the conclusions of the MPLS-TP design team
>    discussions on the MPLS-TP OAM tools at IETF75 and the guidelines
>    that were agreed.  The guidelines refer to a set of existing OAM
>    tools that need to be enhanced to fully support the MPLS-TP OAM
>    requirements and identify new tools that need to be defined.  The
>    organizational structure of the documents on MPLS-TP OAM tools was
>    also discussed and agreed at IETF75 and is described later in this
>    document."
> 
> 3. For MEAD team's disband, you can see liaison send to itu recorded in TD218-
> wp3 (2009-9).

You say that some members of the MEAD team did not agree with the recorded
decision of the team and quit from the draft. They might have done better to
disagree with the draft and to have discussed their concerns on the MPLS working
group mailing list. But the main point is that one of the key problems with the
MEAD team at this stage was that the discussions were private and did not allow
in a wider community opinion of the work. As was complained a number of times,
the MEAD team was established to kick-start the work, but was continuing to
develop the solutions outside the working group. In practice, had the MEAD team
continued any further it would have acted to exclude other participants - in
particular it would have prevented participants from the ITU-T from having their
fair input through the MPLS working group mailing list. I am sure you agree that
that would have been bad. Indeed, you complained in a previous email that
decisions had not been explored in public, so the implication is that you really
appreciate the closing of the team.

IETF participants will more easily find the liaison you refer to at
https://datatracker.ietf.org/liaison/593/

You will note, on reading this liaison, that the reasons given at the time were
to specifically to ensure rapid progress and open discussion.

This liaison should make it clear to you that the team was closed by the Area
Directors and the MPLS working group chair responsible for the team. The team
did not (as you suggest in a previous email) disband itself.

I am aware that there are comments that an IETF design team should not have been
shut down without consent from the ITU-T. I find, however, that when the ITU-T
agreed to develop MPLS-TP in cooperation with the IETF within the IETF and using
IETF process, it is only to be expected that IETF design teams are managed
according to normal IETF practice.

Thank you,
Adrian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Oct 2011 08:24:14 +1300

On 2011-10-07 04:01, Adrian Farrel wrote:
...
> according to normal IETF practice.

At the risk of wading even further into muddy waters, I would like to
underline that Adrian is indeed describing normal IETF practice and that
this practice is specifically intended to ensure openness and transparency.

I want to mention an older example that occurred when I was co-chairing
the diffserv WG. It didn't involve a second SDO but otherwise it was
quite similar. We had RFC 2598 (a proposed standard). We had people in
the WG who claimed that it was underspecified and inaccurate. There were
diverging views about how to fix this, so we set up a design team. The
design team came up with a proposed update, but there were still
diverging views. So the issue was brought back to the WG as a whole.
The result was two RFCs: RFC 3246 (a proposed standard that obsoleted
2598) and RFC 3248 (an informational document describing the rejected
alternative, for the record). As a matter of fact, RFC 3248 describes
the design team proposal, which is the point of my story. The design
team process is *not* what counts; it's rough consensus in the open
WG discussion that counts.

When ITU-T agreed to work in the IETF process, they agreed to that.

   Brian