Subject: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Mon, 03 Feb 2020 22:14:20 -0800

Adam Roach has entered the following ballot position for
charter-ietf-add-00-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-add/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

No objection to external review, but I think there are some issues
that are likely to come up in that review that we can work to head
off now. If we don't, then we'll probably end up with a less-than-
productive working group.

I'll start by stating the obvious: the problem space that this working
group is establishing itself in is incredibly contentious, and finding
consensus on just about anything in this space has been elusive. Because
of this, I think we need to take special care to scope the work in a way
that keeps it off of the highly disruptive "third rail" topics that
have plagued conversations to date.

I can appreciate that the charter has undergone many iterations to arrive at
its current form, but still think that the working group would be well served
by some additional tightening up of the description of the deliverables.

Based on Tommy's most recent explanations of the intention of the three
cited deliverables, I would like to propose some re-scoping for the
purpose of making success more likely.

> - define a mechanism that allows clients to discover DNS resolvers,
> including encrypted DNS servers, that are available to the client
> either on the public Internet or on private or local networks;

Branching out to solved problems, like generic DNS resolver discovery,
seems like it's carving out a much larger space than this working group
is intending to address. If the notion is to develop, say, a replacement
for DHCP or RA messages, then this phrasing makes sense. But if that's
the case, then I think we need to have a pretty serious conversation
with the associated protocol stakeholders in the INT and RTG areas.

Yes, I know that's not the intention, but it's what the words literally say.
We should make them say what they mean.

Based on the recent on-list conversation, I'm pretty sure the intention
here is to describe how a client can transition from knowing how to
contact a DNS server over an unencrypted channel to knowing how to
contact it over an encrypted channel. I *think* we can capture this
with something more along the lines of:

- define a mechanism that allows clients to discover how to contact
  known DNS resolvers over an encrypted channel, including resolvers
  provided by the local network, by a public DNS provider, or by way
  of an access technology like a VPN.

The second bullet seems good to me, although I do take EKR's point that
breaking these up into two deliverables does seem to prejudge the outcome
in a way that may not be useful. It might alleviate concerns if the second
bullet debiased this with a phrase like "...a mechanism, which may or may not
be the same as the mechanism mentioned above, ..."

> - develop an informational document that describes how client
>   applications and systems can manage selection of DNS resolvers
>   in various network environments and use cases.

Here I agree with both EKR and Éric that the described work is open-ended
enough to result in unproductive and likely toxic interactions. It would
be my strong recommendation to strike it from the charter at this time,
with an intention of re-visiting it if the working group is able to
productively make headway on the less-contentious issues called for by
the other deliverables. It may well be that this community finds a
positive way of interacting by solving the concrete discovery
mechanisms described above, and can then leverage the relationships
and trust they build during that exercise to succeed where conversations
have so far been fruitless. But I fear that putting this on the plate
as part of the first tranche of work is likely to lead to the same
acrimony that has dogged this endeavor in the past.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 4 Feb 2020 00:26:11 -0800

On Mon, Feb 3, 2020 at 10:14 PM Adam Roach via Datatracker <[email-masked]>
wrote:

> enough to result in unproductive and likely toxic interactions.
>

There is a concrete suggestion here, in the form of

https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01#section-3.3

That algorithm seems useful, or at least informative. But it doesn't seem
important for it to be in the charter of the WG. I'm happy to work on it in
I-D form.

thanks,
Rob

---

From: "Mirja Kühlewind (IETF)" <[email-masked]>
Date: Tue, 4 Feb 2020 09:42:08 +0100

Hi Adam,

Please see a few comments online.

> Am 04.02.2020 um 07:14 schrieb Adam Roach via Datatracker <[email-masked]>:
> 
> contact it over an encrypted channel.

No, this is not necessary the case. The problem is that your usually preferred DNS server might not offer encryption (yet) and therefore you may actually want to discover other servers that provide encryption.

> I *think* we can capture this

As Tommy explained, retrieving additional information about an already known server can be useful as well. Therefore these are to different items, one focusing on discovery only and one on retrieving information. Not sure what exactly you mean with “deliverables“ but I think the charter leaves it correctly open if these are different mechanisms or somehow combined in one protocol or one step as well as leaving it open in how many documents this will get finally published. We need to have some more discussion in the group about the details of these mechanisms, therefore precluding an outcome in the charter more than it is described now doesn’t make sense to me.

> acrimony that has dogged this endeavor in the past.

There has been quite a lot discussion about this point on the list and this is were agreement was reached. Now having the IESG forcing tge community to strike that part really seems like overrunning community agreement and would probably cause equally much discussion or even more. The agreement was to have this as an informational item in the charter and i  personally think it is actually important for this work to have this discussion in parallel to developing technical mechanisms. Let’s not repeat the same mistake that happened with DoH.

Mirja

> 
> 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Rob Sayre <[email-masked]>
Date: Tue, 4 Feb 2020 00:56:15 -0800

On Tue, Feb 4, 2020 at 12:42 AM "Mirja Kühlewind (IETF)" <
[email-masked]> wrote:

> ...
>  Let’s not repeat the same mistake that happened with DoH.
>

What mistake would that be? Encryption standards always have opponents.

thanks,
Rob

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 4 Feb 2020 10:12:02 +0100

This is really not about opposing encryption but I think that DoH was very narrowly only concentrating on the technical aspects while I believe some of the discussion we have right now would probably have been more productive if that would have happen in parallel to the technical work instead of afterwards. But who knows… let’s concentrate on the new work in add now!

> On 4. Feb 2020, at 09:56, Rob Sayre <[email-masked]> wrote:
> 
> On Tue, Feb 4, 2020 at 12:42 AM "Mirja Kühlewind (IETF)" <[email-masked]> wrote:
> ...

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Feb 2020 01:14:19 -0800

On Tue, Feb 4, 2020 at 1:12 AM Mirja Kuehlewind <[email-masked]> wrote:

> This is really not about opposing encryption but I think that DoH was very
> narrowly only concentrating on the technical aspects

In what way do you feel this is different from DoT?

-Ekr

while I believe some of the discussion we have right now would probably
> have been more productive if that would have happen in parallel to the
> technical work instead of afterwards. But who knows… let’s concentrate on
> the new work in add now!
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Feb 2020 01:26:17 -0800

On Tue, Feb 4, 2020 at 12:42 AM "Mirja Kühlewind (IETF)" <
[email-masked]> wrote:

> There has been quite a lot discussion about this point on the list and
> this is were agreement was reached. Now having the IESG forcing tge
> community to strike that part really seems like overrunning community
> agreement and would probably cause equally much discussion or even more.
> The agreement was to have this as an informational item in the charter
>

What agreement? I don't recall a consensus call on either the ADD list or
the IETF list. Until that point, there's just a bunch of people's opinions,
and, as you can see from the traffic, there are objections here.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 4 Feb 2020 01:50:36 -0800

On Tue, Feb 4, 2020 at 1:12 AM Mirja Kuehlewind <[email-masked]> wrote:

> narrowly only concentrating on the technical aspects while I believe some
> of the discussion we have right now would probably have been more
> productive if that would have happen in parallel to the technical work
> instead of afterwards. But who knows… let’s concentrate on the new work in
> add now!
>

I don't agree at all. DoH is a successful standard, and its authors should
be congratulated. Its deployment also does not need this proposed WG.

Compare and contrast with the vast wasteland of unsuccessful RFCs...

thanks,
Rob

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 4 Feb 2020 11:25:57 +0100

Just to clarify I didn’t say that DoH is not a good protocol or that is not successful; just saying discussions we have right now might have been more productive when we would have had that discussion in parallel to the technical work. 

> On 4. Feb 2020, at 10:50, Rob Sayre <[email-masked]> wrote:
> 
> I don't agree at all. DoH is a successful standard, and its authors should be congratulated. Its deployment also does not need this proposed WG.
>

---

From: Rob Sayre <[email-masked]>
Date: Tue, 4 Feb 2020 02:28:59 -0800

On Tue, Feb 4, 2020 at 2:26 AM Mirja Kuehlewind <[email-masked]> wrote:

> Just to clarify I didn’t say that DoH is not a good protocol or that is
> not successful; just saying discussions we have right now might have been
> more productive when we would have had that discussion in parallel to the
> technical work.
>

Still do not agree. The technical work would not be done if tied to the
"discussions" we're having now.

thanks,
Rob

---

From: <[email-masked]>
Date: Tue, 4 Feb 2020 10:50:48 +0000

RFC8484 is a successful protocol, and solves some genuine privacy problems.

But I agree with Mirja that it would have been better to start solving the deployment issues in 2018 rather than 2020.

Would this have delayed the technical work? Yes, but it is easy to see that the adoption of DoH has been delayed by failing to address them. The problems need solving, and it's good that the proposed ADD charter will tackle this issue. Without the new working group, adoption of DoH will in practice be limited to particular areas or use cases. Or we'll find that it creates a new class of problems.

Therefore I support the ADD charter, and I'm willing to work on some drafts in the wg, in a spirit of respect and co-operation.

Chris

From: Add <[email-masked]> On Behalf Of Rob Sayre
Sent: 04 February 2020 10:29
To: Mirja Kuehlewind <[email-masked]>
Cc: ADD Mailing list <[email-masked]>; Adam Roach <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT)

On Tue, Feb 4, 2020 at 2:26 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
Just to clarify I didn’t say that DoH is not a good protocol or that is not successful; just saying discussions we have right now might have been more productive when we would have had that discussion in parallel to the technical work.

Still do not agree. The technical work would not be done if tied to the "discussions" we're having now.

thanks,
Rob

---

From: "Winfield, Alister" <[email-masked]>
Date: Tue, 4 Feb 2020 11:57:51 +0000

I agree RFC8484 works well as a protocol and has some very good use-cases. There are, however, some issues in deployments which I hope and believe can be solved.

Therefore, I support the ADD charter and look forward to working on drafts in the wg.

Alister Winfield.

Ps: Just read Jim’s comment and agree use-cases ought to be / allow multiple use-case documents. We can always combine them if and when commonalities are found.

From: Add <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Tuesday, 4 February 2020 at 10:51
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT)

Chris

thanks,
Rob

--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by sending them to [email-masked] as attachments. Thank you
--------------------------------------------------------------------

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Feb 2020 12:37:29 +0000

>  of an access technology like a VPN.

The insertion of the word "known" works for some of the current deployment models, but definitely not all. It would be unfortunate for the IESG to insist that the nascent working group only consider the current, barely-a-year-old models when others have been requested repeatedly in the BoFs and on the mailing lists. 

Further, this replacement ignores another set of deployment models that have been discussed repeatedly, namely where a resolver that does not offer encryption wants its customers that want encryption to go to a different resolver, probably operated by or for the same operator. Allowing such upgrades can increase the amount of encryption used without forcing resolver operators to add it to their current infrastructure. This is particularly important because we still don't know all the models for naming the resolvers in the PKIX certificates used in TLS for either DoT or DoH.

Although the current charter text allows some weeds-wandering, there is a lot of interest in getting the protocol work defined and deployed in the near future. It would be better to keep the current wording than to limit the working group to a subset of the needed work.

> acrimony that has dogged this endeavor in the past.

However, taking it fully off the plate will lead to the same discussions happening repeatedly due to current deployment strategies of major vendors. Instead of removing the text and hoping the discussions don't happen, it would be better to say that the WG will work on the configuration and use cases after the protocol work is finished. For example:

- after the work on the two mechanisms above is complete, the Working Group
  will begin developing an informational document that describes how client
  applications and systems can manage selection of DNS resolvers
  in various network environments and use cases.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Feb 2020 04:45:35 -0800

On Tue, Feb 4, 2020 at 4:37 AM Paul Hoffman <[email-masked]> wrote:

> However, taking it fully off the plate will lead to the same discussions
> happening repeatedly due to current deployment strategies of major vendors.

Well, perhaps, but we don't need an IETF WG for those discussions and the
evidence is that that's not a productive venue for them.

Instead of removing the text and hoping the discussions don't happen, it
> would be better to say that the WG will work on the configuration and use
> cases after the protocol work is finished. For example:
>

Why not simply recharter at that point?

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Feb 2020 13:49:51 +0000

On Feb 4, 2020, at 12:45 PM, Eric Rescorla <[email-masked]> wrote:
> Well, perhaps, but we don't need an IETF WG for those discussions and the evidence is that that's not a productive venue for them.

We disagree that such evidence exists. Many people have been waiting for a working group so that a document can be created in the IETF process.

> Why not simply recharter at that point?

There has been success in the past with working groups that ordered their work instead of ignoring likely future work. (Of course, there have also been well-documented failures.) My preference would be to make it clear that there is a venue for the informational document, but not until the technical work is done first.

--Paul Hoffman

---

From: Kenji Baheux <[email-masked]>
Date: Tue, 4 Feb 2020 08:37:36 -0600

After reading a few exchanges, I can't help but wonder why there is a need
to preclude specific items of interest to a significant number of
participants, on what appears to be unsubstantiated doubts about the wg's
ability to be productive, or to produce deliverables that will meet various
stakeholders' requirements, or of the wg's chairs inability to guide the
group, etc.

If certain wg items end up not making progress then so be it. Chairs and
group members should notice and make a call or a change.

If certain wg items result in unacceptable deliverables for specific
stakeholders then so be it. Or, if certain wg items are non-starters for
some stakeholders, then so be it. It's not necessarily the case that
everyone feels the same. Beside, I don't think anyone has the power to
force anyone else to change their belief and just have them
implement/follow everything that would come out of this wg.

So, to the extent that there are many folks and parties interested in these
specific problems, the discussions will inevitably happen. It seems
preferable to have them happen in the context of the IETF so that the
output benefits from other viewpoints and expertise. That would at least
increases the chance that the deliverables are acceptable by a wider set of
stakeholders, or that the group sees dead-ends earlier, etc.

On Tue, Feb 4, 2020, 07:50 Paul Hoffman <[email-masked]> wrote:

> > Well, perhaps, but we don't need an IETF WG for those discussions and
> the evidence is that that's not a productive venue for them.
>
> We disagree that such evidence exists. Many people have been waiting for a
> working group so that a document can be created in the IETF process.
>
> There has been success in the past with working groups that ordered their
> work instead of ignoring likely future work. (Of course, there have also
> been well-documented failures.) My preference would be to make it clear
> that there is a venue for the informational document, but not until the
> technical work is done first.
>
> --Paul Hoffman--
> Add mailing list
> [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Feb 2020 06:43:35 -0800

> stakeholders' requirements, or of the wg's chairs inability to guide the

I'm not sure why you think those doubts are unsubstantiated. We have the
past year of traffic on this list and others as evidence of the difficulty
of reaching any kind of consensus on the general policy questions.

-Ekr

> So, to the extent that there are many folks and parties interested in
> these specific problems, the discussions will inevitably happen. It seems
>> We disagree that such evidence exists. Many people have been waiting for
>> a working group so that a document can be created in the IETF process.
>>

---

From: Kenji Baheux <[email-masked]>
Date: Tue, 4 Feb 2020 08:54:31 -0600

On Tue, Feb 4, 2020, 08:44 Eric Rescorla <[email-masked]> wrote:

>> After reading a few exchanges, I can't help but wonder why there is a
>> need to preclude specific items of interest to a significant number of

>From the interactions I've had (out of these lists), I can tell you that it
is possible to have reasonable discussions and make progress toward a
better state for our mutual users. I hope that we can bring these sort of
discussions to a broader group.

>>> There has been success in the past with working groups that ordered
>>> their work instead of ignoring likely future work. (Of course, there have
>>> also been well-documented failures.) My preference would be to make it
>>> clear that there is a venue for the informational document, but not until
>>> the technical work is done first.
>>>
>>> --Paul Hoffman--
>>> Add mailing list
>>> [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Feb 2020 10:00:01 -0500

On Feb 4, 2020, at 9:37 AM, Kenji Baheux <kenjibaheux=[email-masked]> wrote:
> After reading a few exchanges, I can't help but wonder why there is a need to preclude specific items of interest to a significant number of participants, on what appears to be unsubstantiated doubts about the wg's ability to be productive, or to produce deliverables that will meet various stakeholders' requirements, or of the wg's chairs inability to guide the group, etc.

The reason for this is that when a working group is given a work item on which it’s clear consensus cannot be reached, that working group becomes a tax on the time of all the people who have to continually participate in order to prevent consensus being reached on what they consider to be a bad idea.  If the work item is not in the charter, then this (sometimes massive) time tax doesn’t exist.

So it really is important to exclude work items on which it’s unlikely that consensus can be reached.

---

From: Andrew Campling <[email-masked]>
Date: Tue, 4 Feb 2020 15:24:13 +0000

+1 to Kenji and Paul’s points below.

Andrew

From: Kenji Baheux <[email-masked]>
Sent: 04 February 2020 14:38
To: Paul Hoffman <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; ADD Mailing list <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT)

If certain wg items end up not making progress then so be it. Chairs and group members should notice and make a call or a change.

If certain wg items result in unacceptable deliverables for specific stakeholders then so be it. Or, if certain wg items are non-starters for some stakeholders, then so be it. It's not necessarily the case that everyone feels the same. Beside, I don't think anyone has the power to force anyone else to change their belief and just have them implement/follow everything that would come out of this wg.

So, to the extent that there are many folks and parties interested in these specific problems, the discussions will inevitably happen. It seems preferable to have them happen in the context of the IETF so that the output benefits from other viewpoints and expertise. That would at least increases the chance that the deliverables are acceptable by a wider set of stakeholders, or that the group sees dead-ends earlier, etc.

On Tue, Feb 4, 2020, 07:50 Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:

--Paul Hoffman--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 4 Feb 2020 15:29:27 +0000

Like many on this list, I disagree that the third bullet from the charter should be struck, and I support Tommy Pauly’s charter as written.

Adam> It may well be that this community finds a
positive way of interacting by solving the concrete discovery
mechanisms described above, and can then leverage the relationships
and trust they build during that exercise to succeed where conversations
have so far been fruitless.

Some of us would say this has already started to happen thanks to a larger number of us declaring support for encrypted DNS deployment. For example, conversations on this list have become more focused on how we should deploy versus whether deployment is even a good thing. We also greatly limit the quality of the solutions we can build for bullets one and two if we ignore this difficult topic altogether.

I look forward to bringing the productivity from offlist collaborations into a formal WG where that collaboration can have a greater ecosystem impact.

Thanks,
Tommy (the other one)

________________________________
From: Add <[email-masked]> on behalf of Adam Roach via Datatracker <[email-masked]>
Sent: Monday, February 3, 2020 10:14 PM
To: The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [EXTERNAL] [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT)

The document, along with other ballot positions, can be found here:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-add%2F&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cc6ad75f691664d08b32008d7a9397d82%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637163936698675465&amp;sdata=ZW1Gl9LEEfD5MGqLxY649%2FrqzKCILBpPyVt3MTPntUs%3D&amp;reserved=0

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cc6ad75f691664d08b32008d7a9397d82%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637163936698685422&amp;sdata=OXlAX9Sz0NPLSqBaa2JcFKXmTVxGBS5VvdeGNvaKVtQ%3D&amp;reserved=0

---

From: Kenji Baheux <[email-masked]>
Date: Tue, 4 Feb 2020 09:30:44 -0600

On Tue, Feb 4, 2020, 09:00 Ted Lemon <[email-masked]> wrote:

> On Feb 4, 2020, at 9:37 AM, Kenji Baheux <
> kenjibaheux=[email-masked]> wrote:
>
> The reason for this is that when a working group is given a work item on
> which it’s clear consensus cannot be reached, that working group becomes a
> tax on the time of all the people who have to continually participate in
> order to prevent consensus
>

It feels like we are keeping hostage the whole charter just because of one
item that's informational on top. Does "consensus by worning-out the
opposition" necessarily result in having more folks implement what some
would consider a bad idea? Can't they document and convince everyone why
it's a bad idea despite the "consensus"? Or if this is a question of
requirements, can't these requirements be documented and justified once?

being reached on what they consider to be a bad idea.

This seems to assume that some items in the charter would inevitably result
in bad ideas, or that said items are framed in terms of a specific (bad)
idea and not a problem.

The latter can be fixed right now. The former could just be folks assuming
a certain direction they disagree with or they could be right but evidence
rather than belief seems preferable. I don't think this should block the
charter though. Couldn't the wg decide to drop the item as it is presented
said evidence?

 If the work item is not in the charter, then this (sometimes massive) time
> tax doesn’t exist.

The work item will find a different home as long as there are parties
interested in it. It might not be a tax time anymore for the unconvinced
folks but the outcome would be the same (worse in fact), i.e. a "consensus"
on something that didn't get the full benefit of a broader panel of voices
with potential implementers unaware of the (unvoiced) downsides.

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 4 Feb 2020 15:33:09 +0000

+1, and calling this point out in particular (having a WG ignore parts of the charter just means the same conversations will occur without the WG leading to a less ideal solution due to a smaller collaborative audience):

> So, to the extent that there are many folks and parties interested in these specific problems, the discussions will inevitably happen. It seems preferable to have them happen in the context of the IETF so that the output benefits from other viewpoints and expertise.
________________________________
From: Add <[email-masked]> on behalf of Andrew Campling <[email-masked]>
Sent: Tuesday, February 4, 2020 7:24 AM
To: Kenji Baheux <[email-masked]>; Paul Hoffman <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; ADD Mailing list <[email-masked]>; The IESG <[email-masked]>; [email-masked] <[email-masked]>
Subject: [EXTERNAL] Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT)

Andrew

--Paul Hoffman--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cabace10e7764403ff6e208d7a9865274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637164266693397946&sdata=Tr6QSFl6J%2BSsuWdDW9GJo2rx8k8fP%2B7AJo5GFo5h5sQ%3D&reserved=0>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Feb 2020 10:56:45 -0500

On Feb 4, 2020, at 10:30 AM, Kenji Baheux <[email-masked]> wrote:
> On Tue, Feb 4, 2020, 09:00 Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> On Feb 4, 2020, at 9:37 AM, Kenji Baheux <kenjibaheux=[email-masked] <mailto:kenjibaheux=[email-masked]>> wrote:
> The reason for this is that when a working group is given a work item on which it’s clear consensus cannot be reached, that working group becomes a tax on the time of all the people who have to continually participate in order to prevent consensus
> 
> It feels like we are keeping hostage the whole charter just because of one item that's informational on top. Does "consensus by worning-out the opposition" necessarily result in having more folks implement what some would consider a bad idea? Can't they document and convince everyone why it's a bad idea despite the "consensus"? Or if this is a question of requirements, can't these requirements be documented and justified once?

To be clear, I was simply explaining why it’s important to get the charter right.  It does matter that we do not include items in the charter upon which agreement can be reached.  It appears that there is not widespread understanding of this problem in the IETF, and that’s why I consider it worth sticking my head up and reminding people of this from time to time.

Whether or not the current situation justifies a change to the charter is another question.

> The work item will find a different home as long as there are parties interested in it. It might not be a tax time anymore for the unconvinced folks but the outcome would be the same (worse in fact), i.e. a "consensus" on something that didn't get the full benefit of a broader panel of voices with potential implementers unaware of the (unvoiced) downsides.

This is true.  However, the times when the discussion matters are:

1. When a consensus call has been made on a working group charter (that is, now)
2. When a call for adoption has been made in a working group
3. When a working group last call has been made
4. When an IETF last call has been made

At each of these points in the process, the likelihood of consensus not being called in favor of publication is less.   If a working group exists and has a work item, it’s presumed that they are supposed to publish something that corresponds to that work item; not publishing it becomes an exception.  So it’s good to be clear on what the work item is.

If a working group exists and has a work item, then the call for adoption is important, but because the document being adopted can change quite a bit, it’s harder to argue against adoption: proponents can simply say “well, we can address your concerns once the document has been adopted.”   This is frequently said, and documents are frequently adopted over such objections.

When working group last call happens, there is a presumption that, absent clear technical objections that the working group has not addressed, the document will be published.  You often see working group chairs getting this wrong and asking for people to say “yeah, go ahead and publish it,” because it’s _also_ important that the working group show that the document has been reviewed, but strictly speaking what is being asked for here is confirmation that the document has been reviewed and that no technical objections are to be raised.

Documents that reach IETF last call almost always pass; when they don’t, the process of preventing them from passing is very expensive.  It’s one of the reasons people tend not to read the IETF mailing list.

So for this reason, it really is important to get this right, now.  This is why, to your original question, there is a need to preclude specific items of interest to a significant number of participants during the charter discussion.  The working group can still discuss those items; they simply can’t publish anything without getting consensus to add the work to the charter.  This allows participants to choose their battles more carefully—if something is a bad idea, but there’s no recharter going on, you can say it’s a bad idea and then ignore the discussion until the rechartering happens, at which point you can point out that you’ve already objected and why, and hopefully the right thing happens in the consensus process.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 4 Feb 2020 11:02:21 -0500

On Tue, Feb 4, 2020 at 10:31 AM Kenji Baheux <kenjibaheux=
[email-masked]> wrote:

> item that's informational on top.
>

My impression (as someone who's been mostly passive here) is actually the
opposite, namely that this one controversial work item is holding up
progress on the things people agree are needed.  The work described in this
third work item seems clearly separable from the other two items, in the
sense that the better discovery and decision support mechanisms can be
built and deployed without the deployment guidance.  Indeed, it is usually
better to write the deployment guidance after you have the mechanisms and
some experience with them!

So ISTM that this third work item is both (a) an impediment to progress on
the substantive technical work in the charter, and (b) actually premature.
That seems like a pretty clear case for dropping it.

--Richard

> Does "consensus by worning-out the opposition" necessarily result in
> having more folks implement what some would consider a bad idea? Can't they
> document and convince everyone why it's a bad idea despite the "consensus"?
> Or if this is a question of requirements, can't these requirements be
> documented and justified once?
>
>
>
> This seems to assume that some items in the charter would inevitably
> result in bad ideas, or that said items are framed in terms of a specific
> (bad) idea and not a problem.
>
>  If the work item is not in the charter, then this (sometimes massive)
>> time tax doesn’t exist.
>>
>

---

From: Warren Kumari <[email-masked]>
Date: Tue, 4 Feb 2020 11:13:56 -0500

> There has been success in the past with working groups that ordered their work instead of ignoring likely future work. (Of course, there have also been well-documented failures.) My preference woul…

... and my preference is to just get the $bad_word thing chartered -
as I said in my ballot, this charter is imperfect, but I'd much rather
see work progress with an imperfect charter than more division,
fragmentation and delays while trying to get this perfectly polished.
If we generally agree on what the expected shape of the work is, and
largely understand what we are working towards *and there is some
goodwill remaining*, an imperfect charter is fine - but I do think
that there is a risk of us over-engineering / lawyering chartered to
death, at which point the tone of the WG becomes (even more?) toxic.

Happy and healthy WGs often take on additional documents as they learn
more about the problem space (and as participants show up with
documents!) - I personally think agree with Paul that this would be a
good document for the WG to create, but I'm concerned that we run the
risk of further delay in getting any work done while charter
lawyering, and ending up in a situation where people are unwilling to
work together because everyone is so tired of this / hated the
charter. A flexible charter, with good chairs, a collegiate
atmosphere, and a desire to get work done would be my preference...

"Better a diamond with a flaw than a pebble without."
   -- Confucius[0]

But, this isn't a hill I'm willing to die (or even get lightly injured :-)) on,
W

[0]: Although, almost definitely not.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Adam Roach <[email-masked]>
Date: Tue, 4 Feb 2020 10:38:46 -0600

On 2/4/20 10:13, Warren Kumari wrote:
> good document for the WG to create,

Sure, and I think the voices on the other side at least make it clear 
that this is a pretty controversial goal that runs the risk of 
preventing progress on the other two. I take the point that you'd prefer 
to create a working group sooner rather than later; but I think we're 
better off if we create a productive working group a little later 
instead of creating a dysfunctional one immediately.

And, to be clear, I think we can get this done before Vancouver either way.

In the interest of seeing if there is some compromise here that provides 
sufficient guiderails, I'll call out the elephant in the room: the 
concern that I have about work that satisfies this third proposed work 
item (and I assume at least part of other peoples' worries) is that 
there will be a tug-of-war about whether it contains prescriptive and/or 
proscriptive statements, rather than simply surveying network behaviors 
that require consideration. If there's some language that we can add to 
the charter that prevents this (and, no, simply being Informational is 
not sufficient), then it might head off the issues that several of us 
are concerned with.

/a