Re: Process on open RFC2518bis issues

Unfortunately, this proposal would violate that idea that a WG needs to
determine that at least rough consensus exists within the WG for the
advancement of a document. It would change to where there was not consensus,
then we defaulted to what RFC 2518 says.

On 1/11/06 9:03 AM, "Geoffrey M Clemm" <geoffrey.clemm@us.ibm.com> wrote:

> 
> I don't think there is any communication problem,
> I believe we just disagree on the appropriate way to resolve
> the remaining disagreements in a limited time.
> 
> One way to do so is to play a game of "chicken" ...
> set up the situation in which unless one party to each
> disagreement gives in by the specified time, something
> severely negative results (e.g. all the work on 2518bis
> is wasted and no revision of 2518 is published).
> 
> Another way to achieve agreement is to instantiate a rule
> that depends only on the facts of the issue, and not on the
> personalities of the participants.
> 
> I believe Julian has proposed a sensible rule for this
> situation that will produce a superior result (and be less
> stressful on the participants) than would the game of chicken.
> 
> Cheers, 
> Geoff 
> 
> Cullen wrote on 01/11/2006 11:36:08 AM:
>> > 
>> > Somehow, we continue to seem to miscommunication - perhaps we are saying >>
the
>> > same thing
>> > 
>> > On 1/11/06 5:08 AM, "Geoffrey M Clemm" <geoffrey.clemm@us.ibm.com> wrote:
>> > 
>>> > >  and therefore any change to RFC2518 should by
>>> > > default be rejected unless there is at least consensus
>> > 
>> > Let me comment on this in the simplest form I can.
>> > 
>> > If bis is includes change A, yes we will need consensus for that change.
>> > 
>> > If many people think that bis should include some other change X to clarify
>> > a problem/confusion seen with 2518 but bis does not include that, we will
>> > need consensus that bis does not include X.
>> > 
>> > We need consensus on the document. Now to get to consensus, yes I encourage
>> > the WG not to add new features, and not to be shy about removing features
>> > that don't work.
>> > 
>> > 
>> > 
>> > 
>