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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 21 Jul 2020 23:47:49 +0100

Hi,

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/

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. 

While it is true that the WG can rewrite all of the document once adopted,
it must be understood that there is a certain stickiness to fundamental
ideas that are contained in adopted documents (the details may be changed,
but the main thrust is much harder to change).

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.

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.

Thanks,
Adrian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jul 2020 13:51:37 +1200

fwiw, this co-author partly agrees with you. I think it's fair to say
that a formally designated design team would be expected to produce
a WG draft but I think the text you quote goes too far.

Just to quote the relevant bit of RFC2418 (a.k.a. BCP25):
"Design teams may range from an informal chat
 between people in a hallway to a formal set of expert volunteers that
 the WG chair or AD appoints to attack a controversial problem.  The
 output of a design team is always subject to approval, rejection or
 modification by the WG as a whole."

So we need to tune the text you quoted to be compatible with that.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 21:58:18 -0400

> s/implicitely/implicitly/

(fixed in my copy)

    > document that the DT likes but the WG finds unacceptable, then the document

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.

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

    > that the result is not up to scratch, that is good use of time and the draft

If it deserved agenda time, then adopt it.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Jul 2020 22:15:30 -0400

I strongly disagree with the text below about a WG automatically 
adopting a DT result.
The DT is not the WG.  It is not acceptable, in my view, for the DT 
product to be automatically adopted.  In the two current cases I am 
involved with, it would be very bad, as it is clear that the purpose of 
the design team is to create a proposal which the WG can then review to 
see if it (the WG) agrees that it is a good starting point.  (And yes, 
both DTs are chair-appointed DTs.)

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jul 2020 15:35:20 +1200

Let's stipulate that this paragraph of the draft needs to be rewritten.
What does it need to say beyond what is said in RFC2418 (quoted in
my previous message)?

Regards
   Brian Carpenter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Jul 2020 00:18:04 -0400

Personally, I like the text in 2418 about design teams.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Jul 2020 09:17:20 +0100

I agree with Joel. So we might jump two ways...

1. Simply remove the text about the DT (that is, the text I quoted)
2. Replace the quoted text with something like...
   A working group may set up a design team to solve a specific
   problem, and the design team may produce Internet-Drafts.
   The standing and operation of design teams is described in
   [RFC2418], and the drafts that they produce are candidates
   For adoption as working group drafts subject to the same
   Considerations as any other draft.

Ciao,
Adrian
-----Original Message-----
From: Gendispatch <[email-masked]> On Behalf Of Joel M.
Halpern
Sent: 22 July 2020 05:18
To: Brian E Carpenter <[email-masked]>; Michael Richardson
<[email-masked]>; [email-masked];
[email-masked]
Subject: Re: [Gendispatch] Thoughts on
draft-carpenter-gendispatch-draft-adoption

Yours,
Joel

-- 
Gendispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gendispatch

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Jul 2020 09:40:04 +0100

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 <[email-masked]> 
Sent: 22 July 2020 02:58
To: [email-masked]; [email-masked];
[email-masked]
Subject: Re: Thoughts on draft-carpenter-gendispatch-draft-adoption

(fixed in my copy)

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.

--
]               Never tell me the odds!                 | ipv6 mesh networks
[
]   Michael Richardson, Sandelman Software Works        |    IoT architect
[
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails
[

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Jul 2020 09:09:43 -0400

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Jul 2020 10:34:30 -0400

> how to run each situation with different DTs in different WGs.

I agree with these goals.

    > with RFC 7221. Making tight micro-rules constrains "doing the right thing".

I would be satisfied if the result was that I could tell via symbol, set of
colours, or reference to a subsection of a document, how a particular WG
behaves.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Jul 2020 15:44:15 -0500

The text in this document should not (really, must not) constrain the 
group to automatically adopt _anything_.

I have seen groups set up two teams to refine separate proposals with 
the intent that the group weigh the results against each other. 
Automatically adopting the output of both of those teams would have 
created confusion and increased friction.

RjS

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2020 12:28:42 +1200

> created confusion and increased friction.

True.  I'm thinking that the main point is that a formally appointed
DT (not an informal self-starting DT) can reasonably *expect* their
output to be adopted, but cannot assume it.

fwiw, RFC3248 is a design team output that was published for the
record, but the WG standardised RFC3246 instead. Anything can happen,
and probably will.

   Brian

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Jul 2020 15:06:59 +1000

> output to be adopted, but cannot assume it.

There might be an assumption here, and I'm sure that in most cases a draft that is the product of a formalized DT will be adopted.  But it's a bad assumption.

The only true measure here is that the WG has consensus to adopt.  I'm surprised that the draft doesn't put that up front.  It's there, but buried.  Given that this is the yardstick that has been uniformly used - at least in my experience - I think it would be remiss not to mention it.

BTW, I think that the general concept is fine, just not this DT point.

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jul 2020 03:05:23 -0400

On 7/22/20 8:28 PM, Brian E Carpenter wrote:

> DT (not an informal self-starting DT) can reasonably*expect*  their

IMO even this states it a bit too strongly.    IMO a DT should not be 
used as a political tool to convince a WG to adopt a particular document 
or documents.  So there should be no presumption whatsoever that a DT's 
output will be adopted.   It should be treated as a proposal, nothing 
more, and alternative proposals should be welcomed.

More generally, I have often seen the "adoption of a draft" question as 
an undesirable short-circuiting of the IETF process, as WGs often seem 
to be asked to adopt a draft before there's any shared sense of the 
problem or the potential solution space.   I have a similar view of the 
practice of naming a draft in a WG's charter as the presumed starting 
basis of the group's output.

I understand why WG chairs and IESG want to avoid having WGs wander 
around, seemingly aimlessly, struggling to find a common direction.   
But I don't think early adoption of a draft by a WG serves the Internet 
community most of the time.   I'd rather see a discussion period 
followed by an invitation to people to submit proposals, with the 
understanding that the WG may want to combine 2 or more of the proposals 
rather than pick a clear winner.

Keith

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jul 2020 07:34:07 -0300

> how to run each situation with different DTs in different WGs.

I don't think the intent is to micro-manage, but rather to set 
constraints, and establish a common ground.

Recently I have seen the following as part of adoption calls:

* Folks arguing support/not support with a different understanding of 
what adoption actually means

* Chairs rejecting to do a wg call for adoption as a result of the 
personal opinion about a document

* Documents being adopted without a consensus call on the mailing list 
(and no previous action item in the charter or anything)

...and quite a few others.

Yes, when everything works as expected, it might seem that specifying 
stuff is unnecessary or even undesirable. But in other cases, it may 
become evident why not setting a common-ground, common expectations, and 
constraints within which the wg needs to operate becomes evident.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2020 13:20:14 -0400

Fernando Gont <[email-masked]> wrote:
    > * Documents being adopted without a consensus call on the mailing list (and
    > no previous action item in the charter or anything)

Chairs *ARE* allowed to do this according to the current guidelines.

Many chairs and many participants don't know this.
It's something that I want to preserve.
I would further say that the Adoption Call is just the chairs asking for
objections before just adopting a document.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Jul 2020 14:10:36 -0400

My understanding of WG document adoption is a stronger statement than 
"no objection".
First and foremost, it is an agreement by the working group that the 
given document is a (not "the", but at least "a") good place to start 
working on the topic.
Second, when I as chair run such a call I expect to see enough interest 
that I believe the working group will work on the document.

As far as I know, those expectations are the (to a reasonable 
approximation) the communities expectation for the meaning.

Yours,
Joel

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 24 Jul 2020 09:54:48 +1000

> Chairs *ARE* allowed to do this according to the current guidelines.
...
> It's something that I want to preserve.

Could you say a little more about why?  For me, chairs have significant, but indirect, power over what is adopted.  Why allow specific, direct power?

As Joel says, adoption is a strong statement that has an established meaning.  For me, going directly against that requires similarly strong justification, precedent or no.