Re: [Gendispatch] Thoughts on draft-carpenter-gendispatch-draft-adoption

["Joel M. Halpern" <[e-mail]>]

We may be disagreeing, as we did in an earlier email on a different 
thread, about the meaning of WG adoption.
As I understand it, WG Adoption represents the WG agreeing that a given 
document is a good starting point for working on solving a specific 
problem that the WG wants to work on.

The formation of a chair-appointed DT probably does represent some 
agreement that there is interest.  It does nnot represent that the WG 
agrees that the DT output is a good starting point.  It is indeed hoped 
that the result will be one the WG can adopt.  But the DT does not get 
to assume WG agreement.

It is based on the above meaning for adoption that I object to a process 
implication that a DT can force WG adoption of their result.

Yours,
Joel

On 7/22/2020 4:40 AM, Adrian Farrel wrote:
> Michael,
> 
> I think what you are saying (or what we should agree upon) is that different
> WGs run their work differently. It would be a shame, IMHO, to mandate the
> micromanagement of WGs to this level. IOW, sometimes the draft would get
> implicitly adopted, sometimes the chairs would adopted it by fiat, sometimes
> the WG would discuss it before adoption: leave it up to the chairs to decide
> how to run each situation with different DTs in different WGs.
> 
> Making it clear to the chairs and participants what the options are is
> helpful to smooth and flexible operation - this is what we were trying to do
> with RFC 7221. Making tight micro-rules constrains "doing the right thing".
> 
> Best,
> Adrian
> 
> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: 22 July 2020 02:58
> To: [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: Thoughts on draft-carpenter-gendispatch-draft-adoption
> 
> 
> Adrian Farrel <[e-mail]> wrote:
>      > In this draft you have (section 3)...
> 
>      > A WG that decides to create a design team to solve a
>      > problem has implicitely agreed to adopt the result.  To not adopt the
>      > result is to say that the results of the WG mandated design team does
>      > not deserve first class agenda time.  Such a design team would have
>      > been created, for instance, when a WG can not decide between two
>      > competing individual drafts and decides to merge them.
> 
>      > s/implicitely/implicitly/
>      > s/can not/cannot/
> 
> (fixed in my copy)
> 
>      > But I strongly disagree with this statement. I think that the DT is
> (very)
>      > often chartered to come up with a draft for the WG to consider
> adopting. If,
>      > however, as is somewhat common, the DT goes a little wild and produces
> a
>      > document that the DT likes but the WG finds unacceptable, then the
> document
>      > should not be adopted.
> 
> I guess I disagree about the mechanicals of the process.
> I really think that the DT should be charged with uploading it's work as
> draft-ietf-foobar-00.txt
> If the WG hates the result, then the DT can be fired and a new one created.
> 
> Adoption is not endorsement.
> 
>      > I would go as far as to say that sometimes there is an expectation
> that the
>      > output of a DT will be presented to a WG as a done decision that the
> WG must
>      > accept because "the WG chartered the DT". But a DT is "just a group of
>      > people working together on a draft," and the fact that the WG
> chartered a DT
>      > merely means that the WG helped form the group of people.
> 
> I agree totally, but the WG created the design team.
> If we do agenda time correctly, then the DT might get none.
> 
>      > The sentence about the "first class agenda time" also seems wrong.
> Yes, the
>      > output of the DT deserves agenda time, but if the use of that time
> reveals
>      > that the result is not up to scratch, that is good use of time and the
> draft
>      > should not be adopted.
> 
> If it deserved agenda time, then adopt it.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks
> [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect
> [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails
> [
> 
> 
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
> 
>