Re: WG split: why and how?

Don,

> Alex
> 
> You have missed some important facts here.  There were other VPN BoFs 
> that were unsuccessful. It was very tough just to get a VPN WG going.  
> Early efforts to keep the VPN space small and focused were unsuccessful. 
> L2VPNs have a symbiotic/parasitic relationship with  L3VPN technology. 
> The wide scope of VPNs is the nature of the beast.  
> 
> What I find disturbing is the process of this split logic is superficial 
> and the reorganization is rushed. 

Agreed.

>                                  How much time have you spent with 
> stake holders trying to address the current issues?  Communication 
> between the ADs the IESG and the WG chairs and the members is perplexing 
> from my standpoint.   

Agreed.

> I suggest it would be more fruitful to spend time 
> from now to Vienna advancing current work and seeing what is holding up 
> the rest.  Lets get this train back on the rails before, if necessary, 
> we split the tracks.

I think this is a very reasonble proposal.

Yakov.

> 
> Don
> 
> 
> Alex Zinin wrote:
> 
> >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
> >
> >  
> >
> 
> 
>