Subject: RE: Draft charter for L3VPN: protocol-specific work

From: "Paul Knight" <[email-masked]>
Date: Fri, 9 May 2003 18:10:48 -0400

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-masked]] 
> Sent: Friday, May 09, 2003 2:43 PM
> To: [email-masked]
> 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
> 
> 
>

---

From: Alex Zinin <[email-masked]>
Date: Fri, 9 May 2003 15:18:35 -0700

Paul,

> reasonable approach for protocol extensions (whether or not there is a WG

Thanks, we need some positive notes this week ;)

> any last-minute objections from people not following the mailing list can be

I think this goes to the area of 'how do we gauge consensus?'
It would probably be too much for this list to take this topic now :)
However, generally, I think that just a discussion on the mailing
list or just a discussion at a face-to-face meeting are not enough,
we need both.

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

Most probably, but I think it would probably be hard to come up
with a universal definition, so maybe we should leave this to
the judgement of WG chairs and ADs. To answer your particular

> I'm assuming that this procedure would apply to:

I'd say yes

> - New message types, payload types, type codes

I'd say yes

> - New enumerated values in existing attributes or protocol messages

I'd say no, provided that the semantics of the fields are not
changed, but this may very well depend on each particular case.

Thanks.

Alex