Re: Draft charter for L3VPN: protocol-specific work

Paul,

> 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).

Thanks, we need some positive notes this week ;)

> 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.

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
questions:

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

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