Re: WG split: why and how?

Folks-

As promised (though 11:40-ish my time), I tried to quickly bring
together information that would clarify some confusion I noticed
during the discussion about the work split. I also tried to come up
with answers to questions that I thought might be interesting.

Hope this is helpful.
Regards.

Alex



1. Procedural background:

 1.1 Relevant quotes from RFC 2418:
 
    Section 2:
    
    a) "...A working group may be established
        at the initiative of an Area Director or it may be initiated by an
        individual or group of individuals."

    b) "Working groups are typically created to address a specific problem or
        to produce one or more specific deliverables (a guideline, standards
        specification, etc.).  Working groups are generally expected to be
        short-lived in nature."

    c) "Upon completion of its goals and achievement
        of its objectives, the working group is terminated. A working group
        may also be terminated for other reasons (see section 4)."

        Section 4:

       "If, at some point, it becomes evident that a working group is unable
        to complete the work outlined in the charter, or if the assumptions
        which that work was based have been modified in discussion or by
        experience, the Area Director, in consultation with the working group
        can either:

        1. Recharter to refocus its tasks,
        2. Choose new Chair(s), or
        3. Disband.

        If the working group disagrees with the Area Director's choice, it
        may appeal to the IESG (see section 3.4)."

    d) "The formation of a working group requires a charter which is
        primarily negotiated between a prospective working group Chair and
        the relevant Area Director(s), although final approval is made by the
        IESG with advice from the Internet Architecture Board (IAB).  A
        charter is a contract between a working group and the IETF to perform
        a set of tasks."

 1.2. WG split is not covered in 2418

    From the process perspective, splitting of PPVPN work is
    considered as 1) termination of the existing WG, 2) formation of
    the new WGs, and 3) relocation of the WG documents to the new WGs.

2. Data about PPVPN WG:

    BOF'ed                    : Pittsburgh, Aug 03, 2000 (NBVPN BOF)
    1st meeting               : San Diego , Dec 14, 2000 (PPVPN BOF/WG)
    WG drafts                 : 17   (as of May 09, 2003)
    Submitted to IESG         : 3 (L3 framework, L3 reqs, generic reqs)
    Approved, in RFC-ed queue : None (as of May 09, 2003)
    RFCs published            : None (as of May 09, 2003)

3. Problem statement.

   As seen by ADs: slow progress on L3 and L2 VPN work (see section 2
   above) caused by comparatively wide problem space with unusually
   big number of correlated technologies (L2, bridging, tunneling,
   routing, signalling, etc.) that in turn results in a big number of
   tasks and documents within the WG. Overloading of the WG resources
   (management cycles, mailing list, and face-to-face meeting time)
   causes slow progress on the existing WG documents that (because of
   the number of incomplete items) keeps continuing VPN technology
   developments outside the WG and makes the process within the WG and
   its results less relevant to the community and the industry. Unless
   addressed, the situation is expected to get only worse.

4. Summary of the solution under consideration

   1. Put L3 and L2 work in separate WGs
      Analysis of the L3 and L2 remaining and potential future work items
      has shown that there is a sufficient amount of work in each area to
      warrant a separate WG. Smaller and more focused WGs tend to be
      more efficient in terms of achieving consensus and completing
      their tasks.

   2. Focus the charters to ensure progress on items already in
      the pipe; expand the charters and add more work items as
      things progress

5. Goal of the discussion on the list

   Collect community feedback on the solution and the charters of
   the proposed new WGs.

6. FAQ

6.1 How is relocating the work to the Internet area related to
    the described problem and the proposed split?

    It is not. Relocation of the VPN work to the Internet area
    is an independent action. However, since the question of
    reorganizing the work is being considered, it is logical to
    do the move at the same time.

6.2 Does the IETF process require consensus within the WG on the problem
    statement and/or the proposed solution?

    Formally, the ADs or the IESG do not need to obtain WG consensus
    on forming, disbanding, splitting a WG, or any other WG management
    actions. However, it is normal for the ADs and the IESG to consult
    the community before making the decisions. This is what happened
    before the discussion was started and essentially what is
    happening on the list now.

6.3 Have you made the decision already or are you still open to
    feedback from the community?

    We came to the WG with a strong opinion that a split is needed,
    however, the decision has not been made yet and we are open to all
    opinions.

6.4 If the decision has not been made yet, why did you start the
    discussion on the charters of proposed new WGs?

    This was done to make sure the community has enough information
    to understand what the results of the split would be, and to
    collect feedback on the charters themselves.

6.5 What would happen to the documents that span both L2 and L3
    VPN areas?

    They would be put in one of the new WGs.

6.6 How would you ensure coordination between the two VPN groups?

    Coordination between different WGs is a well-known task and is
    usually accomplished through direct communication of the WG
    chairs, ministration by ADs, and by formation of technology-
    specific directorates. Formation of the VPN directorate is being
    considered.

6.7 Have you considered other alternatives to the split?

    Yes. The alternative to the split would be to organize work within
    the WG in the form of design teams and have more than one WG
    session at the face-to-face meetings. However, the WG already has
    a number of DTs inside of it, so we can consider that this method
    has been tried already. Increasing the number of WG sessions alone
    is hardly going to help as majority of work is done outside the
    face-to-face meetings, in fact, consistent need for more than one
    session maybe considered as an indication that the WG has more
    than enough on its charter.