Re: Draft charter for L3VPN: protocol-specific work

On the following part of the proposed charter:

> As a general rule, the WG will not create new protocols, but will provide
> functional requirements for extensions of the existing protocols that will
> be discussed in the protocol-specific WGs.

we had the following:

   Robert wrote:
   > That is even biggest evil making essentially as ppvpn this new WG
   > useless :).Without at least ability to propose extensions to protocols
   > submitting any serious draft is pointless. If I have to write
   > requirements for myself and submit a solution in IDR I would just go for
   > the latter immediately. Also note that this line is outside of reality
   > of work done in vast majority of all drafts in ppvpn WG. I do hope that
   > this line will also be removed therefor making the ppvnp split really
   > useful in practice

   Rahul wrote:
   > I very strongly second Robert's opinion. Time and again the procedure of
   > defining protocol extensions in PPVPN comes up. And every time the reality
   > is ignored. How about the following:
   >    "The WG may propose extensions to existing protocols and such
   > extensions will be discussed and reviewed by the protocol-specific WG."
   >
   > The question than is: Should a document submitted to the current PPVPN WG
   > (or the new groups if the split happens) be accepted as a WG doc before
   > the protocol specific WG reviews protocol extensions (if any) ? I think we
   > need more discussion on this. There are cases where it makes sense to have
   > such a review before accepting the doc as a WG doc and there are cases
   > where it doesn't.

   Eric wrote:
   > I happen  to like this  sort of restriction,  because it helps to  prevent a
   > situation in  which every  proposal includes an  extension that  is entirely
   > optimized for that proposal.

Here's my take on this:

1. I think I (and the IESG in this case too) would not be comfortable
   with a general approach of extensions to protocols that have
   corresponding WGs not owned by those WGs. Clearly, the expertise and
   the bigger picture of the development of a particular protocol is
   there. So, I think allowing the VPN WGs (or PPVPN) to develop and
   standardize protocol-specific extensions would not be realistic or
   fair to the protocol-specific WGs.

2. The text in the charter actually describes an existing
   situation--we do this in CCAMP--for instance, we have a generic
   routing document describing information that needs to be
   distributed and then we have protocol-specific documents that
   define encoding in that particular protocol. Not extremely
   effective from the CCAMP perspective, but quite fair if we take
   other WGs in consideration.

3. In reality, what we want to achieve is the VPN community being
   able to propose and document extensions to existing protocols
   that would help VPN technology development. Also, before a given
   mechanism goes forward, we need to make sure that:

     a. The VPN community believes that it serves the purpose
        and the right way forward
     
   AND
   
     b. The protocol-specific community believes that using
        the protocol is a good idea and the way this is done
        is correct.

   Given that finally the extension specs have to live in the
   protocol-specific WGs, ow about we use the following process
   (draft):

     1. VPN folks who believe that a given protocol extension
        is needed, come up with an individual draft describing
        the details.

     2. The draft is brought to the appropriate VPN WG. A discussion
        on the mailing list AND in the room is held on the subject of
        why this is needed and whether this is a good idea VPN-wise.
        If there is no agreement on this--the draft does not go
        any further. Otherwise:

     3. The draft is taken to the protocol-specific WG. The WG
        discusses if it is happy with it as a general approach, if
        so takes it as a WG item. Otherwise, the WG chairs summarize
        the discussion and send the summary to the VPN WG.

     4. If the draft is accepted by the protocol-specific WG,
        the appropriate VPN framework document is updated to describe
        it and refer to the doc.

     5. The WG chairs coordinate timing for the draft.
        When ready to go to IESG, the draft is LC'ed in both WGs.

   Comments?

Alex