RE: Draft charter for L3VPN: protocol-specific work

Hi Alex,

To go into the weekend on a positive note, this looks like a pretty
reasonable approach for protocol extensions (whether or not there is a WG
split).

However, in the interest of saving time in the meetings, perhaps there
should be some provision for allowing consensus on a proposed protocol
extension to be reached just on the mailing list, so we don't require a
presentation and discussion of each one in the meeting.  Maybe there could
be a slide with a list of the "pre-approved" extensions in the meeting, so
any last-minute objections from people not following the mailing list can be
heard.

Also, are there gray areas in the definition of "protocol extensions" ?

I'm assuming that this procedure would apply to:
- New attributes
- New message types, payload types, type codes
- New enumerated values in existing attributes or protocol messages
- ?

Regards,
Paul

> -----Original Message-----
> From: Alex Zinin [mailto:[email protected]] 
> Sent: Friday, May 09, 2003 2:43 PM
> To: [email protected]
> Subject: 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
> 
> 
>