Subject: [Add] The ADD WG has placed draft-boucadair-add-deployment-considerations in state "Call For Adoption By WG Issued"

From: IETF Secretariat <[email-masked]>
Date: Tue, 12 Oct 2021 08:47:07 -0700

The ADD WG has placed draft-boucadair-add-deployment-considerations in state
Call For Adoption By WG Issued (entered by Glenn Deen)

The document is available at
https://datatracker.ietf.org/doc/draft-boucadair-add-deployment-considerations/

Comment:
This document is a -00 draft however the material is not new and has been
moved from other WG documents into this draft as suggested during WG
discussions in past meetings.

This WG Adoption call will run for 2 weeks until Oct 27, 2021.

thanks,
ADD Co-chairs,
Glenn Deen,  David Lawrence

---

From: tirumal reddy <[email-masked]>
Date: Thu, 14 Oct 2021 16:34:28 +0530

I support adoption of the draft. It seems useful to discuss the following
deployment scenario in the draft:

The CPE uses a global IPv6 address and is upgradable. The mechanism
discussed in https://datatracker.ietf.org/doc/html/rfc8738 can be used by
the CPE to get a certificate from a CA for the IPv6 address and can host a
HTTP server temporarily till the ACME challenge is complete.

Cheers,

-Tiru

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Oct 2021 18:08:14 -0700

I do not support adoption of this draft. It's largely background material
and I do not believe that the WG needs to work on it or publish it as an
RFC. It can serve its purpose just fine as an individual draft.

-Ekr

On Tue, Oct 12, 2021 at 8:47 AM IETF Secretariat <
[email-masked]> wrote:

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 14 Oct 2021 22:19:16 -0400 (EDT)

On Thu, 14 Oct 2021, Eric Rescorla wrote:

> Subject: Re: [Add] The ADD WG has placed
>     draft-boucadair-add-deployment-considerations in state
>     "Call For Adoption By WG Issued"
> 
> I do not support adoption of this draft. It's largely background material and I do not believe that the WG needs to work on it or publish it as an RFC. It
> can serve its purpose just fine as an individual draft.

I agree with Eric. Once we have protocol documents, I don't think this
documents add anything to implementors for the new protocols to assist
them with their implementation.

Paul

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 15 Oct 2021 15:10:20 -0700

I also agree that this document doesn’t need to be adopted in ADD. It does describe some of the possible deployment setups, but it’s not clear to me that these differences impact the discovery protocols this working group is focused on.

If there needs to be advice written down for deployments of encrypted DNS, perhaps that would belong in DNSOP (who has a charter that includes deployment operational considerations more closely).

Thanks,
Tommy

> On Oct 14, 2021, at 7:19 PM, Paul Wouters <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Oct 2021 18:12:37 -0400

I have a problem with the implied view here is that WGs can only adopt
documents they intend to publish.
That suggests, against our process, that documents that a WG adopts will all
be published.   When that's really a second decision.

The WG can adopt the document and not publish it.
WGs have done this with use cases and requirements regularly.
It can merge the contents into a protocol document (or documents).
It can remain as a reference of some kind to retain a history of WG
conclusions.   Adopting it costs nothing, but allows discussion of the
document to get priority over non-adopted documents.

The list of documents the WG has adopted is a list of things that a person who
wishes to participate in the WG needs to know about. (i.e.: Needs to read)

I agree with you: I don't know if the document will be useful as an operational RFC.
I think that many enterprise and ISP operators might appreciate the content.
That remains to be seen, I think.

But, since you say it's useful as background material, that implies that all participants
in the WG should be familiar with it.  So, by that argument, it should be adopted.

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------
    > --
    > Add mailing list
    > [email-masked]

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 16 Oct 2021 19:14:23 -0400

I can only support adoption on the condition it is never published, but
used as a WG document to document all the deployment scenarios that ADD is
trying to operate in. Otherwise, I am against adoption.

tim

On Fri, Oct 15, 2021 at 6:10 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> I also agree that this document doesn’t need to be adopted in ADD. It does
> describe some of the possible deployment setups, but it’s not clear to me
> that these differences impact the discovery protocols this working group is
> focused on.
>
> If there needs to be advice written down for deployments of encrypted DNS,
> perhaps that would belong in DNSOP (who has a charter that includes
> deployment operational considerations more closely).
>
> Thanks,
> Tommy
>
> >> I do not support adoption of this draft. It's largely background
> material and I do not believe that the WG needs to work on it or publish it
> as an RFC. It

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 16 Oct 2021 16:25:28 -0700

> documents they intend to publish.

This is not what I said. Rather, I said:
"I do not believe that the WG needs to work on it or publish it as an RFC."

Note the clause before "or publish". I think it's fine for the authors to
have
this document as an I-D. I do not believe that WG resources should be
used to refine it.

> document to get priority over non-adopted documents.

Well, I do not believe this document should get priority over non-adopted
documents.

Moreover, I don't agree that adopting it costs nothing. As you observe, once
it's adopted there is an implicit assumption that this to some extent
represents
"WG conclusions", which means that WG members need to invest resources
in ensuring that it is right. IMO it would simply be better to have it be
an individual
draft and people can pay attention to it or not as they please.

> in the WG should be familiar with it.  So, by that argument, it should be

Again, this is not what I said. I said it *was* background material. I'm
not actually
sure how useful this background is.

-Ekr

> material
>     >> The ADD WG has placed draft-boucadair-add-deployment-considerations
> in
>     >> state

---

From: <[email-masked]>
Date: Mon, 18 Oct 2021 05:38:38 +0000

Hi all, 

I support the draft to be adopted by the WG. I'm neutral whether this ends in an RFC, though. 

The draft adopts a simplified (not a superficial) architectural view on purpose. It also discusses how a key requirement (support of forwarders in home networks, for example) can be provided with ADD protocols. The document discusses how this can be solved for DNR, but whether/how this can be solved in DDR is still to be done.

Cheers,
Med

> -----Message d'origine-----
> De : IETF Secretariat <[email-masked]>
> Envoyé : mardi 12 octobre 2021 17:47
> À : [email-masked]; [email-masked]; draft-boucadair-add-deployment-
> [email-masked]
> Objet : The ADD WG has placed draft-boucadair-add-deployment-
> considerations in state "Call For Adoption By WG Issued"
> 
> 
> The ADD WG has placed draft-boucadair-add-deployment-considerations in
> state Call For Adoption By WG Issued (entered by Glenn Deen)
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Andrew Campling <[email-masked]>
Date: Tue, 19 Oct 2021 12:23:10 +0000

I believe that there is a need to document deployment considerations for the various options to discover encrypted DNS servers.  It is clear to me that the working group has already benefited from sharing knowledge given that market conditions vary widely in different geographies.  Capturing these considerations within a single document is useful and will help evaluate consistently how well different discovery options address the diverse needs of the market.  

I note from other responses that there may not be a requirement to publish a final version of this document as an RFC, retaining it instead in its adopted state as an official repository of deployment considerations for the ADD working group.  That is not a barrier to adoption and does leave the door open to progressing to RFC status in the future if there is consensus that such a move would be beneficial.

Given the above, I believe that this document is beneficial to the working group and I support its adoption.

Andrew

-----Original Message-----
From: IETF Secretariat <[email-masked]> 
Sent: 12 October 2021 16:47
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Add] The ADD WG has placed draft-boucadair-add-deployment-considerations in state "Call For Adoption By WG Issued"

The ADD WG has placed draft-boucadair-add-deployment-considerations in state Call For Adoption By WG Issued (entered by Glenn Deen)

Comment:
This document is a -00 draft however the material is not new and has been moved from other WG documents into this draft as suggested during WG discussions in past meetings.

thanks,
ADD Co-chairs,