From nobody Sat Feb 1 07:29:55 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609EA12022C for ; Sat, 1 Feb 2020 07:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfhuFA4po-m4 for ; Sat, 1 Feb 2020 07:29:50 -0800 (PST) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B2C1200F9 for ; Sat, 1 Feb 2020 07:29:49 -0800 (PST) Received: by mail-lf1-x144.google.com with SMTP id r14so6847535lfm.5 for ; Sat, 01 Feb 2020 07:29:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=siNKwwkHZbwPlz73XvvNrrX+Shvyxu/UcBYFIUv4mME=; b=XFUJe1V8Stjyd5Q4HzCfGg8Ds4SMHChtyWSpyA4ejV5+pwK9OLr9NgFLiJnz8YAOCj sfDbd+bMhQ6lRbAQyolzKLoxmpfGli+WyRaEllkYk23VRenJrTqIcg5xNJv+1t79QFps fMVC8POKnktDQMiJ1ZDubnQSF8wGYsxCWbOl89gFIYvk9VJbCeR6fPfrTRF3JZjcG1t8 hduED/NW5GcbWVOXkkZw6myYSnSWaArhx8s0soDmAgl7YFmWXWp83jUx9bYfrMBkovks yObUDttxFYBIMGHWmbjHEKvsBu8iqcHGy8OLUCO+XsrDLyYxazAzwc6GklE8mGGf/Cp0 TDkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=siNKwwkHZbwPlz73XvvNrrX+Shvyxu/UcBYFIUv4mME=; b=YVo22YmHXD2FrK2LLnNbvmPwU3vPG4HkcRk8TR9ImQeZb10pIYVZSH1qRs4s5UhmIG t2Ctt3avGxggGzrLkHlZdCMSGydgCt2i+MwQvJuc9Oq/Rw/EAG6zHlIuPzYFtAhMeZK6 pMdrsH1uPAsR3vRSZpGD8vNvm/KpOMmnYVOxX9FXImGc1IqD9QABuiuRY9d7KPx3ai6+ 6RZWmdobyCRc+bQ68uj5CdxsHjt9tZoDV/s7MmAOL41TfUOZCfUrUiM8Ix4K7O7UY2hG qawhK7uMwdChxDeWvOyhyLuttraUlkMoYWUu2qsMhTh7XtYAJiqeRvR7nDKvKAGeLxEe 0q9A== X-Gm-Message-State: APjAAAXsrH62ziQ3xiprFy6I0E5D9vT/Mzj1Ccza5Azt+Pf5be8HMO89 xos8HlPyDZKU4doghZ1lz3smg4zdRcz7LmkSqziJyQ== X-Google-Smtp-Source: APXvYqzorRTqQ7LDC7VzTKs2r9T8eIFpEPBYbIsweq159IIVDyDahyoI33FwaIYh8gNDfkC+wOsja6RVDGjgH7hoLIc= X-Received: by 2002:a19:cc11:: with SMTP id c17mr7892116lfg.161.1580570987686; Sat, 01 Feb 2020 07:29:47 -0800 (PST) MIME-Version: 1.0 References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> In-Reply-To: From: Eric Rescorla Date: Sat, 1 Feb 2020 07:29:11 -0800 Message-ID: To: Barry Leiba Cc: Tommy Pauly , ADD Mailing list , IESG Content-Type: multipart/alternative; boundary="000000000000437ffa059d855c67" Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 15:29:52 -0000 --000000000000437ffa059d855c67 Content-Type: text/plain; charset="UTF-8" Hi folks, I finally got around to reading this charter and while I appreciate the effort that has gone into it, I don't think it's ready for prime time. The fundamental problem here is that the charter seems to be conflating two very different types of discovery: (1) Discovering the resolvers that are available on a specific network or that the network would like a given client to use (and potentially their policies). (as in draft-ietf-dnsop-resolver-information or draft-reddy-dprive-dprive-privacy-policy) (2) Discovering the resolvers that a given domains would like you to use to resolve them and their subdomains (as in draft-pauly-dprive-adaptive-dns-privacy) It's pretty hard to map these onto the list of work items. - 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; - define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions; Perhaps the first bullet is intended to refer to (1), but the "public Internet" text that is confusing here, because while the local network might want to tell you about some server that happens to be on the public Internet (e.g., it wants to point you to QuadX) that's not the relevant point and not something that the client cares about [0]. Similarly, the second bullet point might be intended to refer to (2) but it doesn't have anything about per-domain information, so it might just as well refer to something like draft-ietf-dnsop-resolver-information. So, in both cases it just seems like this charter conflates these cases. I would suggest changing the bullets to be more like my list above. The third bullet seems like it is edging pretty close to the zone of controversy: - develop an informational document that describes how client applications and systems can manage selection of DNS resolvers in various network environments and use cases. I supposed if this was just a laundry list of every idea anyone had ever thought of, that might be OK, but in my experience documents like this (1) do some selection of the mechanisms and (2) want to list the pluses and minuses of each mechanism and both of these seem like a recipe for the kind of argument that this group has been having for some time. I would propose striking this work item entirely. -Ekr [0] It's possible that what this is referring to is somehow discovering a set of viable QuadX resolvers, but that's yet a third problem with its own solution and I doubt we are going to be able to standardize that at all. On Tue, Jan 28, 2020 at 7:41 AM Barry Leiba wrote: > I have begun the chartering process with the charter below, modulo a > small edit by me in the last paragraph. > > https://datatracker.ietf.org/doc/charter-ietf-add/ > > It would be good if we could have an estimated milestone based on the > assumption that this working group would be chartered by and meet at > IETF 107 in Vancouver. > > Barry, ART AD > > On Mon, Jan 27, 2020 at 4:13 PM Tommy Pauly wrote: > > > > Hi ADD, > > > > As our discussion on the proposed charter has quieted down, I wanted to > send a brief update and summary. > > > > The main point of discussion was the paragraph on security requirements > that began "Any mechanisms that...". As many people stated on the previous > thread, the necessity for security considerations and security area review > in work produced by an IETF working group is already well-established, so > this text is not needed specifically in this charter. There were some > proposals to tweak the language, but on the whole, it seems that we can > live without that paragraph. > > > > Jari also had a good suggestion to include a sentence about the impact > of resolver selection (on reachability and privacy, etc). After looking at > adding that text, I am concerned that adding it to the charter gets into > too many details that really belong in the WG documents, particularly > around how to assess the "privacy" implications of choosing one resolver > over another. The charter does indicate that these mechanisms are being > used to "provide benefits to the security and privacy of DNS data", and it > does cover reachability with the example of "a resolver may be able to > resolve private or local names...". As such, I'd prefer to not add any new > sentence for now (and Jari indicated he could live with the text as is!). > > > > I've included the updated proposal, which matches the previous proposal > and removes the text on security requirements. Based on the previous > thread, this should represent the consensus of the list. > > > > Barry, can you help get this started in the process of chartering? > > > > Best, > > Tommy > > > > > > > > Adaptive DNS Discovery (ADD) > > ==================================== > > Proposed Working Group Charter > > > > Sending DNS messages over encrypted transports, as defined in DNS over > > TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides > > benefits to the security and privacy of DNS data. Clients, such as > > applications and host operating systems, have started adopting these > > protocols to provide these user benefits. > > > > This working group will focus on discovery and selection of DNS resolvers > > by DNS clients in a variety of networking environments, including public > > networks, private networks, and VPNs; supporting both encrypted and > > unencrypted resolvers. > > > > Clients adopting encrypted DNS protocols need to determine which DNS > > servers support encrypted transports, and which server to use for > specific > > queries if multiple servers are available. These decisions can vary based > > on the network environment, and also based on the content and purpose of > > the client queries. > > > > Network operators that start offering DNS encryption on their servers > also > > need a way to indicate this support to clients. Communicating information > > about resolver configuration and behavior allows clients to make more > > informed decisions about which DNS servers to use. For example, a > resolver > > may be able to resolve private or local names as a split DNS server. > > > > The Adaptive DNS Discovery (ADD) working group will work on the following > > deliverables: > > > > - 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; > > > > - define a mechanism that allows communication of DNS resolver > > information to clients for use in selection decisions; > > > > - develop an informational document that describes how client > > applications and systems can manage selection of DNS resolvers > > in various network environments and use cases. > > > > This working group will coordinate with dnsop, doh, and dprive for any > > changes required in DNS protocols. It will also work with capport to > > ensure that solutions are applicable to captive networks. > > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000437ffa059d855c67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi folks,

I finally got around to reading this = charter and while I appreciate
the effort that has gone into it, I don&#= 39;t think it's ready for prime
time.

The fundamental problem= here is that the charter seems to be
conflating two very different type= s of discovery:

(1) Discovering the resolvers that are available on = a specific
=C2=A0 =C2=A0 network or that the network would like a given = client
=C2=A0 =C2=A0 to use (and potentially their policies). (as in
= =C2=A0 =C2=A0 draft-ietf-dnsop-resolver-information or
=C2=A0 =C2=A0 dra= ft-reddy-dprive-dprive-privacy-policy)

(2) Discovering the resolvers= that a given domains would like
=C2=A0 =C2=A0 you to use to resolve the= m and their subdomains
=C2=A0 =C2=A0 (as in draft-pauly-dprive-adaptive-= dns-privacy)

It's pretty hard to map these onto the list of work= items.
=C2=A0 =C2=A0
=C2=A0 =C2=A0- define a mechanism that allows = clients to discover DNS resolvers,
=C2=A0 =C2=A0including encrypted DNS = servers, that are available to the client
=C2=A0 =C2=A0either on the pub= lic Internet or on private or local networks;

=C2=A0 =C2=A0- define = a mechanism that allows communication of DNS resolver
=C2=A0 =C2=A0infor= mation to clients for use in selection decisions;

Perhaps the first = bullet is intended to refer to (1), but the "public
Internet" = text that is confusing here, because while the local network
might want = to tell you about some server that happens to be on the
public Internet = (e.g., it wants to point you to QuadX) that's not the
relevant point= and not something that the client cares about [0].
Similarly, the secon= d bullet point might be intended to refer to (2)
but it doesn't have= anything about per-domain information, so it might
just as well refer t= o something like
draft-ietf-dnsop-resolver-information. So, in both case= s it just seems
like this charter conflates these cases. I would suggest= changing the
bullets to be more like my list above.


The thir= d bullet seems like it is edging pretty close to the
zone of controversy= :

=C2=A0 =C2=A0- develop an informational document that describes ho= w client
=C2=A0 =C2=A0applications and systems can manage selection of D= NS resolvers
=C2=A0 =C2=A0in various network environments and use cases.=

I supposed if this was just a laundry list of every idea anyone
= had ever thought of, that might be OK, but in my experience
documents li= ke this (1) do some selection of the mechanisms
and (2) want to list the= pluses and minuses of each mechanism
and both of these seem like a reci= pe for the kind of argument
that this group has been having for some tim= e. I would propose
striking this work item entirely.

-Ekr

=
[0] It's possible that what this is referring to is somehow
disc= overing a set of viable QuadX resolvers, but that's yet
a third prob= lem with its own solution and I doubt we are going
to be able to standar= dize that at all.



On Tue, Jan 28, 2020 at 7:41 AM Barry Leiba &= lt;barryleiba@computer.org&g= t; wrote:
I have= begun the chartering process with the charter below, modulo a
small edit by me in the last paragraph.

https://datatracker.ietf.org/doc/charter-ietf-add/=

It would be good if we could have an estimated milestone based on the
assumption that this working group would be chartered by and meet at
IETF 107 in Vancouver.

Barry, ART AD

On Mon, Jan 27, 2020 at 4:13 PM Tommy Pauly <tpauly@apple.com> wrote:
>
> Hi ADD,
>
> As our discussion on the proposed charter has quieted down, I wanted t= o send a brief update and summary.
>
> The main point of discussion was the paragraph on security requirement= s that began "Any mechanisms that...". As many people stated on t= he previous thread, the necessity for security considerations and security = area review in work produced by an IETF working group is already well-estab= lished, so this text is not needed specifically in this charter. There were= some proposals to tweak the language, but on the whole, it seems that we c= an live without that paragraph.
>
> Jari also had a good suggestion to include a sentence about the impact= of resolver selection (on reachability and privacy, etc). After looking at= adding that text, I am concerned that adding it to the charter gets into t= oo many details that really belong in the WG documents, particularly around= how to assess the "privacy" implications of choosing one resolve= r over another. The charter does indicate that these mechanisms are being u= sed to "provide benefits to the security and privacy of DNS data"= , and it does cover reachability with the example of "a resolver may b= e able to resolve private or local names...". As such, I'd prefer = to not add any new sentence for now (and Jari indicated he could live with = the text as is!).
>
> I've included the updated proposal, which matches the previous pro= posal and removes the text on security requirements. Based on the previous = thread, this should represent the consensus of the list.
>
> Barry, can you help get this started in the process of chartering?
>
> Best,
> Tommy
>
>
>
> Adaptive DNS Discovery (ADD)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Proposed Working Group Charter
>
> Sending DNS messages over encrypted transports, as defined in DNS over=
> TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides
> benefits to the security and privacy of DNS data. Clients, such as
> applications and host operating systems, have started adopting these > protocols to provide these user benefits.
>
> This working group will focus on discovery and selection of DNS resolv= ers
> by DNS clients in a variety of networking environments, including publ= ic
> networks, private networks, and VPNs; supporting both encrypted and > unencrypted resolvers.
>
> Clients adopting encrypted DNS protocols need to determine which DNS > servers support encrypted transports, and which server to use for spec= ific
> queries if multiple servers are available. These decisions can vary ba= sed
> on the network environment, and also based on the content and purpose = of
> the client queries.
>
> Network operators that start offering DNS encryption on their servers = also
> need a way to indicate this support to clients. Communicating informat= ion
> about resolver configuration and behavior allows clients to make more<= br> > informed decisions about which DNS servers to use. For example, a reso= lver
> may be able to resolve private or local names as a split DNS server. >
> The Adaptive DNS Discovery (ADD) working group will work on the follow= ing
> deliverables:
>
> - 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;
>
> - define a mechanism that allows communication of DNS resolver
> information to clients for use in selection decisions;
>
> - develop an informational document that describes how client
> applications and systems can manage selection of DNS resolvers
> in various network environments and use cases.
>
> This working group will coordinate with dnsop, doh, and dprive for any=
> changes required in DNS protocols. It will also work with capport to > ensure that solutions are applicable to captive networks.
>

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000437ffa059d855c67-- From nobody Sat Feb 1 13:36:20 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E3812008F; Sat, 1 Feb 2020 13:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClNixVlttlet; Sat, 1 Feb 2020 13:36:15 -0800 (PST) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D2A12004A; Sat, 1 Feb 2020 13:36:15 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id 011LWI2x043097; Sat, 1 Feb 2020 13:36:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=lA8vlEKJ7qaMhQNPIFZnzsjeuoW9Ed4BlA5h57JOUdY=; b=JZORIAzXaZOUzJdVHC00DkLu8a8BleuH1Lztwnp0udUMT9AkVLlwLXE1+or+PTGVZKFf oqQfXvonMScWkEGQx6opt2RXDyJ6KrBnjTyCjZbszGbYDl9BokRTHC5TwrDGoJJ/DdNi RHttISuQTayHG7j6c7kc4oCx6bwlhOKN2+kjSnEziun2G3Yoj0zWPWt68Se5hJxztMJ7 0dHegVHyaYk90h5ZZI7bAv10ufk14HyJ9W1bgy6EwqIjRiW/HToXUHp5IloBU6XCkk8Y 7lvMfpKjzpajEELX5SF+vbUdGb0XDF7kcx0Ka6t5GFKjdIHHjfQL8bG+JTlog82lYFsj aQ== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2xw952u0hv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 01 Feb 2020 13:36:13 -0800 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q5100G0CLCD3D40@rn-mailsvcp-mta-lapp04.rno.apple.com>; Sat, 01 Feb 2020 13:36:13 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q5100000L5DZC00@nwk-mmpp-sz12.apple.com>; Sat, 01 Feb 2020 13:36:13 -0800 (PST) X-Va-A: X-Va-T-CD: 6ca8ca8f63305df212074b411a74f5fb X-Va-E-CD: 8334c067597dbe6d319d09970b67c10c X-Va-R-CD: 1f698b5a705368b11f6c36875f76d28b X-Va-CD: 0 X-Va-ID: ab965f7e-5918-462d-ab02-47a00e5ddd06 X-V-A: X-V-T-CD: 6ca8ca8f63305df212074b411a74f5fb X-V-E-CD: 8334c067597dbe6d319d09970b67c10c X-V-R-CD: 1f698b5a705368b11f6c36875f76d28b X-V-CD: 0 X-V-ID: 801b1bfd-b894-4296-a7da-5b3690f4b419 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-01_07:,, signatures=0 Received: from [17.234.110.125] (unknown [17.234.110.125]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q510008VLC9IG80@nwk-mmpp-sz12.apple.com>; Sat, 01 Feb 2020 13:36:10 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <25D6C7B0-216E-46B3-A32F-B76988DB1A09@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_26948D40-2999-4E0C-A8EE-A777912C2645" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Sat, 01 Feb 2020 13:36:09 -0800 In-reply-to: Cc: Barry Leiba , ADD Mailing list , IESG To: Eric Rescorla References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-01_07:, , signatures=0 Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 21:36:18 -0000 --Apple-Mail=_26948D40-2999-4E0C-A8EE-A777912C2645 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 1, 2020, at 7:29 AM, Eric Rescorla wrote: >=20 >=20 > Hi folks, >=20 > I finally got around to reading this charter and while I appreciate > the effort that has gone into it, I don't think it's ready for prime > time. >=20 > The fundamental problem here is that the charter seems to be > conflating two very different types of discovery: >=20 > (1) Discovering the resolvers that are available on a specific > network or that the network would like a given client > to use (and potentially their policies). (as in > draft-ietf-dnsop-resolver-information or > draft-reddy-dprive-dprive-privacy-policy) >=20 > (2) Discovering the resolvers that a given domains would like > you to use to resolve them and their subdomains > (as in draft-pauly-dprive-adaptive-dns-privacy) >=20 > It's pretty hard to map these onto the list of work items. > =20 > - 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; >=20 > - define a mechanism that allows communication of DNS resolver > information to clients for use in selection decisions; >=20 > Perhaps the first bullet is intended to refer to (1), but the "public > Internet" text that is confusing here, because while the local network > might want to tell you about some server that happens to be on the > public Internet (e.g., it wants to point you to QuadX) that's not the > relevant point and not something that the client cares about [0]. > Similarly, the second bullet point might be intended to refer to (2) > but it doesn't have anything about per-domain information, so it might > just as well refer to something like > draft-ietf-dnsop-resolver-information. So, in both cases it just seems > like this charter conflates these cases. I would suggest changing the > bullets to be more like my list above. The first work item refers to discovery of the existence and identities = of resolvers, such as DoH URI template, for both the cases you list as = (1) and (2). The phrase for =E2=80=9Cpublic Internet=E2=80=9D is = intended to refer to resolvers that are generally available regardless = of your local network connection (not cases in which your local network = points to an address that happens to be QuadX); and the local and = private networks refers to resolvers that are available only locally or = based on some special property of the connectivity, such as a VPN or = enterprise network. So this covers the use of DHCP, RA, or DNS records = (as in draft-pauly-dprive-adaptive-dns-privacy) to identify resolvers. The second work item is about defining the mechanism by which = information (which could at some point include policy) about the = resolver is communicated to the host. For the per-domain use cases = described in draft-pauly-dprive-adaptive-dns-privacy, that information = mechanism helps identify the relevant domains; it also can include = draft-ietf-dnsop-resolver-information, = draft-reddy-dprive-dprive-privacy-policy. >=20 >=20 > The third bullet seems like it is edging pretty close to the > zone of controversy: >=20 > - develop an informational document that describes how client > applications and systems can manage selection of DNS resolvers > in various network environments and use cases. Can you clarify what controversy you see arising from this work item? = The intent here is to describe recommendations for how to work with = scenarios like VPNs, captive networks, locally-hosted network content, = etc, in a world where DoH is used both to local and public/remote = resolvers. >=20 > I supposed if this was just a laundry list of every idea anyone > had ever thought of, that might be OK, but in my experience > documents like this (1) do some selection of the mechanisms > and (2) want to list the pluses and minuses of each mechanism > and both of these seem like a recipe for the kind of argument > that this group has been having for some time. I would propose > striking this work item entirely. This is not at all intended to be a laundry list of multiple approaches = to the same use cases, with plusses and minuses. The key point in the = item is enumerating the *network environments and use cases* (like = captive networks, say) that should be considered by clients during = implementation. Thanks, Tommy >=20 > -Ekr >=20 >=20 > [0] It's possible that what this is referring to is somehow > discovering a set of viable QuadX resolvers, but that's yet > a third problem with its own solution and I doubt we are going > to be able to standardize that at all. >=20 >=20 >=20 > On Tue, Jan 28, 2020 at 7:41 AM Barry Leiba > wrote: > I have begun the chartering process with the charter below, modulo a > small edit by me in the last paragraph. >=20 > https://datatracker.ietf.org/doc/charter-ietf-add/ = >=20 > It would be good if we could have an estimated milestone based on the > assumption that this working group would be chartered by and meet at > IETF 107 in Vancouver. >=20 > Barry, ART AD >=20 > On Mon, Jan 27, 2020 at 4:13 PM Tommy Pauly > wrote: > > > > Hi ADD, > > > > As our discussion on the proposed charter has quieted down, I wanted = to send a brief update and summary. > > > > The main point of discussion was the paragraph on security = requirements that began "Any mechanisms that...". As many people stated = on the previous thread, the necessity for security considerations and = security area review in work produced by an IETF working group is = already well-established, so this text is not needed specifically in = this charter. There were some proposals to tweak the language, but on = the whole, it seems that we can live without that paragraph. > > > > Jari also had a good suggestion to include a sentence about the = impact of resolver selection (on reachability and privacy, etc). After = looking at adding that text, I am concerned that adding it to the = charter gets into too many details that really belong in the WG = documents, particularly around how to assess the "privacy" implications = of choosing one resolver over another. The charter does indicate that = these mechanisms are being used to "provide benefits to the security and = privacy of DNS data", and it does cover reachability with the example of = "a resolver may be able to resolve private or local names...". As such, = I'd prefer to not add any new sentence for now (and Jari indicated he = could live with the text as is!). > > > > I've included the updated proposal, which matches the previous = proposal and removes the text on security requirements. Based on the = previous thread, this should represent the consensus of the list. > > > > Barry, can you help get this started in the process of chartering? > > > > Best, > > Tommy > > > > > > > > Adaptive DNS Discovery (ADD) > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Proposed Working Group Charter > > > > Sending DNS messages over encrypted transports, as defined in DNS = over > > TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides > > benefits to the security and privacy of DNS data. Clients, such as > > applications and host operating systems, have started adopting these > > protocols to provide these user benefits. > > > > This working group will focus on discovery and selection of DNS = resolvers > > by DNS clients in a variety of networking environments, including = public > > networks, private networks, and VPNs; supporting both encrypted and > > unencrypted resolvers. > > > > Clients adopting encrypted DNS protocols need to determine which DNS > > servers support encrypted transports, and which server to use for = specific > > queries if multiple servers are available. These decisions can vary = based > > on the network environment, and also based on the content and = purpose of > > the client queries. > > > > Network operators that start offering DNS encryption on their = servers also > > need a way to indicate this support to clients. Communicating = information > > about resolver configuration and behavior allows clients to make = more > > informed decisions about which DNS servers to use. For example, a = resolver > > may be able to resolve private or local names as a split DNS server. > > > > The Adaptive DNS Discovery (ADD) working group will work on the = following > > deliverables: > > > > - 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; > > > > - define a mechanism that allows communication of DNS resolver > > information to clients for use in selection decisions; > > > > - develop an informational document that describes how client > > applications and systems can manage selection of DNS resolvers > > in various network environments and use cases. > > > > This working group will coordinate with dnsop, doh, and dprive for = any > > changes required in DNS protocols. It will also work with capport to > > ensure that solutions are applicable to captive networks. > > >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add = --Apple-Mail=_26948D40-2999-4E0C-A8EE-A777912C2645 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 1, 2020, at 7:29 AM, Eric Rescorla <ekr@rtfm.com> = wrote:


Hi folks,

I finally got around to reading this charter and while I = appreciate
the effort that has gone into it, I don't think = it's ready for prime
time.

The = fundamental problem here is that the charter seems to be
conflating two very different types of discovery:

(1) Discovering the resolvers that are = available on a specific
    network or that the = network would like a given client
    to use = (and potentially their policies). (as in
    = draft-ietf-dnsop-resolver-information or
    = draft-reddy-dprive-dprive-privacy-policy)

(2)= Discovering the resolvers that a given domains would like
    you to use to resolve them and their = subdomains
    (as in = draft-pauly-dprive-adaptive-dns-privacy)

It's= pretty hard to map these onto the list of work items.
   
   - 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;

   - define a mechanism that allows communication = of DNS resolver
   information to clients for = use in selection decisions;

Perhaps the = first bullet is intended to refer to (1), but the "public
Internet" text that is confusing here, because while the = local network
might want to tell you about some server = that happens to be on the
public Internet (e.g., it wants = to point you to QuadX) that's not the
relevant point and = not something that the client cares about [0].
Similarly, = the second bullet point might be intended to refer to (2)
but it doesn't have anything about per-domain information, so = it might
just as well refer to something like
draft-ietf-dnsop-resolver-information. So, in both cases it = just seems
like this charter conflates these cases. I = would suggest changing the
bullets to be more like my list = above.

The first work item refers to discovery of the = existence and identities of resolvers, such as DoH URI template, for = both the cases you list as (1) and (2). The phrase for =E2=80=9Cpublic = Internet=E2=80=9D is intended to refer to resolvers that are generally = available regardless of your local network connection (not cases in = which your local network points to an address that happens to be QuadX); = and the local and private networks refers to resolvers that are = available only locally or based on some special property of the = connectivity, such as a VPN or enterprise network. So this covers the = use of DHCP, RA, or DNS records (as in = draft-pauly-dprive-adaptive-dns-privacy) to identify = resolvers.

The second work item is = about defining the mechanism by which information (which could at some = point include policy) about the resolver is communicated to the host. = For the per-domain use cases described in = draft-pauly-dprive-adaptive-dns-privacy, that information mechanism = helps identify the relevant domains; it also can include = draft-ietf-dnsop-resolver-information, draft-reddy-dprive-dprive-priv= acy-policy.



The = third bullet seems like it is edging pretty close to the
zone of controversy:

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

Can you clarify what controversy you see arising = from this work item? The intent here is to describe recommendations for = how to work with scenarios like VPNs, captive networks, locally-hosted = network content, etc, in a world where DoH is used both to local and = public/remote resolvers.


I = supposed if this was just a laundry list of every idea anyone
had ever thought of, that might be OK, but in my = experience
documents like this (1) do some selection of = the mechanisms
and (2) want to list the pluses and minuses = of each mechanism
and both of these seem like a recipe for = the kind of argument
that this group has been having for = some time. I would propose
striking this work item = entirely.

This is not at all intended to be a laundry list = of multiple approaches to the same use cases, with plusses and minuses. = The key point in the item is enumerating the *network environments and = use cases* (like captive networks, say) that should be considered by = clients during implementation.

Thanks,
Tommy


-Ekr


[0] It's possible that what this is referring = to is somehow
discovering a set of viable QuadX resolvers, = but that's yet
a third problem with its own solution and I = doubt we are going
to be able to standardize that at = all.



On Tue, Jan = 28, 2020 at 7:41 AM Barry Leiba <barryleiba@computer.org> wrote:
I = have begun the chartering process with the charter below, modulo a
small edit by me in the last paragraph.

https://datatracker.ietf.org/doc/charter-ietf-add/

It would be good if we could have an estimated milestone based on the
assumption that this working group would be chartered by and meet at
IETF 107 in Vancouver.

Barry, ART AD

On Mon, Jan 27, 2020 at 4:13 PM Tommy Pauly <tpauly@apple.com> wrote:
>
> Hi ADD,
>
> As our discussion on the proposed charter has quieted down, I = wanted to send a brief update and summary.
>
> The main point of discussion was the paragraph on security = requirements that began "Any mechanisms that...". As many people stated = on the previous thread, the necessity for security considerations and = security area review in work produced by an IETF working group is = already well-established, so this text is not needed specifically in = this charter. There were some proposals to tweak the language, but on = the whole, it seems that we can live without that paragraph.
>
> Jari also had a good suggestion to include a sentence about the = impact of resolver selection (on reachability and privacy, etc). After = looking at adding that text, I am concerned that adding it to the = charter gets into too many details that really belong in the WG = documents, particularly around how to assess the "privacy" implications = of choosing one resolver over another. The charter does indicate that = these mechanisms are being used to "provide benefits to the security and = privacy of DNS data", and it does cover reachability with the example of = "a resolver may be able to resolve private or local names...". As such, = I'd prefer to not add any new sentence for now (and Jari indicated he = could live with the text as is!).
>
> I've included the updated proposal, which matches the previous = proposal and removes the text on security requirements. Based on the = previous thread, this should represent the consensus of the list.
>
> Barry, can you help get this started in the process of = chartering?
>
> Best,
> Tommy
>
>
>
> Adaptive DNS Discovery (ADD)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Proposed Working Group Charter
>
> Sending DNS messages over encrypted transports, as defined in DNS = over
> TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], = provides
> benefits to the security and privacy of DNS data. Clients, such = as
> applications and host operating systems, have started adopting = these
> protocols to provide these user benefits.
>
> This working group will focus on discovery and selection of DNS = resolvers
> by DNS clients in a variety of networking environments, including = public
> networks, private networks, and VPNs; supporting both encrypted = and
> unencrypted resolvers.
>
> Clients adopting encrypted DNS protocols need to determine which = DNS
> servers support encrypted transports, and which server to use for = specific
> queries if multiple servers are available. These decisions can vary = based
> on the network environment, and also based on the content and = purpose of
> the client queries.
>
> Network operators that start offering DNS encryption on their = servers also
> need a way to indicate this support to clients. Communicating = information
> about resolver configuration and behavior allows clients to make = more
> informed decisions about which DNS servers to use. For example, a = resolver
> may be able to resolve private or local names as a split DNS = server.
>
> The Adaptive DNS Discovery (ADD) working group will work on the = following
> deliverables:
>
> - 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;
>
> - define a mechanism that allows communication of DNS resolver
> information to clients for use in selection decisions;
= >
> - develop an informational document that describes how client
> applications and systems can manage selection of DNS resolvers
> in various network environments and use cases.
>
> This working group will coordinate with dnsop, doh, and dprive for = any
> changes required in DNS protocols. It will also work with capport = to
> ensure that solutions are applicable to captive networks.
>

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

= --Apple-Mail=_26948D40-2999-4E0C-A8EE-A777912C2645-- From nobody Sun Feb 2 00:09:41 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE524120019; Sun, 2 Feb 2020 00:09:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: add@ietf.org, add-chairs@ietf.org, add@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158063097885.11235.17143352157147989125.idtracker@ietfa.amsl.com> Date: Sun, 02 Feb 2020 00:09:38 -0800 Archived-At: Subject: [Add] =?utf-8?q?=C3=89ric_Vyncke=27s_Yes_on_charter-ietf-add-00-?= =?utf-8?q?00=3A_=28with_COMMENT=29?= X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 08:09:39 -0000 Éric Vyncke has entered the following ballot position for charter-ietf-add-00-00: Yes 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: ---------------------------------------------------------------------- Just one concern about the 3rd work items ("informational document that describes how client applications and systems can manage selection of DNS resolvers") which may end up in rat hole discussions. From nobody Sun Feb 2 07:48:46 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D917C12003F for ; Sun, 2 Feb 2020 07:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2FJpGWhuhLk for ; Sun, 2 Feb 2020 07:48:40 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63D3120100 for ; Sun, 2 Feb 2020 07:48:39 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id o15so6471806ljg.6 for ; Sun, 02 Feb 2020 07:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NgX5fPZyisOPveSYljcCvf9pMTiNLfqMAQo9p5urA4k=; b=NznaQZ6y365AYtnU1Vm4E5gSmfFO36OS3YEJOQlB4r+0TY1hX5keNNUX20khQdEZeE 9afQWWLn6LDyKi71xhfTFfDA7iRGegBDQOhPT09CvrJNYW+rZUMPCLc7IZc7TsbYTlxc 69qLS/jfEjiwz/LLB6923dt6zuPVJ9BgntTs26KmDPmSMUhTsYnZIUXk8jjZVXMNDNQq j8RbuhxVp+oXMaUlOCdiyKIFixMXuY6MRZN0OUBryffFJOJzsh2piB2ZhiYhVYyTVthy JTL7YfBbPLl61dYnWa2o2SaVTKdew6QVt17qwxxrvedzbzQrfEz82Ofi8JYGu+WMDDkm 0aKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NgX5fPZyisOPveSYljcCvf9pMTiNLfqMAQo9p5urA4k=; b=GOvUTs41XAvJkzsussrxS0F3ZNwjnT38RIsnhdG1OHOut1Ioe5BvVrHWmHViIxqSlf OBdZUty8nd2BqIpI0Ct3ja3Lzx++JyAZrVdlqFIvxWu/e+GEv0NL+vvEHozsr5Lcht0D 1vTwlhQB4kM5zgnd+uhjoo38S5U/AVgZ8AQ2oIQvbrA4j0tz01rZbfc58bT/CfR2L1Bl XIw9V/6MbZBQM4P60wlmKc0LSPAVh19UZ31PMV1VjB2Fgeq7z8XhFAYWXVbOfsrZE2Me 8ezL3rWy+vWfrUellR5z044tU6tOB/K6vbevYCnku3fJMiAhHh6ZmsRTdaoPYVFAUDfU oBOw== X-Gm-Message-State: APjAAAVyINZQOZGQHeHj3PdZNig1HaXCZi4Ue4g1mAYdKox5kzwDcMjl mo6Phn6dLjsWzhEd4kI9nhKeXdZx9OIJOQMrcRcaqDA/GlI= X-Google-Smtp-Source: APXvYqx39LgM+m60mVfl8JJfhdk3dDs3fimPvG7PgBcykdFJV3+RwRQYmBe8CvCWr9TRYFRFnt4VHIxRbi0iH1UTKnA= X-Received: by 2002:a2e:b5a5:: with SMTP id f5mr11114915ljn.162.1580658518169; Sun, 02 Feb 2020 07:48:38 -0800 (PST) MIME-Version: 1.0 References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> <25D6C7B0-216E-46B3-A32F-B76988DB1A09@apple.com> In-Reply-To: <25D6C7B0-216E-46B3-A32F-B76988DB1A09@apple.com> From: Eric Rescorla Date: Sun, 2 Feb 2020 07:48:02 -0800 Message-ID: To: Tommy Pauly Cc: Barry Leiba , ADD Mailing list , IESG Content-Type: multipart/alternative; boundary="0000000000007cad3e059d99bdb5" Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 15:48:44 -0000 --0000000000007cad3e059d99bdb5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tommy, Thanks for your note. Before we get into the details, I would observe that my understanding of the charter text seems pretty divergent from your intent. I think this is a fairly strong signal that the text needs: if a charter doesn't describe the work to be done sufficiently precisely that someone familiar with field can understand it, then it's not doing its job. With that said, now that I understand your intent, I also have severe misgivings about some of the proposed work, as noted below. > > On Feb 1, 2020, at 7:29 AM, Eric Rescorla wrote: > > > > > > Hi folks, > > > > I finally got around to reading this charter and while I appreciate > > the effort that has gone into it, I don't think it's ready for prime > > time. > > > > The fundamental problem here is that the charter seems to be > > conflating two very different types of discovery: > > > > (1) Discovering the resolvers that are available on a specific > > network or that the network would like a given client > > to use (and potentially their policies). (as in > > draft-ietf-dnsop-resolver-information or > > draft-reddy-dprive-dprive-privacy-policy) > > > > (2) Discovering the resolvers that a given domains would like > > you to use to resolve them and their subdomains > > (as in draft-pauly-dprive-adaptive-dns-privacy) > > > > It's pretty hard to map these onto the list of work items. > > > > - 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; > > > > - define a mechanism that allows communication of DNS resolver > > information to clients for use in selection decisions; > > > > Perhaps the first bullet is intended to refer to (1), but the "public > > Internet" text that is confusing here, because while the local network > > might want to tell you about some server that happens to be on the > > public Internet (e.g., it wants to point you to QuadX) that's not the > > relevant point and not something that the client cares about [0]. > > Similarly, the second bullet point might be intended to refer to (2) > > but it doesn't have anything about per-domain information, so it might > > just as well refer to something like > > draft-ietf-dnsop-resolver-information. So, in both cases it just seems > > like this charter conflates these cases. I would suggest changing the > > bullets to be more like my list above. > > The first work item refers to discovery of the existence and > identities of resolvers, such as DoH URI template, for both the cases > you list as (1) and (2). The phrase for =E2=80=9Cpublic Internet=E2=80=9D= is intended > to refer to resolvers that are generally available regardless of your > local network connection (not cases in which your local network points > to an address that happens to be QuadX); I don't understand what work you are contemplating here: some sort of public directory which lists QuadX and similar resolvers and their properties? Is there demand for such a thing? At least from the perspective of Firefox, I don't see how this would be useful. Even for clients which don't intend to operate some kind of TRR-style program, it seems clear that there are going to be some malicious resolvers in this directory; how would you know which ones they were? In any case, this seems like a completely different problem from learning the resolver offerings/preferences for a given local network, so these should be separate work items, not merged into one bullet. > The second work item is about defining the mechanism by which > information (which could at some point include policy) about the > resolver is communicated to the host. For the per-domain use cases > described in draft-pauly-dprive-adaptive-dns-privacy, that information > mechanism helps identify the relevant domains; it also can include > draft-ietf-dnsop-resolver-information, > draft-reddy-dprive-dprive-privacy-policy. This seems to have a specific architecture in mind which is not necessarily the right architecture. I.e., one could define a system in which you learn about a resolver and then learn about its properteis from it (as you suggest here) or one in which you learn about a resolver *and* its properties and then decide whether to use it. This latter design is more attractive in a number of cases, so I don't think that we ought to predecide it in the charter. Here too, draft-pauly and the other drafts seem designed for totally different use cases and therefore should be seperate work items. > > The third bullet seems like it is edging pretty close to the > > zone of controversy: > > > > - develop an informational document that describes how client > > applications and systems can manage selection of DNS resolvers > > in various network environments and use cases. > > Can you clarify what controversy you see arising from this work item? > The intent here is to describe recommendations for how to work with > scenarios like VPNs, captive networks, locally-hosted network content, > etc, in a world where DoH is used both to local and public/remote > resolvers. Well, here too, we have a lack of clarity in the text, so I don't know what's buried in your "etc.". One case I am concerned about is one in which the network wishes to communicate that it wants you to use a specific resolver but the client decides to ignore that. This is clearly contested ground. > > I supposed if this was just a laundry list of every idea anyone > > had ever thought of, that might be OK, but in my experience > > documents like this (1) do some selection of the mechanisms > > and (2) want to list the pluses and minuses of each mechanism > > and both of these seem like a recipe for the kind of argument > > that this group has been having for some time. I would propose > > striking this work item entirely. > > This is not at all intended to be a laundry list of multiple > approaches to the same use cases, with plusses and minuses. The key > point in the item is enumerating the *network environments and use > cases* (like captive networks, say) that should be considered by > clients during implementation. Well, the text says "hoc client applications and systems can manage", so it's clearly rather more than just enumeration. -Ekr --0000000000007cad3e059d99bdb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tommy,

Thanks for your note.

Before we get i= nto the details, I would observe that my understanding
of the charter te= xt seems pretty divergent from your intent. I think
this is a fairly str= ong signal that the text needs: if a charter
doesn't describe the wo= rk to be done sufficiently precisely that
someone familiar with field ca= n understand it, then it's not doing its
job.

With that said,= now that I understand your intent, I also have severe
misgivings about = some of the proposed work, as noted below.


> > On Feb 1, 2= 020, at 7:29 AM, Eric Rescorla <ekr@rtfm= .com> wrote:
> >
> >
> > Hi folks,
>= ; >
> > I finally got around to reading this charter and while = I appreciate
> > the effort that has gone into it, I don't thi= nk it's ready for prime
> > time.
> >
> > Th= e fundamental problem here is that the charter seems to be
> > con= flating two very different types of discovery:
> >
> > (1= ) Discovering the resolvers that are available on a specific
> > = =C2=A0 =C2=A0 network or that the network would like a given client
>= > =C2=A0 =C2=A0 to use (and potentially their policies). (as in
>= > =C2=A0 =C2=A0 draft-ietf-dnsop-resolver-information or
> > = =C2=A0 =C2=A0 draft-reddy-dprive-dprive-privacy-policy)
> >
>= ; > (2) Discovering the resolvers that a given domains would like
>= ; > =C2=A0 =C2=A0 you to use to resolve them and their subdomains
>= ; > =C2=A0 =C2=A0 (as in draft-pauly-dprive-adaptive-dns-privacy)
>= ; >
> > It's pretty hard to map these onto the list of work= items.
> > =C2=A0 =C2=A0
> > =C2=A0 =C2=A0- define a mec= hanism that allows clients to discover DNS resolvers,
> > =C2=A0 = =C2=A0including encrypted DNS servers, that are available to the client
= > > =C2=A0 =C2=A0either on the public Internet or on private or local= networks;
> >
> > =C2=A0 =C2=A0- define a mechanism that= allows communication of DNS resolver
> > =C2=A0 =C2=A0information= to clients for use in selection decisions;
> >
> > Perha= ps the first bullet is intended to refer to (1), but the "public
&g= t; > Internet" text that is confusing here, because while the local= network
> > might want to tell you about some server that happens= to be on the
> > public Internet (e.g., it wants to point you to = QuadX) that's not the
> > relevant point and not something tha= t the client cares about [0].
> > Similarly, the second bullet poi= nt might be intended to refer to (2)
> > but it doesn't have a= nything about per-domain information, so it might
> > just as well= refer to something like
> > draft-ietf-dnsop-resolver-information= . So, in both cases it just seems
> > like this charter conflates = these cases. I would suggest changing the
> > bullets to be more l= ike my list above.
>
> The first work item refers to discovery= of the existence and
> identities of resolvers, such as DoH URI temp= late, for both the cases
> you list as (1) and (2). The phrase for = =E2=80=9Cpublic Internet=E2=80=9D is intended
> to refer to resolvers= that are generally available regardless of your
> local network conn= ection (not cases in which your local network points
> to an address = that happens to be QuadX);

I don't understand what work you are = contemplating here: some sort of
public directory which lists QuadX and = similar resolvers and their
properties? Is there demand for such a thing= ? At least from the
perspective of Firefox, I don't see how this wou= ld be useful.
Even for clients which don't intend to operate some ki= nd of
TRR-style program, it seems clear that there are going to be
so= me malicious resolvers in this directory; how would you know
which ones = they were?

In any case, this seems like a completely different probl= em
from learning the resolver offerings/preferences for a given
local= network, so these should be separate work items, not
merged into one bu= llet.


> The second work item is about defining the mechanism = by which
> information (which could at some point include policy) abo= ut the
> resolver is communicated to the host. For the per-domain use= cases
> described in draft-pauly-dprive-adaptive-dns-privacy, that i= nformation
> mechanism helps identify the relevant domains; it also c= an include
> draft-ietf-dnsop-resolver-information,
> draft-red= dy-dprive-dprive-privacy-policy.

This seems to have a specific archi= tecture in mind which is not
necessarily the right architecture. I.e., o= ne could define
a system in which you learn about a resolver and then le= arn
about its properteis from it (as you suggest here) or one in
whic= h you learn about a resolver *and* its properties and then
decide whethe= r to use it. This latter design is more attractive
in a number of cases,= so I don't think that we ought to predecide
it in the charter.
<= br>Here too, draft-pauly and the other drafts seem designed for
totally = different use cases and therefore should be seperate
work items.

=
> > The third bullet seems like it is edging pretty close to the<= br>> > zone of controversy:
> >
> > =C2=A0 =C2=A0- = develop an informational document that describes how client
> > = =C2=A0 =C2=A0applications and systems can manage selection of DNS resolvers=
> > =C2=A0 =C2=A0in various network environments and use cases.>
> Can you clarify what controversy you see arising from this = work item?
> The intent here is to describe recommendations for how t= o work with
> scenarios like VPNs, captive networks, locally-hosted n= etwork content,
> etc, in a world where DoH is used both to local and= public/remote
> resolvers.

Well, here too, we have a lack of = clarity in the text, so I
don't know what's buried in your "= ;etc.". One case
I am concerned about is one in which the network w= ishes
to communicate that it wants you to use a specific resolver
but= the client decides to ignore that. This is clearly
contested ground.

> > I supposed if this was just a laundry list of every idea= anyone
> > had ever thought of, that might be OK, but in my exper= ience
> > documents like this (1) do some selection of the mechani= sms
> > and (2) want to list the pluses and minuses of each mechan= ism
> > and both of these seem like a recipe for the kind of argum= ent
> > that this group has been having for some time. I would pro= pose
> > striking this work item entirely.
>
> This i= s not at all intended to be a laundry list of multiple
> approaches t= o the same use cases, with plusses and minuses. The key
> point in th= e item is enumerating the *network environments and use
> cases* (lik= e captive networks, say) that should be considered by
> clients durin= g implementation.

Well, the text says "hoc client applications = and systems can manage",
so it's clearly rather more than just = enumeration.

-Ekr
--0000000000007cad3e059d99bdb5-- From nobody Sun Feb 2 12:04:38 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436EA12004D; Sun, 2 Feb 2020 12:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOaB5Oa8H1dx; Sun, 2 Feb 2020 12:04:29 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EAB6120033; Sun, 2 Feb 2020 12:04:29 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 012K28K7037778; Sun, 2 Feb 2020 12:04:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=3doOs1PS5bWPpMbz3yEvPdm96rIo4WF64Jcvmlsg5b0=; b=roTh/yuWznU64ezcf7OF6eylpcMDHr6+2kdbDsqFmIC4a4T1fIDfnXa6uwOlX0+FwFJq zYw/bkRt7SXteBVxxzdo3Om4w2n8vjadC3aMvHSR4PXUXZ1qUWzQibT0johripYmZXF5 9nqgS4fqR6iqXBA6loALhi9CzidcKdA3rGdwj1m08bL3ElTRrpp0Od5PJ2EmgjBZZ0JY vmx9Vv+WCkg0PSV6l4PVUSTfygGSDIysDBlORhQuUm1Mrae4VMD1h1GYk7I/lZTdUcW4 nU6QGHQT0eEuktgHhLoW8GQJMmZQwFT4oGRMOWhw2colWrIbdDH16wbbyMYTboefFwjy EA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2xw6vwrrfv-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 02 Feb 2020 12:04:26 -0800 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q53001Z2BREX320@rn-mailsvcp-mta-lapp04.rno.apple.com>; Sun, 02 Feb 2020 12:04:26 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q5300B00B6HIX00@nwk-mmpp-sz13.apple.com>; Sun, 02 Feb 2020 12:04:26 -0800 (PST) X-Va-A: X-Va-T-CD: 6ca8ca8f63305df212074b411a74f5fb X-Va-E-CD: 8334c067597dbe6d319d09970b67c10c X-Va-R-CD: 1f698b5a705368b11f6c36875f76d28b X-Va-CD: 0 X-Va-ID: 7502135a-36d0-4468-9a10-fc3969aeb3f0 X-V-A: X-V-T-CD: 6ca8ca8f63305df212074b411a74f5fb X-V-E-CD: 8334c067597dbe6d319d09970b67c10c X-V-R-CD: 1f698b5a705368b11f6c36875f76d28b X-V-CD: 0 X-V-ID: e22d4c18-0965-4e92-9008-089ac4d8b5af X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-02_07:,, signatures=0 Received: from [17.234.29.189] (unknown [17.234.29.189]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q530067LBRAGI20@nwk-mmpp-sz13.apple.com>; Sun, 02 Feb 2020 12:04:23 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <4DB16752-C63B-4348-83AB-ED95FDB07B9E@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_16967F44-9D45-455B-8A3F-DB16346C9FB9" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Sun, 02 Feb 2020 12:04:22 -0800 In-reply-to: Cc: Barry Leiba , ADD Mailing list , IESG To: Eric Rescorla References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> <25D6C7B0-216E-46B3-A32F-B76988DB1A09@apple.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-02_07:, , signatures=0 Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 20:04:32 -0000 --Apple-Mail=_16967F44-9D45-455B-8A3F-DB16346C9FB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ekr, Thanks for the further comments! Responses inline, but as a general comment, I think the proposed charter = text is more open-ended than some of the points you=E2=80=99re bringing = up. It intentionally is not trying to prescribe the technical solutions = or how those solutions will be arranged, but rather the solution space = that a working group can focus on. To that end, tweaking the wording to = not imply solutions that are not meant to be implied is definitely = useful, but I=E2=80=99m not sure it would be good to define too many = protocol details in the charter text.=20 > On Feb 2, 2020, at 7:48 AM, Eric Rescorla wrote: >=20 > Tommy, >=20 > Thanks for your note. >=20 > Before we get into the details, I would observe that my understanding > of the charter text seems pretty divergent from your intent. I think > this is a fairly strong signal that the text needs: if a charter > doesn't describe the work to be done sufficiently precisely that > someone familiar with field can understand it, then it's not doing its > job. >=20 > With that said, now that I understand your intent, I also have severe > misgivings about some of the proposed work, as noted below. >=20 >=20 > > > On Feb 1, 2020, at 7:29 AM, Eric Rescorla > wrote: > > > > > The first work item refers to discovery of the existence and > > identities of resolvers, such as DoH URI template, for both the = cases > > you list as (1) and (2). The phrase for =E2=80=9Cpublic Internet=E2=80= =9D is intended > > to refer to resolvers that are generally available regardless of = your > > local network connection (not cases in which your local network = points > > to an address that happens to be QuadX); >=20 > I don't understand what work you are contemplating here: some sort of > public directory which lists QuadX and similar resolvers and their > properties? Is there demand for such a thing? At least from the > perspective of Firefox, I don't see how this would be useful. > Even for clients which don't intend to operate some kind of > TRR-style program, it seems clear that there are going to be > some malicious resolvers in this directory; how would you know > which ones they were? >=20 > In any case, this seems like a completely different problem > from learning the resolver offerings/preferences for a given > local network, so these should be separate work items, not > merged into one bullet. This charter isn=E2=80=99t proposing some public directory or list. I = agree that such a list doesn=E2=80=99t really make sense, and I don=E2=80=99= t know of anyone asking for that. Your quoted text removed the portion of the response that was probably = most relevant for explaining the intent: "this covers the use of DHCP, = RA, or DNS records... to identify resolvers.=E2=80=9D It=E2=80=99s up to = whatever group forms to decide what to do, but at the most basic this = would imply that a client could learn from a local network if the local = resolver supports DoH, and what the DoH URI Template is for that case; = and if the client device is pointed (say, by user selection) to a public = resolver like a QuadX, that it could learn what the DoH URI Template for = that is as well. The point of this is to not require big lists of resolvers. The details = of mechanism, though, need to be left to the group discussion. >=20 >=20 > > The second work item is about defining the mechanism by which > > information (which could at some point include policy) about the > > resolver is communicated to the host. For the per-domain use cases > > described in draft-pauly-dprive-adaptive-dns-privacy, that = information > > mechanism helps identify the relevant domains; it also can include > > draft-ietf-dnsop-resolver-information, > > draft-reddy-dprive-dprive-privacy-policy. >=20 > This seems to have a specific architecture in mind which is not > necessarily the right architecture. I.e., one could define > a system in which you learn about a resolver and then learn > about its properteis from it (as you suggest here) or one in > which you learn about a resolver *and* its properties and then > decide whether to use it. This latter design is more attractive > in a number of cases, so I don't think that we ought to predecide > it in the charter. >=20 > Here too, draft-pauly and the other drafts seem designed for > totally different use cases and therefore should be seperate > work items. I agree that these details shouldn=E2=80=99t be predecided in the = charter, and I don=E2=80=99t think they are. The charter proposal = doesn=E2=80=99t preclude the mechanisms for resolver discovery and = information being in the same document, or in separate documents. The reason this is listed as separate from discovering the existence of = resolvers is to be clear that having a way to look up the properties of = a resolver is something that may be desirable even for cases in which = clients already have some hardcoded list of resolvers they know about. = For example, if like Firefox, a browser knew about some public trusted = resolvers, being able to query those resolvers about information such as = keys for making oblivious queries is something that ought to be done in = a standard fashion. I definitely think that in many cases, the existence and applicability = of a resolver should be done in the same step, but the details should be = worked out by the group, not dictated by a charter. >=20 >=20 > > > The third bullet seems like it is edging pretty close to the > > > zone of controversy: > > > > > > - develop an informational document that describes how client > > > applications and systems can manage selection of DNS resolvers > > > in various network environments and use cases. > >=20 > > Can you clarify what controversy you see arising from this work = item? > > The intent here is to describe recommendations for how to work with > > scenarios like VPNs, captive networks, locally-hosted network = content, > > etc, in a world where DoH is used both to local and public/remote > > resolvers. >=20 > Well, here too, we have a lack of clarity in the text, so I > don't know what's buried in your "etc.". One case > I am concerned about is one in which the network wishes > to communicate that it wants you to use a specific resolver > but the client decides to ignore that. This is clearly > contested ground. Got it. Yes, I imagine that if a group tried to give recommendations = around whether or not clients can ignore network policy, it would be = difficult to quickly come to an agreement. However, I don=E2=80=99t = think that (a) a charter should make it out of scope to touch on that = topic if the group decided that it actually could do useful work there, = or that (b) a charter should preclude the group from working on the = recommendations and descriptions for cases that are not as contentious = that still need explanation, such as how to deal correctly with captive = networks, VPNs, and private networks. >=20 >=20 > > > I supposed if this was just a laundry list of every idea anyone > > > had ever thought of, that might be OK, but in my experience > > > documents like this (1) do some selection of the mechanisms > > > and (2) want to list the pluses and minuses of each mechanism > > > and both of these seem like a recipe for the kind of argument > > > that this group has been having for some time. I would propose > > > striking this work item entirely. > >=20 > > This is not at all intended to be a laundry list of multiple > > approaches to the same use cases, with plusses and minuses. The key > > point in the item is enumerating the *network environments and use > > cases* (like captive networks, say) that should be considered by > > clients during implementation. >=20 > Well, the text says "hoc client applications and systems can manage", > so it's clearly rather more than just enumeration. Yes, indeed. My point here was that any document here wouldn=E2=80=99t = be enumerating *possible approaches*, as you suggested, but would be = enumerating the *network scenarios* clients need to handle. Clients managing selection of resolvers would, for example, include the = fact that a probe for a captive portal trigger page needs to use the = locally-provisioned DNS resolver, even if user-facing traffic is = otherwise bound to some other encrypted public resolver. Thanks, Tommy >=20 > -Ekr > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --Apple-Mail=_16967F44-9D45-455B-8A3F-DB16346C9FB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ekr,

Thanks for the = further comments!

Responses = inline, but as a general comment, I think the proposed charter text is = more open-ended than some of the points you=E2=80=99re bringing up. It = intentionally is not trying to prescribe the technical solutions or how = those solutions will be arranged, but rather the solution space that a = working group can focus on. To that end, tweaking the wording to not = imply solutions that are not meant to be implied is definitely useful, = but I=E2=80=99m not sure it would be good to define too many protocol = details in the charter text. 

On Feb 2, 2020, at 7:48 AM, = Eric Rescorla <ekr@rtfm.com> wrote:

Tommy,

Thanks for your note.

Before we get into the details, I would = observe that my understanding
of the charter text seems = pretty divergent from your intent. I think
this is a = fairly strong signal that the text needs: if a charter
doesn't describe the work to be done sufficiently precisely = that
someone familiar with field can understand it, then = it's not doing its
job.

With = that said, now that I understand your intent, I also have severe
misgivings about some of the proposed work, as noted = below.


> > On Feb 1, = 2020, at 7:29 AM, Eric Rescorla <ekr@rtfm..com> wrote:
> >
> The first work item refers to discovery of the existence = and
> identities of resolvers, such as DoH URI = template, for both the cases
> you list as (1) and (2). = The phrase for =E2=80=9Cpublic Internet=E2=80=9D is intended
> to refer to resolvers that are generally available = regardless of your
> local network connection (not = cases in which your local network points
> to an = address that happens to be QuadX);

I don't = understand what work you are contemplating here: some sort of
public directory which lists QuadX and similar resolvers and = their
properties? Is there demand for such a thing? At = least from the
perspective of Firefox, I don't see how = this would be useful.
Even for clients which don't intend = to operate some kind of
TRR-style program, it seems clear = that there are going to be
some malicious resolvers in = this directory; how would you know
which ones they = were?

In any case, this seems like a = completely different problem
from learning the resolver = offerings/preferences for a given
local network, so these = should be separate work items, not
merged into one = bullet.

This charter isn=E2=80=99t proposing some public = directory or list. I agree that such a list doesn=E2=80=99t really make = sense, and I don=E2=80=99t know of anyone asking for that.

Your quoted text removed the portion of the = response that was probably most relevant for explaining the intent: = "this covers the use of DHCP, RA, or DNS records... to identify = resolvers.=E2=80=9D It=E2=80=99s up to whatever group forms to decide = what to do, but at the most basic this would imply that a client could = learn from a local network if the local resolver supports DoH, and what = the DoH URI Template is for that case; and if the client device is = pointed (say, by user selection) to a public resolver like a QuadX, that = it could learn what the DoH URI Template for that is as = well.

The point of this is to not = require big lists of resolvers. The details of mechanism, though, need = to be left to the group discussion.



> The second work item is about defining = the mechanism by which
> information (which could at = some point include policy) about the
> resolver is = communicated to the host. For the per-domain use cases
> = described in draft-pauly-dprive-adaptive-dns-privacy, that = information
> mechanism helps identify the relevant = domains; it also can include
> = draft-ietf-dnsop-resolver-information,
> = draft-reddy-dprive-dprive-privacy-policy.

This seems to have a specific architecture in mind which is = not
necessarily the right architecture. I.e., one could = define
a system in which you learn about a resolver and = then learn
about its properteis from it (as you suggest = here) or one in
which you learn about a resolver *and* its = properties and then
decide whether to use it. This latter = design is more attractive
in a number of cases, so I don't = think that we ought to predecide
it in the charter.

Here too, draft-pauly and the other drafts = seem designed for
totally different use cases and = therefore should be seperate
work items.

I agree = that these details shouldn=E2=80=99t be predecided in the charter, and I = don=E2=80=99t think they are. The charter proposal doesn=E2=80=99t = preclude the mechanisms for resolver discovery and information being in = the same document, or in separate documents.

The reason this is listed as separate from = discovering the existence of resolvers is to be clear that having a way = to look up the properties of a resolver is something that may be = desirable even for cases in which clients already have some hardcoded = list of resolvers they know about. For example, if like Firefox, a = browser knew about some public trusted resolvers, being able to query = those resolvers about information such as keys for making oblivious = queries is something that ought to be done in a standard = fashion.

I definitely think that in = many cases, the existence and applicability of a resolver should be done = in the same step, but the details should be worked out by the group, not = dictated by a charter.



> > The third bullet seems like it is edging pretty = close to the
> > zone of controversy:
> >
> >    - develop an = informational document that describes how client
> > =    applications and systems can manage selection of DNS = resolvers
> >    in various network = environments and use cases.
>
> Can = you clarify what controversy you see arising from this work item?
> The intent here is to describe recommendations for how = to work with
> scenarios like VPNs, captive networks, = locally-hosted network content,
> etc, in a world where = DoH is used both to local and public/remote
> = resolvers.

Well, here too, we have a lack = of clarity in the text, so I
don't know what's buried in = your "etc.". One case
I am concerned about is one in which = the network wishes
to communicate that it wants you to use = a specific resolver
but the client decides to ignore that. = This is clearly
contested ground.

Got = it. Yes, I imagine that if a group tried to give recommendations around = whether or not clients can ignore network policy, it would be difficult = to quickly come to an agreement. However, I don=E2=80=99t think that (a) = a charter should make it out of scope to touch on that topic if the = group decided that it actually could do useful work there, or that (b) a = charter should preclude the group from working on the recommendations = and descriptions for cases that are not as contentious that still need = explanation, such as how to deal correctly with captive networks, VPNs, = and private networks.



> > I supposed if this was just a laundry list of every = idea anyone
> > had ever thought of, that might be = OK, but in my experience
> > documents like this (1) = do some selection of the mechanisms
> > and (2) want = to list the pluses and minuses of each mechanism
> > = and both of these seem like a recipe for the kind of argument
> > that this group has been having for some time. I = would propose
> > striking this work item = entirely.
>
> This is not at all = intended to be a laundry list of multiple
> approaches = to the same use cases, with plusses and minuses. The key
> point in the item is enumerating the *network = environments and use
> cases* (like captive networks, = say) that should be considered by
> clients during = implementation.

Well, the text says "hoc = client applications and systems can manage",
so it's = clearly rather more than just enumeration.

Yes, = indeed. My point here was that any document here wouldn=E2=80=99t be = enumerating *possible approaches*, as you suggested, but would be = enumerating the *network scenarios* clients need to = handle.

Clients managing selection = of resolvers would, for example, include the fact that a probe for a = captive portal trigger page needs to use the locally-provisioned DNS = resolver, even if user-facing traffic is otherwise bound to some other = encrypted public resolver.

Thanks,
Tommy


-Ekr
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

= --Apple-Mail=_16967F44-9D45-455B-8A3F-DB16346C9FB9-- From nobody Sun Feb 2 20:41:45 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7901208A9 for ; Sun, 2 Feb 2020 20:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H94vhs02pP8i for ; Sun, 2 Feb 2020 20:41:40 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC94D120890 for ; Sun, 2 Feb 2020 20:41:39 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id z26so8647280lfg.13 for ; Sun, 02 Feb 2020 20:41:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wd6Y8nv1lShg6Ru3LHOKiGzn3vV8cfT155iFYKJyUpQ=; b=D/4ojcsGhIzzL6Zc5YoLb29J5J+8lhWfKq63p+WCsYrPr5KNK1AmJVlpk6oyxTNhVG ui5exb7o5GanJeslXHCrx+6y+SRRuQdkY9r4zYjW0jc6mikLamZhXmsZvdJS/45McQdk iWnuSXjfPDk6RFEJXCvgJR5lP3txlbTq4B0Xc4q2GflKdqAnPxAsXJwlvLjJuVijdL00 HR/cUhxdeTU3kPu5lOx7Us6cCb+LxZSCYmuudhrPULs4n9Lgv97Apk/mjvM4sVDx7VYa 9UkLAyobrUQwqe21KHnvEWA3Wj2vDE20SMjZYGJwEZvniD3Yxj2WN+ksdnHrztyHr+sB QeZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wd6Y8nv1lShg6Ru3LHOKiGzn3vV8cfT155iFYKJyUpQ=; b=f1ogge/E85qLxVEuWjyozRtZBHs4kiR5dYENNzUt2W4vwpoNM8dr9Bugnd/qhY8A62 i3QUMtn9uwOvySXxJYW8wz0kdN1dtot5ggO47AxKJAinT3o/1Bvl7f1vws+u8DpVRXM4 K1wCcOvddpc/BsPNAuzeQvmDcILjZvCwZ3hoOlwDMaY51lZTvBz7dSveiuVc7gTl2x09 U9ZbAut8ftrYAaC7BFvb4qwN+yAZy8AXDUr56zY3eGt0UNAdUY9lAv90pwM/Yica3u7G Uv6aeVakvyRraHGxBmkq9GA+QSCDXPvYzOLClftfll140+97+njMue2uKpuofhqeQ8YR NEYw== X-Gm-Message-State: APjAAAXntU4HgCGT8vFHT5HfOXuA0Ed5t+XAeHcRbr96KHv00c4pRCs8 ydlk7KRFpF33Xp8w7Nt3Vgcdn3MEvIb/ZUYVajDiaw== X-Google-Smtp-Source: APXvYqwrtBZyErhZKW6Nl6DsTkEsljS49Hk7LtZJshjIPz8l9PhJpVZibtAqiX9N+HslwRK/Mlod/Z+w2H8KgDwLVYU= X-Received: by 2002:a19:cb17:: with SMTP id b23mr11104803lfg.201.1580704898159; Sun, 02 Feb 2020 20:41:38 -0800 (PST) MIME-Version: 1.0 References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> <25D6C7B0-216E-46B3-A32F-B76988DB1A09@apple.com> <4DB16752-C63B-4348-83AB-ED95FDB07B9E@apple.com> In-Reply-To: <4DB16752-C63B-4348-83AB-ED95FDB07B9E@apple.com> From: Eric Rescorla Date: Sun, 2 Feb 2020 20:41:01 -0800 Message-ID: To: Tommy Pauly Cc: Barry Leiba , ADD Mailing list , IESG Content-Type: multipart/alternative; boundary="000000000000f32539059da489f1" Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 04:41:43 -0000 --000000000000f32539059da489f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Feb 2, 2020 at 12:04 PM Tommy Pauly wrote: > Hi Ekr, > > Thanks for the further comments! > > Responses inline, but as a general comment, I think the proposed charter > text is more open-ended than some of the points you=E2=80=99re bringing u= p. > Yes. I am arguing against that. A charter is a contract between the WG and the IESG and contracts need to be crisp. This is not. It intentionally is not trying to prescribe the technical solutions or how > those solutions will be arranged, but rather the solution space that a > working group can focus on. > Yes, but I don't agree that we should be working in some of the space this lays out. To that end, tweaking the wording to not imply solutions that are not meant > to be implied is definitely useful, but I=E2=80=99m not sure it would be = good to > define too many protocol details in the charter text. > I'm not trying to define protocol details. > > > > On Feb 1, 2020, at 7:29 AM, Eric Rescorla > wrote: > > > > > The first work item refers to discovery of the existence and > > identities of resolvers, such as DoH URI template, for both the cases > > you list as (1) and (2). The phrase for =E2=80=9Cpublic Internet=E2=80= =9D is intended > > to refer to resolvers that are generally available regardless of your > > local network connection (not cases in which your local network points > > to an address that happens to be QuadX); > > I don't understand what work you are contemplating here: some sort of > public directory which lists QuadX and similar resolvers and their > properties? Is there demand for such a thing? At least from the > perspective of Firefox, I don't see how this would be useful. > Even for clients which don't intend to operate some kind of > TRR-style program, it seems clear that there are going to be > some malicious resolvers in this directory; how would you know > which ones they were? > > In any case, this seems like a completely different problem > from learning the resolver offerings/preferences for a given > local network, so these should be separate work items, not > merged into one bullet. > > > This charter isn=E2=80=99t proposing some public directory or list. I agr= ee that > such a list doesn=E2=80=99t really make sense, and I don=E2=80=99t know o= f anyone asking > for that. > > Your quoted text removed the portion of the response that was probably > most relevant for explaining the intent: "this covers the use of DHCP, RA= , > or DNS records... to identify resolvers.=E2=80=9D It=E2=80=99s up to what= ever group forms > to decide what to do, but at the most basic this would imply that a clien= t > could learn from a local network if the local resolver supports DoH, and > what the DoH URI Template is for that case; > Yes, this makes sense. and if the client device is pointed (say, by user selection) to a public > resolver like a QuadX, that it could learn what the DoH URI Template for > that is as well. > Why would you want this and why would you trust the network for that information? The point of this is to not require big lists of resolvers. The details of > mechanism, though, need to be left to the group discussion. > Of course, but if we don't have any ideas that make sense, then the work shouldn't be chartered. > > The second work item is about defining the mechanism by which > > information (which could at some point include policy) about the > > resolver is communicated to the host. For the per-domain use cases > > described in draft-pauly-dprive-adaptive-dns-privacy, that information > > mechanism helps identify the relevant domains; it also can include > > draft-ietf-dnsop-resolver-information, > > draft-reddy-dprive-dprive-privacy-policy. > > This seems to have a specific architecture in mind which is not > necessarily the right architecture. I.e., one could define > a system in which you learn about a resolver and then learn > about its properteis from it (as you suggest here) or one in > which you learn about a resolver *and* its properties and then > decide whether to use it. This latter design is more attractive > in a number of cases, so I don't think that we ought to predecide > it in the charter. > > Here too, draft-pauly and the other drafts seem designed for > totally different use cases and therefore should be seperate > work items. > > > I agree that these details shouldn=E2=80=99t be predecided in the charter= , and I > don=E2=80=99t think they are. The charter proposal doesn=E2=80=99t preclu= de the mechanisms > for resolver discovery and information being in the same document, or in > separate documents. > It's not an issue of documents, but of work items. The reason this is listed as separate from discovering the existence of > resolvers is to be clear that having a way to look up the properties of a > resolver is something that may be desirable even for cases in which clien= ts > already have some hardcoded list of resolvers they know about. For exampl= e, > if like Firefox, a browser knew about some public trusted resolvers, bein= g > able to query those resolvers about information such as keys for making > oblivious queries is something that ought to be done in a standard fashio= n. > > I definitely think that in many cases, the existence and applicability of > a resolver should be done in the same step, but the details should be > worked out by the group, not dictated by a charter. > My point is that your charter strongly pushes this particular detail in one direction. > > > The third bullet seems like it is edging pretty close to the > > > zone of controversy: > > > > > > - develop an informational document that describes how client > > > applications and systems can manage selection of DNS resolvers > > > in various network environments and use cases. > > > > Can you clarify what controversy you see arising from this work item? > > The intent here is to describe recommendations for how to work with > > scenarios like VPNs, captive networks, locally-hosted network content, > > etc, in a world where DoH is used both to local and public/remote > > resolvers. > > Well, here too, we have a lack of clarity in the text, so I > don't know what's buried in your "etc.". One case > I am concerned about is one in which the network wishes > to communicate that it wants you to use a specific resolver > but the client decides to ignore that. This is clearly > contested ground. > > > Got it. Yes, I imagine that if a group tried to give recommendations > around whether or not clients can ignore network policy, it would be > difficult to quickly come to an agreement. However, I don=E2=80=99t think= that (a) > a charter should make it out of scope to touch on that topic if the group > decided that it actually could do useful work there, > I strongly disagree here. The charter should, in fact, rule out the most controversial topics precisely because even having the group try to decide whether it could do useful work on them is itself going to be distracting. or that (b) a charter should preclude the group from working on the > recommendations and descriptions for cases that are not as contentious th= at > still need explanation, such as how to deal correctly with captive > networks, VPNs, and private networks. > Well, I'm not sure there is a "correct" answer for any of these. Also, what's a "private network"? If you mean "enterprise network", then this is in fact a very contentious case. > > > > I supposed if this was just a laundry list of every idea anyone > > > had ever thought of, that might be OK, but in my experience > > > documents like this (1) do some selection of the mechanisms > > > and (2) want to list the pluses and minuses of each mechanism > > > and both of these seem like a recipe for the kind of argument > > > that this group has been having for some time. I would propose > > > striking this work item entirely. > > > > This is not at all intended to be a laundry list of multiple > > approaches to the same use cases, with plusses and minuses. The key > > point in the item is enumerating the *network environments and use > > cases* (like captive networks, say) that should be considered by > > clients during implementation. > > Well, the text says "hoc client applications and systems can manage", > so it's clearly rather more than just enumeration. > > > Yes, indeed. My point here was that any document here wouldn=E2=80=99t be > enumerating *possible approaches*, as you suggested, but would be > enumerating the *network scenarios* clients need to handle. > > Clients managing selection of resolvers would, for example, include the > fact that a probe for a captive portal trigger page needs to use the > locally-provisioned DNS resolver, even if user-facing traffic is otherwis= e > bound to some other encrypted public resolver. > This is a perfect example of what I am concerned about, which is not just about listing the cases but proposing solutions. As it happens, I don't think there's much controversy about this particular one (and i agree that the solution you propose is likely correct), but there may well be about others. And some of the other environments are much less obvious. -Ekr > > Thanks, > Tommy > > > -Ekr > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > > > --000000000000f32539059da489f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 2, 2020 at 12:04 PM Tommy= Pauly <tpauly@apple.com> wro= te:
Hi Ekr,

Thanks for the f= urther comments!

Responses inline, but as a general = comment, I think the proposed charter text is more open-ended than some of = the points you=E2=80=99re bringing up.
<= br>
Yes. I am arguing against that. A charter is a contract betwe= en the WG and the IESG and contracts need to be crisp. This is not.


It intentionall= y is not trying to prescribe the technical solutions or how those solutions= will be arranged, but rather the solution space that a working group can f= ocus on.

Yes, but I don&= #39;t agree that we should be working in some of the space this lays out.


To that end,= tweaking the wording to not imply solutions that are not meant to be impli= ed is definitely useful, but I=E2=80=99m not sure it would be good to defin= e too many protocol details in the charter text.=C2=A0

I'm not trying to define protocol details= .



> > On Feb 1, 2020, at 7:29 AM, Eric Re= scorla <ekr@rtfm..com<= /a>> wrote:
> >
> The first work item refers to discovery= of the existence and
> identities of resolvers, such as DoH URI temp= late, for both the cases
> you list as (1) and (2). The phrase for = =E2=80=9Cpublic Internet=E2=80=9D is intended
> to refer to resolvers= that are generally available regardless of your
> local network conn= ection (not cases in which your local network points
> to an address = that happens to be QuadX);

I don't understand what work you are = contemplating here: some sort of
public directory which lists QuadX and = similar resolvers and their
properties? Is there demand for such a thing= ? At least from the
perspective of Firefox, I don't see how this wou= ld be useful.
Even for clients which don't intend to operate some ki= nd of
TRR-style program, it seems clear that there are going to be
so= me malicious resolvers in this directory; how would you know
which ones = they were?

In any case, this seems like a completely different probl= em
from learning the resolver offerings/preferences for a given
local= network, so these should be separate work items, not
merged into one bu= llet.



Yes, this makes sense.




Of course, but if we don't have= any ideas that make sense, then the work shouldn't be chartered.
<= /div>

=C2=A0
> The second work item is about def= ining the mechanism by which
> information (which could at some point= include policy) about the
> resolver is communicated to the host. Fo= r the per-domain use cases
> described in draft-pauly-dprive-adaptive= -dns-privacy, that information
> mechanism helps identify the relevan= t domains; it also can include
> draft-ietf-dnsop-resolver-informatio= n,
> draft-reddy-dprive-dprive-privacy-policy.

This seems to h= ave a specific architecture in mind which is not
necessarily the right a= rchitecture. I.e., one could define
a system in which you learn about a = resolver and then learn
about its properteis from it (as you suggest her= e) or one in
which you learn about a resolver *and* its properties and t= hen
decide whether to use it. This latter design is more attractive
i= n a number of cases, so I don't think that we ought to predecide
it = in the charter.

Here too, draft-pauly and the other drafts seem desi= gned for
totally different use cases and therefore should be seperatework items.

I agree that these = details shouldn=E2=80=99t be predecided in the charter, and I don=E2=80=99t= think they are. The charter proposal doesn=E2=80=99t preclude the mechanis= ms for resolver discovery and information being in the same document, or in= separate documents.



The reason this is listed as separate= from discovering the existence of resolvers is to be clear that having a w= ay to look up the properties of a resolver is something that may be desirab= le even for cases in which clients already have some hardcoded list of reso= lvers they know about. For example, if like Firefox, a browser knew about s= ome public trusted resolvers, being able to query those resolvers about inf= ormation such as keys for making oblivious queries is something that ought = to be done in a standard fashion.

I definitely think that in many cases, the e= xistence and applicability of a resolver should be done in the same step, b= ut the details should be worked out by the group, not dictated by a charter= .

My point is that your c= harter strongly pushes this particular detail in one direction.
<= br>

<= div style=3D"overflow-wrap: break-word;">

> > The third bullet seems like it is edg= ing pretty close to the
> > zone of controversy:
> >
&= gt; > =C2=A0 =C2=A0- develop an informational document that describes ho= w client
> > =C2=A0 =C2=A0applications and systems can manage sele= ction of DNS resolvers
> > =C2=A0 =C2=A0in various network environ= ments and use cases.
>
> Can you clarify what controversy you = see arising from this work item?
> The intent here is to describe rec= ommendations for how to work with
> scenarios like VPNs, captive netw= orks, locally-hosted network content,
> etc, in a world where DoH is = used both to local and public/remote
> resolvers.

Well, here t= oo, we have a lack of clarity in the text, so I
don't know what'= s buried in your "etc.". One case
I am concerned about is one = in which the network wishes
to communicate that it wants you to use a sp= ecific resolver
but the client decides to ignore that. This is clearlycontested ground.

Got it.= Yes, I imagine that if a group tried to give recommendations around whethe= r or not clients can ignore network policy, it would be difficult to quickl= y come to an agreement. However, I don=E2=80=99t think that (a) a charter s= hould make it out of scope to touch on that topic if the group decided that= it actually could do useful work there,

I strongly disagree here. The charter should, in fact= , rule out the most controversial topics precisely because even having the = group try to decide whether it could do useful work on them=C2=A0 is itself= going to be distracting.

or that (b) a charter should preclude the group from working on the rec= ommendations and descriptions for cases that are not as contentious that st= ill need explanation, such as how to deal correctly with captive networks, = VPNs, and private networks.

Well, I'm not sure there is a "correct" answer for a= ny of these. Also, what's a "private network"? If you mean &q= uot;enterprise network", then this is in fact a very contentious case.=

> > I supposed if this was just a laundry list of every= idea anyone
> > had ever thought of, that might be OK, but in my = experience
> > documents like this (1) do some selection of the me= chanisms
> > and (2) want to list the pluses and minuses of each m= echanism
> > and both of these seem like a recipe for the kind of = argument
> > that this group has been having for some time. I woul= d propose
> > striking this work item entirely.
>
> T= his is not at all intended to be a laundry list of multiple
> approac= hes to the same use cases, with plusses and minuses. The key
> point = in the item is enumerating the *network environments and use
> cases*= (like captive networks, say) that should be considered by
> clients = during implementation.

Well, the text says "hoc client applicat= ions and systems can manage",
so it's clearly rather more than = just enumeration.

Yes, inde= ed. My point here was that any document here wouldn=E2=80=99t be enumeratin= g *possible approaches*, as you suggested, but would be enumerating the *ne= twork scenarios* clients need to handle.

Clients managing selection= of resolvers would, for example, include the fact that a probe for a capti= ve portal trigger page needs to use the locally-provisioned DNS resolver, e= ven if user-facing traffic is otherwise bound to some other encrypted publi= c resolver.

This is= a perfect example of what I am concerned about, which is not just about li= sting the cases but proposing solutions. As it happens, I don't think t= here's much controversy about this particular one (and i agree that the= solution you propose is likely correct), but there may well be about other= s. And some of the other environments are much less obvious.
=
-Ekr

=C2=A0
--000000000000f32539059da489f1-- From nobody Sun Feb 2 21:18:40 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D957A1208C6; Sun, 2 Feb 2020 21:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz20VL8fZO0g; Sun, 2 Feb 2020 21:18:34 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA34120013; Sun, 2 Feb 2020 21:18:33 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 0135GrG4028530; Sun, 2 Feb 2020 21:18:31 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=FSqS+tmDleZ+yj7hLa9ZTbiPVaFdVrqWDCTw1bzTr0w=; b=kpnye2ruBO1ONZy9nvQoqu5Afqj+NfEHjVmSWlAB71Ch8KIa07wOhqWJ4n6FAUvFLzA4 9yv5Qp1fS3u7+YcgyJJgfaZj7k27YVq46Kzg2evN6QD4rR7PMlPRwT5hEwkkwCJde5uI G5ZjVt2yp6dCGkABh4Pfieq6Gg2oLokgrytGHMzohO+TdNAtwwW45oXXmwDBhWza3TKc Y38hYKa8ENEhoweEM54xDhOqp+dCmETo4Mno25QUwbxADp2LibLaq5Ewg82KQNmlYlDZ h1oqXu73w50rg+peUyQ4La4tx/CwEF9vHBf8duQRY1tWJkikfe8SEzgEaVKlRSysyMGj Yg== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2xw6vx042t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 02 Feb 2020 21:18:31 -0800 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q5400O9B1EVQD20@rn-mailsvcp-mta-lapp03.rno.apple.com>; Sun, 02 Feb 2020 21:18:31 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q5400H001DB1Q00@nwk-mmpp-sz11.apple.com>; Sun, 02 Feb 2020 21:18:31 -0800 (PST) X-Va-A: X-Va-T-CD: 6ca8ca8f63305df212074b411a74f5fb X-Va-E-CD: 8334c067597dbe6d319d09970b67c10c X-Va-R-CD: 1f698b5a705368b11f6c36875f76d28b X-Va-CD: 0 X-Va-ID: e87e6a9b-3ca4-4129-b043-d9783e12ce69 X-V-A: X-V-T-CD: 6ca8ca8f63305df212074b411a74f5fb X-V-E-CD: 8334c067597dbe6d319d09970b67c10c X-V-R-CD: 1f698b5a705368b11f6c36875f76d28b X-V-CD: 0 X-V-ID: 50e0b3b6-eb43-4cff-971a-257336c97d1e X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-02_09:,, signatures=0 Received: from [17.234.32.41] (unknown [17.234.32.41]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q5400HTK1EUTN60@nwk-mmpp-sz11.apple.com>; Sun, 02 Feb 2020 21:18:30 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_58C54E30-B8EA-4707-B7D7-CF8C3688B63B" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Sun, 02 Feb 2020 21:18:30 -0800 In-reply-to: Cc: Barry Leiba , ADD Mailing list , IESG To: Eric Rescorla References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> <25D6C7B0-216E-46B3-A32F-B76988DB1A09@apple.com> <4DB16752-C63B-4348-83AB-ED95FDB07B9E@apple.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-02_09:, , signatures=0 Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 05:18:36 -0000 --Apple-Mail=_58C54E30-B8EA-4707-B7D7-CF8C3688B63B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 2, 2020, at 8:41 PM, Eric Rescorla wrote: >=20 >=20 >=20 > and if the client device is pointed (say, by user selection) to a = public resolver like a QuadX, that it could learn what the DoH URI = Template for that is as well. >=20 > Why would you want this and why would you trust the network for that = information? Just to clarify, I didn=E2=80=99t mean that information about public = resolvers would come from the local network. The information should = certainly be trusted, and not just second-hand. Proposals that can be = more trusted are learning it from other HTTPS connections, or having = DNSSEC signed records. Other good options probably exist too. =20 >=20 >=20 > Got it. Yes, I imagine that if a group tried to give recommendations = around whether or not clients can ignore network policy, it would be = difficult to quickly come to an agreement. However, I don=E2=80=99t = think that (a) a charter should make it out of scope to touch on that = topic if the group decided that it actually could do useful work there, >=20 > I strongly disagree here. The charter should, in fact, rule out the = most controversial topics precisely because even having the group try to = decide whether it could do useful work on them is itself going to be = distracting. >=20 > or that (b) a charter should preclude the group from working on the = recommendations and descriptions for cases that are not as contentious = that still need explanation, such as how to deal correctly with captive = networks, VPNs, and private networks. >=20 > Well, I'm not sure there is a "correct" answer for any of these. Also, = what's a "private network"? If you mean "enterprise network", then this = is in fact a very contentious case. By =E2=80=9Cprivate network=E2=80=9D, I did mean enterprise networks (or = any network that has names that resolve only on the network, and not = publicly). While there may be disagreement about some of the details = there, it is a very important topic to consider. There are ways to make = these deployments work well with clients that use DoH to public servers, = and it should be in scope for the group to address that solution space. >=20 > Yes, indeed. My point here was that any document here wouldn=E2=80=99t = be enumerating *possible approaches*, as you suggested, but would be = enumerating the *network scenarios* clients need to handle. >=20 > Clients managing selection of resolvers would, for example, include = the fact that a probe for a captive portal trigger page needs to use the = locally-provisioned DNS resolver, even if user-facing traffic is = otherwise bound to some other encrypted public resolver. >=20 > This is a perfect example of what I am concerned about, which is not = just about listing the cases but proposing solutions. As it happens, I = don't think there's much controversy about this particular one (and i = agree that the solution you propose is likely correct), but there may = well be about others. And some of the other environments are much less = obvious. Right, I chose an example that is pretty cut-and-dry. Of course, = discussion around other topics should be managed so as not to spiral, = but it=E2=80=99s not clear that the charter should prohibit any area of = discussion. I=E2=80=99ll let the IESG review chime in more on the scope they prefer = for the charter, at this point. Tommy >=20 > -Ekr >=20 > =20 >=20 > Thanks, > Tommy >=20 >>=20 >> -Ekr >> --=20 >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add = --Apple-Mail=_58C54E30-B8EA-4707-B7D7-CF8C3688B63B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 2, 2020, at 8:41 PM, Eric Rescorla <ekr@rtfm.com> = wrote:



and if the client device is pointed (say, by user selection) = to a public resolver like a QuadX, that it could learn what the DoH URI = Template for that is as well.

Why would you want this = and why would you trust the network for that information?

Just = to clarify, I didn=E2=80=99t mean that information about public = resolvers would come from the local network. The information should = certainly be trusted, and not just second-hand. Proposals that can be = more trusted are learning it from other HTTPS connections, or having = DNSSEC signed records. Other good options probably exist = too.
 


Got it. Yes, I imagine that if a group tried to give = recommendations around whether or not clients can ignore network policy, = it would be difficult to quickly come to an agreement. However, I = don=E2=80=99t think that (a) a charter should make it out of scope to = touch on that topic if the group decided that it actually could do = useful work there,
I strongly disagree here. The charter = should, in fact, rule out the most controversial topics precisely = because even having the group try to decide whether it could do useful = work on them  is itself going to be distracting.

or that (b) a = charter should preclude the group from working on the recommendations = and descriptions for cases that are not as contentious that still need = explanation, such as how to deal correctly with captive networks, VPNs, = and private networks.

Well, I'm not sure there = is a "correct" answer for any of these. Also, what's a "private = network"? If you mean "enterprise network", then this is in fact a very = contentious case.

By =E2=80=9Cprivate network=E2=80=9D, I did mean = enterprise networks (or any network that has names that resolve only on = the network, and not publicly). While there may be disagreement about = some of the details there, it is a very important topic to consider. = There are ways to make these deployments work well with clients that use = DoH to public servers, and it should be in scope for the group to = address that solution space.


Yes, indeed. My point here was that any = document here wouldn=E2=80=99t be enumerating *possible approaches*, as = you suggested, but would be enumerating the *network scenarios* clients = need to handle.

Clients managing = selection of resolvers would, for example, include the fact that a probe = for a captive portal trigger page needs to use the locally-provisioned = DNS resolver, even if user-facing traffic is otherwise bound to some = other encrypted public = resolver.

This is a perfect example of what I am = concerned about, which is not just about listing the cases but proposing = solutions. As it happens, I don't think there's much controversy about = this particular one (and i agree that the solution you propose is likely = correct), but there may well be about others. And some of the other = environments are much less obvious.

Right,= I chose an example that is pretty cut-and-dry. Of course, discussion = around other topics should be managed so as not to spiral, but it=E2=80=99= s not clear that the charter should prohibit any area of = discussion.

I=E2=80=99ll let the = IESG review chime in more on the scope they prefer for the charter, at = this point.

Tommy

-Ekr

 

Thanks,
Tommy


-Ekr
-- 
Add mailing = list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

= --Apple-Mail=_58C54E30-B8EA-4707-B7D7-CF8C3688B63B-- From nobody Sun Feb 2 21:29:14 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8F71208DE for ; Sun, 2 Feb 2020 21:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxDZG3r-Cyes for ; Sun, 2 Feb 2020 21:29:10 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620DE1208D9 for ; Sun, 2 Feb 2020 21:29:10 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id 9so8731537lfq.10 for ; Sun, 02 Feb 2020 21:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ex3CeoO3ITkdh2KwC3BJ1xZ+jdheoDqwjxMtmCpK/Qc=; b=uXPizfu0E5Ojh3XtezFhdXoVDTuEimvAWG6BcTqA7jGs4kHlie90yEHWNGnC9SOGp7 4ZsxSVJJFhJtCLggQiJ3bYpStFdXjJ4hvN8SMy8pVJUksn8SlTsQDULHETlPvDwztzqw Dcm8c/adm2gQCd4F3Rqe4w9sxYXzziexzFjPlAHkDXhxqbe+XfpCDt2V+ldmcFif//X4 oAU7KTD7F0Egk4cvb6puTk3bfZx8mUhkdADj9pqPExBuiCY6oTRpgqeTbpHWPOiLRXLI 9LKORM7Sqdgg8WxLbEh7Rosxv2Q3BU2xuw7XdVzne8TgTtGD3mFFYyx7AsqO1hHnGxq2 lWxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ex3CeoO3ITkdh2KwC3BJ1xZ+jdheoDqwjxMtmCpK/Qc=; b=b1syOgRJFJnniWYCsfasmZDUTQ0SCmaZI6RCuf7stVP/A73ATAVYZmxsSy0XT6GEwl FrokwE3MzHutZEjaTHQoA0BoUYGkpWTorIBhHwSmmnR/9KvsXJ76ojg+/vd8jafoX+Ff TrMyvANmZo5z/yW5XctWA8HdbEx++v4F32Seisb/rgqGAXywvfjaGwZGfMjcO5t0Mr/P myFau8br6iVu//wvTGAqfHfL7fy5iRbbm4JSyLFIUyaTGXasPNMQ4NK5nD65NBFgbYv+ vzJWgaZKR71KvAUgKh6CkTUYvJTwbmWNIJSAm89+BrRvZajTvPNPUVQf/5YMy+M4GBDQ Mabg== X-Gm-Message-State: APjAAAW7RmFmPcZPR0ybiM7eh/Ly0QkZ1VUJSejU1HlETHZvDOFVjRfT gCiA9upTzRCjJy8C4DlTCt4qp8trUWOCBdomy0m00w== X-Google-Smtp-Source: APXvYqyyof1naKiOYXlh0snUdo/wziNEg14dAiY6rjYEgl5nf9jWRsP6ZZHpXXdJJ7/l0+/5QcNCfwGh8pXaQX1njJY= X-Received: by 2002:a19:6b11:: with SMTP id d17mr10956415lfa.168.1580707747029; Sun, 02 Feb 2020 21:29:07 -0800 (PST) MIME-Version: 1.0 References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> <25D6C7B0-216E-46B3-A32F-B76988DB1A09@apple.com> <4DB16752-C63B-4348-83AB-ED95FDB07B9E@apple.com> In-Reply-To: From: Eric Rescorla Date: Sun, 2 Feb 2020 21:28:30 -0800 Message-ID: To: Tommy Pauly Cc: Barry Leiba , ADD Mailing list , IESG Content-Type: multipart/alternative; boundary="000000000000c17800059da53374" Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 05:29:13 -0000 --000000000000c17800059da53374 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Feb 2, 2020 at 9:18 PM Tommy Pauly wrote: > Right, I chose an example that is pretty cut-and-dry. Of course, > discussion around other topics should be managed so as not to spiral, but > it=E2=80=99s not clear that the charter should prohibit any area of discu= ssion. > Well, the entire point of *any* charter is to rule out specific areas of work. And in this case that's particularly important to avoid a replay of the past year. -Ekr --000000000000c17800059da53374 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 2, 2020 at 9:18 PM Tommy = Pauly <tpauly@apple.com> wrot= e:
Right, I chose an example that is pretty cut-a= nd-dry. Of course, discussion around other topics should be managed so as n= ot to spiral, but it=E2=80=99s not clear that the charter should prohibit a= ny area of discussion.

Well, the enti= re point of *any* charter is to rule out specific areas of work. And in thi= s case that's particularly important to avoid a replay of the past year= .

-Ekr

--000000000000c17800059da53374-- From nobody Mon Feb 3 03:27:19 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F481200C5; Mon, 3 Feb 2020 03:27:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: add@ietf.org, add-chairs@ietf.org, add@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158072923548.28576.10022100427111787017.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2020 03:27:15 -0800 Archived-At: Subject: [Add] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_charter-ietf-add?= =?utf-8?q?-00-00?= X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 11:27:16 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-add-00-00: Yes 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/ There are no remarks associated with this position. From nobody Mon Feb 3 22:14:26 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DE1120024; Mon, 3 Feb 2020 22:14:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: add@ietf.org, add-chairs@ietf.org, add@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2020 22:14:20 -0800 Archived-At: Subject: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 06:14:21 -0000 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 nobody Tue Feb 4 00:26:32 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBE4120122; Tue, 4 Feb 2020 00:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAIPlA-w1UAx; Tue, 4 Feb 2020 00:26:26 -0800 (PST) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259C9120074; Tue, 4 Feb 2020 00:26:23 -0800 (PST) Received: by mail-io1-xd41.google.com with SMTP id t26so19920166ioi.13; Tue, 04 Feb 2020 00:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Z9UrT+TvMb5OSP+ygE0FMiw3XAUeuUYg4qYM8+2d58=; b=H9a9E66e1351OrnshP0BXcySlBFgH7ioU06Sv67C5A7Aq5hVhHXzWvA6GGgAlPJL89 Ebk1zQICTXE9o99+XT4ZXth5QieBaiwCJ/P11C+gd9qYRLBxk+11ZB27Shfz0AwsUeUr P61qmVqbbNdl/EN8hZCmJcPNkR1M8eNEd5eyLY11cw2hhp2w3FKFpvwf5apP0AztQRQB Yp/52WzwmcLINSj6G+zmU6ly6dMHGukV0be1jz8O+WPOvCHGkttbEzAPFZkP08XZc64l qdQ3U4D3M8oor1DER3jtk13jk85zfFmHWvATUt0aE1/obQayNh1yRGokI9dtgI/8bhai 8u2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Z9UrT+TvMb5OSP+ygE0FMiw3XAUeuUYg4qYM8+2d58=; b=hBaOM9UlG0RtAcbSQCLgL8mUCdME6HqWMH37UcYbethyJlriXe7rXwQznKETNNe8++ 9UsJhogn5aT2YywF82th+AA2RUbgTi4Lg1b6gR++xgalY4X3AvhaOdF5LufIIhA6MJTs 8ewPEKjADDBLj4NV8bEmeTdm5BCu4sbxVKVCZA+gtBPhr6xDCDBIjRBlt6NAzePBid7n iUXmoBxNtqsNF6gnLQbYvf3VvnuPyxHpnsM3/mNAfeuWEg/rSKdLTf+tFNsZhOL7TjDE zHT0zM8v9XXQTqJx00RLWYFFycqPMav3p4n8TjyMMR2cawchzJrDfvbkPh48SFsI4tUq hO4Q== X-Gm-Message-State: APjAAAV2pPVPzgWir7iczsn8A8NrxCYNEoN2YKGmrYkrMGNjkSWGXNOo GXoQERyaBuUVLkyqqocaSu/Obtz6i5Eh6OIeVJQT/lNfX+NUpA== X-Google-Smtp-Source: APXvYqxnRVwze9nMsu4++NXNVRAW64HkE8A9BDDHBfofZqxcfM1ldPhSpl9WHrcWyhSXULGXr8fWMmb0JC3iqyF6wAU= X-Received: by 2002:a02:cd82:: with SMTP id l2mr22567286jap.103.1580804782416; Tue, 04 Feb 2020 00:26:22 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> In-Reply-To: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> From: Rob Sayre Date: Tue, 4 Feb 2020 00:26:11 -0800 Message-ID: To: Adam Roach Cc: The IESG , ADD Mailing list , add-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000083ead3059dbbcb18" Archived-At: Subject: Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 08:26:28 -0000 --00000000000083ead3059dbbcb18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2020 at 10:14 PM Adam Roach via Datatracker wrote: > > > - 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 =C3=89ric that the described work is open-= ended > 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#sect= ion-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 --00000000000083ead3059dbbcb18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --00000000000083ead3059dbbcb18-- From nobody Tue Feb 4 00:42:16 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48750120123; Tue, 4 Feb 2020 00:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEfafetZH1bu; Tue, 4 Feb 2020 00:42:12 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29597120122; Tue, 4 Feb 2020 00:42:12 -0800 (PST) Received: from [46.140.192.12] (helo=[172.29.63.181]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iytmb-0002bh-DS; Tue, 04 Feb 2020 09:42:09 +0100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: =?utf-8?Q?"Mirja_K=C3=BChlewind_=28IETF=29"?= Mime-Version: 1.0 (1.0) Date: Tue, 4 Feb 2020 09:42:08 +0100 Message-Id: <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> Cc: The IESG , add@ietf.org, add-chairs@ietf.org In-Reply-To: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: iPhone Mail (17C54) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1580805732;25aa0c30; X-HE-SMSGID: 1iytmb-0002bh-DS Archived-At: Subject: Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 08:42:16 -0000 Hi Adam, Please see a few comments online. > Am 04.02.2020 um 07:14 schrieb Adam Roach via Datatracker : >=20 > =EF=BB=BFAdam Roach has entered the following ballot position for > charter-ietf-add-00-00: No Objection >=20 > 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.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-add/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 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. >=20 > 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. >=20 > I can appreciate that the charter has undergone many iterations to arrive a= t > its current form, but still think that the working group would be well ser= ved > by some additional tightening up of the description of the deliverables. >=20 > 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. >=20 >> - 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; >=20 > 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. >=20 > Yes, I know that's not the intention, but it's what the words literally sa= y. > We should make them say what they mean. >=20 > 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. No, this is not necessary the case. The problem is that your usually preferr= ed DNS server might not offer encryption (yet) and therefore you may actuall= y want to discover other servers that provide encryption. > I *think* we can capture this > with something more along the lines of: >=20 > - 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. >=20 > 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 n= ot > be the same as the mechanism mentioned above, ..." As Tommy explained, retrieving additional information about an already known= server can be useful as well. Therefore these are to different items, one f= ocusing on discovery only and one on retrieving information. Not sure what e= xactly you mean with =E2=80=9Cdeliverables=E2=80=9C but I think the charter l= eaves it correctly open if these are different mechanisms or somehow combine= d in one protocol or one step as well as leaving it open in how many documen= ts this will get finally published. We need to have some more discussion in t= he group about the details of these mechanisms, therefore precluding an outc= ome in the charter more than it is described now doesn=E2=80=99t make sense t= o me. >=20 >> - develop an informational document that describes how client >> applications and systems can manage selection of DNS resolvers >> in various network environments and use cases. >=20 > Here I agree with both EKR and =C3=89ric that the described work is open-e= nded > 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. There has been quite a lot discussion about this point on the list and this i= s were agreement was reached. Now having the IESG forcing tge community to s= trike that part really seems like overrunning community agreement and would p= robably cause equally much discussion or even more. The agreement was to hav= e 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 dev= eloping technical mechanisms. Let=E2=80=99s not repeat the same mistake that= happened with DoH. Mirja >=20 >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Tue Feb 4 00:56:34 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8723120122; Tue, 4 Feb 2020 00:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmnr8Ljj4Sc3; Tue, 4 Feb 2020 00:56:27 -0800 (PST) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C9C120074; Tue, 4 Feb 2020 00:56:27 -0800 (PST) Received: by mail-io1-xd42.google.com with SMTP id c16so20036884ioh.6; Tue, 04 Feb 2020 00:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o+UdVobWS6ddi54T1sNiB8oL+cZw8/TPuEOTBbEtS6c=; b=ZO11w5SNYgOKnHcdcT93lPk2Nke7oMFUmZNFC4BEwhgNs1+AmfpAxja8zpU+ygCCkz NDFX+DQvcB62xttuiUwx9FwcfehUy90OeJ3tmVbMWPOH9NPCwiMmzpwnkKEHRyjZhund EtLYkVN0rcQHOl+9l0i9Pmu63DIn5/mh1dS9aeqAJfMgwTXymeZ4pEx/sTPF8No6AFc1 PhYOjLOESordEr+GlyAxluizoc3FMO6CSbN9jdLNiegN6Gip+9Lzvs7TI6++1SL8wDui cb/t8hNn3nPyAnofLUS/gqMfXpeIHVkLlW0NYk/0KDCIlqWtgIo2L1zh52AsUe5icK5d J7Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o+UdVobWS6ddi54T1sNiB8oL+cZw8/TPuEOTBbEtS6c=; b=kLuCLC1MRanWzt5IAsjgOAkdK5G/gG6hanjB1a7lvlm8liv7HXbyrxaReRtFmlTmJu 8RlwRdJuZitzLLmm6x4Py7vEf1voz9hYw22bfXFLq8kNwbSMXQP8Wc3NDXz1BgUzIzMH GkKUt95h9+yHze5IR/ZBJ2AFhSTfowJsIFXwyMa+mkCxzruAUyH64OJMPaNBuvaqLHKq L8gsVoi37m+PN/2K1zJ5kkXf9uB7agNmFnDwta7VxonRf1H+G5e5fED5TpBVVqKeZa0i 196xPpDpeW5m+o2h2KH2plPeJe1uby6EWRH+cSkbHLnDCRRt7Sj33xVapzRZh/zIe/0S TxMQ== X-Gm-Message-State: APjAAAVq5pmm05KRmYU8D/nVpkaxiBSm4k6SfOV38IUnm/FgxPQNzcOn QIpD0aLlRA9XBxx5DmLuweZRCeOYR4tvFEGTNoqcBEn3BVk= X-Google-Smtp-Source: APXvYqxJlbuSuwqGflzzXdnbhY8d9ksX7vmajMPV+tmHKan8r9V/xjSjZ5q8fp/dRF3wej8d3SG3+1/XXlyNiDT4HDw= X-Received: by 2002:a6b:6103:: with SMTP id v3mr23294441iob.49.1580806586350; Tue, 04 Feb 2020 00:56:26 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> In-Reply-To: <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> From: Rob Sayre Date: Tue, 4 Feb 2020 00:56:15 -0800 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind_=28IETF=29?= Cc: Adam Roach , ADD Mailing list , The IESG , add-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000009c46d059dbc37ee" Archived-At: Subject: Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 08:56:29 -0000 --00000000000009c46d059dbc37ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020 at 12:42 AM "Mirja K=C3=BChlewind (IETF)" < ietf@kuehlewind.net> wrote: > ... > Let=E2=80=99s not repeat the same mistake that happened with DoH. > What mistake would that be? Encryption standards always have opponents. thanks, Rob --00000000000009c46d059dbc37ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2020 at 12:42 AM "Mir= ja K=C3=BChlewind (IETF)" <i= etf@kuehlewind.net> wrote:
...
=C2=A0Let=E2=80=99s not= repeat the same mistake that happened with DoH.

<= /div>
What mistake would that be? Encryption standards always have oppo= nents.

thanks,
Rob

<= /div>
--00000000000009c46d059dbc37ee-- From nobody Tue Feb 4 01:12:11 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169C8120074; Tue, 4 Feb 2020 01:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9eYeBJ7Kign; Tue, 4 Feb 2020 01:12:07 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7096E120019; Tue, 4 Feb 2020 01:12:07 -0800 (PST) Received: from [2a00:79e1:abc:301:d16b:5d30:4fe:62da]; authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iyuFX-0007OH-FV; Tue, 04 Feb 2020 10:12:03 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 4 Feb 2020 10:12:02 +0100 Cc: ADD Mailing list , Adam Roach , The IESG , add-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <48EF7410-16B7-4B08-A9E2-5605D4714E1E@kuehlewind.net> References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> To: Rob Sayre X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1580807527;8b6e37ed; X-HE-SMSGID: 1iyuFX-0007OH-FV Archived-At: Subject: Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 09:12:10 -0000 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=E2=80=A6 let=E2=80=99s= concentrate on the new work in add now! > On 4. Feb 2020, at 09:56, Rob Sayre wrote: >=20 > On Tue, Feb 4, 2020 at 12:42 AM "Mirja K=C3=BChlewind (IETF)" = wrote: > ... > Let=E2=80=99s not repeat the same mistake that happened with DoH. >=20 > What mistake would that be? Encryption standards always have = opponents. >=20 > thanks, > Rob >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Tue Feb 4 01:15:01 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C13120130 for ; Tue, 4 Feb 2020 01:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9l3KQeA7zLJ for ; Tue, 4 Feb 2020 01:14:57 -0800 (PST) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFC5120074 for ; Tue, 4 Feb 2020 01:14:57 -0800 (PST) Received: by mail-lj1-x242.google.com with SMTP id q8so17759150ljb.2 for ; Tue, 04 Feb 2020 01:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fMLAWwoMj6hR6jNF7H6xjiFrlPt0ZCCg9glkPLvhzps=; b=PQEihidnJFxbeTsHMuqsdl6IFFuMW0lbhQOMP4cWxwh9AuoZi7lDcXtFsYmJfGbY2I LT7vY6jaCCUYvi1YhsmgE9X7NcjO+WPi2KjflnbSDMSD7/KePLysURXByJHmwkxOq2oz gURZMhgPeXYpF9Ez8mOqJlJIlf7N6JxNWoEl6UteeKEZBNPT+r7RaPzEJ3bVJbg2fSa7 PVwwobXMOJyXnB9hpWe5tV1/JpThpxrSPYjOhyu+Oo00tfmOvod3Hu0fE7UIl9Hn6cUo vgGJ5zaER6393KSfWku47JGTq+v23OdRB3XDgewOwrGj5nTRiQTlm1Haw+u/J3D63wgH cBCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fMLAWwoMj6hR6jNF7H6xjiFrlPt0ZCCg9glkPLvhzps=; b=kkAlDspCS8190f7VZf42eKBOgrT/lgSwFE5rzp6w7fyPA/xRZNmi5Pm0mK/PSWt9Bu RLnsYJFPqSIZFm+qq2u9fwZduPqz63b6deIBxr2/6ohpvURglrRaEukZORzG3PgABAxk 9HIws/w2RLDJ8tvl0DQtmKP51OVDqEfywO2WIZkLRbJ8Z1GsKrLkHKOnuBYJ7vEvg3QJ zRYIJw4vnpK3/yQTF8k0CrMX1Hz6Lri+zlGE/LHQq6rpzO1ueL1l6vAYmhTFNGQtkqRH CbjwFJSA/SlSMDLAr2e+QUO8o7VKqJps6Ou64B+vXJgKn6YaR6AFAF0PkiRMKDEiCZoz y1bw== X-Gm-Message-State: APjAAAXzVhARViGuX7aGGbngexTfQuLuhR1A5u8HoGHz+twLerK0XK0Q vpJAC/KF9SGs6vIK+3VCuajiE37Uuvq53vDdwZmaXw== X-Google-Smtp-Source: APXvYqw4BFPo6Q9h7RGn2A/Gd4J/fxr8tOx/u9Oyv6NcEeBeDNJyyJgGe9sBhrYjy/BJuT+VddYijJQtGP1thVFnNU8= X-Received: by 2002:a2e:b0c4:: with SMTP id g4mr16975612ljl.83.1580807695302; Tue, 04 Feb 2020 01:14:55 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> <48EF7410-16B7-4B08-A9E2-5605D4714E1E@kuehlewind.net> In-Reply-To: <48EF7410-16B7-4B08-A9E2-5605D4714E1E@kuehlewind.net> From: Eric Rescorla Date: Tue, 4 Feb 2020 01:14:19 -0800 Message-ID: To: Mirja Kuehlewind Cc: Rob Sayre , ADD Mailing list , Adam Roach , The IESG , add-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000231775059dbc79a4" Archived-At: Subject: Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 09:14:59 -0000 --000000000000231775059dbc79a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020 at 1:12 AM Mirja Kuehlewind wrote= : > This is really not about opposing encryption but I think that DoH was ver= y > 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=E2=80=A6 let=E2=80=99= s concentrate on > the new work in add now! > > > > On 4. Feb 2020, at 09:56, Rob Sayre wrote: > > > > On Tue, Feb 4, 2020 at 12:42 AM "Mirja K=C3=BChlewind (IETF)" < > ietf@kuehlewind.net> wrote: > > ... > > Let=E2=80=99s not repeat the same mistake that happened with DoH. > > > > What mistake would that be? Encryption standards always have opponents. > > > > thanks, > > Rob > > > > -- > > Add mailing list > > Add@ietf.org > > https://www.ietf.org/mailman/listinfo/add > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000231775059dbc79a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Feb 4, 2020 at 1:12 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
This is really not about oppo= sing encryption but I think that DoH was very narrowly only concentrating o= n the technical aspects

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

-Ekr
<= br>
while I believe = some of the discussion we have right now would probably have been more prod= uctive if that would have happen in parallel to the technical work instead = of afterwards. But who knows=E2=80=A6 let=E2=80=99s concentrate on the new = work in add now!




> On 4. Feb 2020, at 09:56, Rob Sayre <sayrer@gmail.com> wrote:
>
> On Tue, Feb 4, 2020 at 12:42 AM "Mirja K=C3=BChlewind (IETF)"= ; <ietf@kuehlew= ind.net> wrote:
> ...
>=C2=A0 Let=E2=80=99s not repeat the same mistake that happened with DoH= .
>
> What mistake would that be? Encryption standards always have opponents= .
>
> thanks,
> Rob
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000231775059dbc79a4-- From nobody Tue Feb 4 01:27:02 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72001120122 for ; Tue, 4 Feb 2020 01:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3655066-goaR for ; Tue, 4 Feb 2020 01:26:59 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4E9120103 for ; Tue, 4 Feb 2020 01:26:55 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id q8so17764429ljj.11 for ; Tue, 04 Feb 2020 01:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/8mlEP6GYa4oGLXtdKqVjeGYSleCJOzdRAblhCBWh6g=; b=yYA05SBP6ORDGTViTDFU3Pkd6aUaEG1xHCaRjtXFLR47U54yjrrznzuTY4lhgYFJga /XyJxDLmrc538pA4+G9zJ3F+Y1X8wFbaol1IQ4OtlwxETKplftai8JfBNgJM6IwHI+2U 6+EkkAVknMV2rSDV6/+fAy2RqPQxkt4k9XATNq4XfXsR85HaJZz5ZKO3nvflyCwNREJ9 ZZrE6OtqQ9nNbJpzhiGIbpAvEVP+V7VwGIl1xI4SsxLLB09rYmOh3zyqhQouyshdxrCe Fh0fIhksSCSb+oFsyVXIOc770JkP9QvPOnzweC1Ujh6EYKlKe+atnAEn1iUGwDOU4yYk hXnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/8mlEP6GYa4oGLXtdKqVjeGYSleCJOzdRAblhCBWh6g=; b=FLmrNo8W7rpfAaU0a5R2V6lxS01Myy2D4WNgqCUKufqIWyNvVIez3/pAaJXluRMOYC GtdsMfb5kGUTiHf4f8bqRvWbGOnDsESXfdlKcR0UubIxDnGzZFz9ysdIa2hncfuJabrJ camuevha9L6BXSHxILcrnNslFzXKT6zerMcGuQcZR9kJSqprbtoBfQH1hEjGDoBYO49u qUuX4pQa7rlw+HhBQd+pOLUl4pAokAK7QtUqrsPjNfDVwyCpTyZbCXpIG7m/TpZQGsSe eDyup8MYhLvJrJh/jlgbw1/ZQDDWhQ1BlfJcbqjWHMJiEWZf2TfD1w1Qv3wJ0S+oG+fq 9nGw== X-Gm-Message-State: APjAAAU94kOP0giDKxhsRvx6kBErL4kbIJMcKJ5qPJlvPb/7NJ+/0PXp N21fKoQ8fkBbl/YKFZ8saZeoEQ2qsp6zM/n3ChtdCA== X-Google-Smtp-Source: APXvYqyp36QMLWl5S0khPPMnFZe170pBbG2mhweSjL3mJhRDLoq/NgYzCnL0XTlycYIf91hu7zdfV3H2mxqxvmAWE3o= X-Received: by 2002:a2e:3e10:: with SMTP id l16mr16397253lja.286.1580808413872; Tue, 04 Feb 2020 01:26:53 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> In-Reply-To: <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> From: Eric Rescorla Date: Tue, 4 Feb 2020 01:26:17 -0800 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind_=28IETF=29?= Cc: Adam Roach , ADD Mailing list , The IESG , add-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000f79495059dbca3f2" Archived-At: Subject: Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 09:27:00 -0000 --000000000000f79495059dbca3f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020 at 12:42 AM "Mirja K=C3=BChlewind (IETF)" < ietf@kuehlewind.net> wrote: > Hi Adam, > > Please see a few comments online. > > > Am 04.02.2020 um 07:14 schrieb Adam Roach via Datatracker < > noreply@ietf.org>: > > > Here I agree with both EKR and =C3=89ric that the described work is ope= n-ended > > enough to result in unproductive and likely toxic interactions. It woul= d > > 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 conversation= s > > 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. > > 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 --000000000000f79495059dbca3f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 12:42 AM "= ;Mirja K=C3=BChlewind (IETF)" <ietf@kuehlewind.net> wrote:
Hi Adam,

Please see a few comments online.

> Am 04.02.2020 um 07:14 schrieb Adam Roach via Datatracker <noreply@ietf.org>:
> Here I agree with both EKR and =C3=89ric that the described work is op= en-ended
> enough to result in unproductive and likely toxic interactions. It wou= ld
> 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 conversatio= ns
> have so far been fruitless. But I fear that putting this on the plate<= br> > as part of the first tranche of work is likely to lead to the same
> 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 t= o strike that part really seems like overrunning community agreement and wo= uld 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 eithe= r 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

--000000000000f79495059dbca3f2-- From nobody Tue Feb 4 01:50:51 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B2C120074; Tue, 4 Feb 2020 01:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asj05kkwxz_p; Tue, 4 Feb 2020 01:50:49 -0800 (PST) Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F68120073; Tue, 4 Feb 2020 01:50:48 -0800 (PST) Received: by mail-il1-x144.google.com with SMTP id f70so15314415ill.6; Tue, 04 Feb 2020 01:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tePglkNzpfNK1MUNXBLjvqgY2vrCMx48xyMdJolCWDg=; b=e0Kg1n/Mq5K0XRZE+bRDkanh1rZH6GYa/s/b8qwAddZnM22JWcCtjWPp9NWQ55+6CJ uRCnsR9xaTCKNKNn2K5CYGAv0U7APWAiynQfzWNXaWi5bR3ptpgbSaUUvBy5WG8pxUPU kJKJNJWmye0QoD9t7HRj4dKRIfRRSq6zIAuU1SrYEwCO97p+CQigrqjVCkeJNfHt6npw CeQoZP76X4wGN6JMLt1qEYuszb70MHaaq4adaanYkd3OrRnvlC0QZ7s53wgXuOxUXGZV RiG0v6HFZBcKfOLyKvkZQaoE1dL61RTas5PqMUJ+M5Dp3NxLHUOab8ZwZgQMaZKEquv+ w59g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tePglkNzpfNK1MUNXBLjvqgY2vrCMx48xyMdJolCWDg=; b=NtpSv74f4f13rzDV6CcjxAHZi8AJ+67NMnC7w8/PWHVZ3rE+e8WzzI/SRHJB9869oE zZzvwMK0xgKy2KKHF14QfJySJSnLSmU/XjouH5gcmp2tLMXDfEoR1qEWip145vHo7qd1 VsLC052C2WLKDAOp/q3LWoyDBlhS7yxoEN9tl/DtP6ETnoj43Ry4CUstY+3MrR2cO/PC Zg6O6VHSWzuebciDzGmJClppd54ImgVJb/5d4ctQjSOpJrf5mec7tQHwpy/GaCwI5XMy lTHRjQeSDKKBaaZ0YSdbEX1qvZfmXyJYyQXUqnhczpdtVZV/GO1UWC4z2F4W76Xk38GM 38yQ== X-Gm-Message-State: APjAAAV88EnS4tjA3N6sgJFFLe3KzubWSTxDxxAbUzg4BqDY+pX/s845 kR180S4vB+ko2xGy4OA9Gcmer5kN0ZQ1P9Ir6dU= X-Google-Smtp-Source: APXvYqwp3iO/OoXNoiks5A3w+V5IOefNNTYxLfEa6t9d7s+d+VsacU8RCauID4s9m+lRpsbMgrRxX4mg6CU3C07W0oI= X-Received: by 2002:a92:990b:: with SMTP id p11mr5784758ili.254.1580809847580; Tue, 04 Feb 2020 01:50:47 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> <48EF7410-16B7-4B08-A9E2-5605D4714E1E@kuehlewind.net> In-Reply-To: <48EF7410-16B7-4B08-A9E2-5605D4714E1E@kuehlewind.net> From: Rob Sayre Date: Tue, 4 Feb 2020 01:50:36 -0800 Message-ID: To: Mirja Kuehlewind Cc: ADD Mailing list , Adam Roach , The IESG , add-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000006c2d79059dbcf984" Archived-At: Subject: Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 09:50:50 -0000 --0000000000006c2d79059dbcf984 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020 at 1:12 AM Mirja Kuehlewind wrote= : > This is really not about opposing encryption but I think that DoH was ver= y > 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=E2=80=A6 let=E2=80=99s concentrate o= n 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 --0000000000006c2d79059dbcf984 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2020 at 1:12 AM Mirja Kueh= lewind <ietf@kuehlewind.net&g= t; wrote:
This is really not about opposing encryption but I thi= nk that DoH was very narrowly only concentrating on the technical aspects w= hile 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 technica= l work instead of afterwards. But who knows=E2=80=A6 let=E2=80=99s concentr= ate on the new work in add now!

I don&#= 39;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 unsuccessf= ul RFCs...

thanks,
Rob

--0000000000006c2d79059dbcf984-- From nobody Tue Feb 4 02:26:05 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8196C120817; Tue, 4 Feb 2020 02:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AD2uVvL-i-X; Tue, 4 Feb 2020 02:26:01 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D4A120018; Tue, 4 Feb 2020 02:26:01 -0800 (PST) Received: from [2a00:79e1:abc:301:d16b:5d30:4fe:62da]; authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iyvP4-0007Sz-VH; Tue, 04 Feb 2020 11:25:59 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 4 Feb 2020 11:25:57 +0100 Cc: ADD Mailing list , Adam Roach , The IESG , add-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> <48EF7410-16B7-4B08-A9E2-5605D4714E1E@kuehlewind.net> To: Rob Sayre X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1580811961;c336afe2; X-HE-SMSGID: 1iyvP4-0007Sz-VH Archived-At: Subject: Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 10:26:04 -0000 Just to clarify I didn=E2=80=99t 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.=20 > On 4. Feb 2020, at 10:50, Rob Sayre wrote: >=20 > On Tue, Feb 4, 2020 at 1:12 AM Mirja Kuehlewind = wrote: > 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=E2=80=A6 let=E2=80=99s= concentrate on the new work in add now! >=20 > 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. >=20 > Compare and contrast with the vast wasteland of unsuccessful RFCs... >=20 > thanks, > Rob >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Tue Feb 4 02:29:14 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F8712008F; Tue, 4 Feb 2020 02:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTmAFefmcgSO; Tue, 4 Feb 2020 02:29:11 -0800 (PST) Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0925F120088; Tue, 4 Feb 2020 02:29:11 -0800 (PST) Received: by mail-il1-x144.google.com with SMTP id g12so15437514ild.2; Tue, 04 Feb 2020 02:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G/Jh3PKXri4gIINlE+JE646vqX6mCbxFSoHDwwEsYcY=; b=rOIqfkqnw2UpE2lIk8+x8CV3c+I001OGxuZCZdZyFsfP96gt6AOWsbtdmGlIuqZWjo NfnYdJl4idPqfaqJJYTl+agXo0jYgDJBuRPyw9OFJMHi1LP2Nq34BJE16YUquJ6GC8b/ 9e0zhJKt8vQRfHWVQZPuuv/2Zm9bK5EaXps1X68WFH3CoYqQMxbpCkV7BFyouAFOos4M +245tJQLguly5RegXBZ0liTQJitmhG1RP78/IZchHRr1Jb6sYpCLICKIW8bwzUbA023p RLIiARIQgNyr2XKR8ynq1wC6zzd/ou8heMUywB22al2USKtozrsBoSRLJH7g3Y8I3Ah4 KmlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G/Jh3PKXri4gIINlE+JE646vqX6mCbxFSoHDwwEsYcY=; b=Fa7dzvqxRoEKA8mN0miKD85wJi0yKAxtmS/LlbNOt1NkcOWHlCkClFW/9SEQ0ua+K4 8Bm+okmzbafkBPcc9thfLjcI8D5eVv6eMJC/WKQNaRV8SoSoKsWc160NbjGwkczGIEk7 kydsnHrRpCJQ3pdReaoOXHqb5VYxoSs73VFVxI8RPkzETrN4OOYp/ETAPJQDZ8EwMlTE B65IXkf73YV6u8jE2dJvsFBuZrnfwxYZElTaFmibIzcwzsDi314UpvNbUJH4zNpPOKMz s3FCtwirCHqnIvZAkqgdXsbYedIXmZZSlYz9vL3Go0YAlvuNvvoRC8XpKIIrAAoBM0M1 eadw== X-Gm-Message-State: APjAAAVkWDvJukMiNPnOcaPbHbKgI4PaUAhQo6383LVIob5PoP1/5q/C jdXch4Jx/kmb2g+sSNw/96eErKqzG1xm/qWUTXA= X-Google-Smtp-Source: APXvYqxtNNj1Z72ezNwzli2y/auvqTMlktxk1uw1TvsK/ykwWldakLZ6+g64hJlau+dy2QKoqiMaJc4L7pb1c6qfOFQ= X-Received: by 2002:a92:990b:: with SMTP id p11mr5917667ili.254.1580812150099; Tue, 04 Feb 2020 02:29:10 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> <48EF7410-16B7-4B08-A9E2-5605D4714E1E@kuehlewind.net> In-Reply-To: From: Rob Sayre Date: Tue, 4 Feb 2020 02:28:59 -0800 Message-ID: To: Mirja Kuehlewind Cc: ADD Mailing list , Adam Roach , The IESG , add-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a9d5a2059dbd82c9" Archived-At: Subject: Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 10:29:12 -0000 --000000000000a9d5a2059dbd82c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020 at 2:26 AM Mirja Kuehlewind wrote= : > Just to clarify I didn=E2=80=99t say that DoH is not a good protocol or t= hat 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 --000000000000a9d5a2059dbd82c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2020 at 2:26 AM Mirja Kueh= lewind <ietf@kuehlewind.net&g= t; wrote:
Just to clarify I didn=E2=80=99t say that DoH is not a= good protocol or that is not successful; just saying discussions we have r= ight now might have been more productive when we would have had that discus= sion in parallel to the technical work.

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

thank= s,
Rob
=C2=A0
--000000000000a9d5a2059dbd82c9-- From nobody Tue Feb 4 02:50:58 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019A8120099; Tue, 4 Feb 2020 02:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYU0SKOhp09f; Tue, 4 Feb 2020 02:50:53 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F46D120074; Tue, 4 Feb 2020 02:50:53 -0800 (PST) Received: from tpw09926dag17h.domain1.systemhost.net (10.9.212.41) by RDW083A011ED67.bt.com (10.187.98.37) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 4 Feb 2020 11:00:00 +0000 Received: from tpw09926dag18g.domain1.systemhost.net (10.9.212.34) by tpw09926dag17h.domain1.systemhost.net (10.9.212.41) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 4 Feb 2020 10:50:49 +0000 Received: from bwp09926079.bt.com (10.36.82.110) by tpw09926dag18g.domain1.systemhost.net (10.9.212.34) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 4 Feb 2020 10:50:49 +0000 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.54) by smtpe1.intersmtp.com (10.36.82.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Tue, 4 Feb 2020 10:50:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dPMgh5iqungSxamj208wsUBxUwAMtZ7SQnuepMVq4r91CcQ8WPhocQPbpcWl19H+ADQanT2gBzNVS9X6LC9y8F0Jlf8PM5VaxJTOp7kbBCMm3lv4MyUiYs5rkb9EUHJ/z0i1S7d5vk0fU/j5sLhn72ROjvBFGW2v5nSSnAlzrUBlhrOM1leU4KH+sSqLusq43Kx3Dh7donSY6EA9SEMLqqWmQx9BSPkSE3zy5v318k/8Zd/iowsZB61rivo8Ypp39IDiN3KP6lDQSOS1Lpy0dV/REDEQqHTLuZ8LXjm5VG4fLW32YtGC4m9OLjBviMLViBAj5CH6rCbyN0fP2Z6FEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PtATjL6K51VfTkv97ezps9CNTquqj1brG1AGXx7ZG4U=; b=Ml4gLI+B35vvgqunktlXe6R8jlItMUS3FvRWzHcAIaTgWIU9wVorsHUW2n3NQSGaTP0Cmu4sh5TFSSgpGuVuDAnuEioZgTKH1bwBK5HiREFt//vw2PDhlWYt0sGnuDfreY5NbsFlSxwLGPbmBUnFPhoPkZzhJj+nLX2gFXXT9uZfPK4oXJEWnll74jFUA9smf7nr6q3AJRVrr+u5KuoWY0lSgEg0KPRN5bmOKT1lq8DdehaxXNkF/9JK32HpqXO2sZS7RnCwBU3/wBTVA30sxZrhxuV+4ftbcdzYYZ7+ZxrKlquvSMyJn1TBgKnbdIUM/Kya37EkT4kovpfTf6oC9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PtATjL6K51VfTkv97ezps9CNTquqj1brG1AGXx7ZG4U=; b=LAAaLM3wUpdtPWtbC9RSs/ZIPZLxmo39PMy5dKBlrXMhGvaoX32jWZjvo9ulqxOrBFLHl6BjSTyMKTjiIIF1kYrQzvZ0P+d2PAFy3cAE3G9s9v7BpONebFn/hYWd4GqbIn6XzFN3PVjNMRT7TO114+n039AcEN/mUEu7262LBAs= Received: from LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM (20.176.158.15) by LO2P123MB2509.GBRP123.PROD.OUTLOOK.COM (20.176.154.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.26; Tue, 4 Feb 2020 10:50:48 +0000 Received: from LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM ([fe80::6c1f:7fed:462a:e846]) by LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM ([fe80::6c1f:7fed:462a:e846%4]) with mapi id 15.20.2686.031; Tue, 4 Feb 2020 10:50:48 +0000 From: To: , CC: , , , Thread-Topic: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV2yJd79b2oiKy50+FV/WjhFt0i6gKt7MAgAAD8YCAAARpAIAACscAgAAJ4ICAAADZgIAABgOw Date: Tue, 4 Feb 2020 10:50:48 +0000 Message-ID: References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> <48EF7410-16B7-4B08-A9E2-5605D4714E1E@kuehlewind.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=chris.box@bt.com; x-originating-ip: [193.113.48.7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b1c59996-86a7-4487-2f62-08d7a9601877 x-ms-traffictypediagnostic: LO2P123MB2509: x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(346002)(376002)(396003)(189003)(199004)(55016002)(9686003)(81166006)(81156014)(8676002)(76116006)(66446008)(66556008)(33656002)(64756008)(316002)(54906003)(8936002)(5660300002)(110136005)(66476007)(66946007)(52536014)(86362001)(7696005)(26005)(186003)(4326008)(71200400001)(478600001)(2906002)(53546011)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P123MB2509; H:LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P62f2swts57s3IiOkzUItNtMPWph1JdqY2TeX9m7RisDOj3uCJqmEOlk4Cb20KVhKzJ98h9d5JtuPCxVgsbFeJ0eJaRLP+YV++wrC4OGE7oDHeD4loPl2aSCPSy1bOPjCmSZfCzuIemRjLimFOYGN4k47XTVYpao3rwk95xKpFC1/dAbTQbFW0ATgIXBPEKpQpo+eO+vCt82vkRoPVwGeXCp18n41UtqgEwEgldIPcjoIPvIUXoNzLYqYJa6OTvuGZ6+t+Lk39n+oT+HYgXk1O91HQQFYuPBC6JoFedX+Q3fKWeIlSe35t7COT32GXxU9f4CBkObftaELoi3HhG0wvoR+ic1kSmL5jOgw7kguKZ2UN2bg80AW5IZukY7VnepqxEigmqEBfFFFXM79YaC2TuYnBF0R4i6dLuQSJ5WRoSx3GaRIaJx3g4CCrdFtNaD x-ms-exchange-antispam-messagedata: sOZADkwc1Z2OqUIOSGOlO61StJGGgDqs+BQAMcsmd3nxvy0Qw30dLvchZPvQQueThkse54wa0sdA8Np6TSKPVoueYRUfAv+2fplfCUWKzpqfuNYXio3FtW0YTAw5D7QOM377pfhOhsCGY7uCdvUmNw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB2256677A78095F1B5178C1CF9B030LO2P123MB2256GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b1c59996-86a7-4487-2f62-08d7a9601877 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 10:50:48.7513 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YeBUxADoIXsPnmlEe+e6sqZZxO+Oz2AWOgSyqiT1k9+LFjXoJdE1r1iXW1v0BZjWejehD/RvmTN/OUv2d1/2Bw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2509 X-OriginatorOrg: bt.com Archived-At: Subject: Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 10:50:56 -0000 --_000_LO2P123MB2256677A78095F1B5178C1CF9B030LO2P123MB2256GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UkZDODQ4NCBpcyBhIHN1Y2Nlc3NmdWwgcHJvdG9jb2wsIGFuZCBzb2x2ZXMgc29tZSBnZW51aW5l IHByaXZhY3kgcHJvYmxlbXMuDQoNCg0KDQpCdXQgSSBhZ3JlZSB3aXRoIE1pcmphIHRoYXQgaXQg d291bGQgaGF2ZSBiZWVuIGJldHRlciB0byBzdGFydCBzb2x2aW5nIHRoZSBkZXBsb3ltZW50IGlz c3VlcyBpbiAyMDE4IHJhdGhlciB0aGFuIDIwMjAuDQoNCg0KDQpXb3VsZCB0aGlzIGhhdmUgZGVs YXllZCB0aGUgdGVjaG5pY2FsIHdvcms/IFllcywgYnV0IGl0IGlzIGVhc3kgdG8gc2VlIHRoYXQg dGhlIGFkb3B0aW9uIG9mIERvSCBoYXMgYmVlbiBkZWxheWVkIGJ5IGZhaWxpbmcgdG8gYWRkcmVz cyB0aGVtLiBUaGUgcHJvYmxlbXMgbmVlZCBzb2x2aW5nLCBhbmQgaXQncyBnb29kIHRoYXQgdGhl IHByb3Bvc2VkIEFERCBjaGFydGVyIHdpbGwgdGFja2xlIHRoaXMgaXNzdWUuIFdpdGhvdXQgdGhl IG5ldyB3b3JraW5nIGdyb3VwLCBhZG9wdGlvbiBvZiBEb0ggd2lsbCBpbiBwcmFjdGljZSBiZSBs aW1pdGVkIHRvIHBhcnRpY3VsYXIgYXJlYXMgb3IgdXNlIGNhc2VzLiBPciB3ZSdsbCBmaW5kIHRo YXQgaXQgY3JlYXRlcyBhIG5ldyBjbGFzcyBvZiBwcm9ibGVtcy4NCg0KDQoNClRoZXJlZm9yZSBJ IHN1cHBvcnQgdGhlIEFERCBjaGFydGVyLCBhbmQgSSdtIHdpbGxpbmcgdG8gd29yayBvbiBzb21l IGRyYWZ0cyBpbiB0aGUgd2csIGluIGEgc3Bpcml0IG9mIHJlc3BlY3QgYW5kIGNvLW9wZXJhdGlv bi4NCg0KDQoNCkNocmlzDQoNCg0KRnJvbTogQWRkIDxhZGQtYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIFJvYiBTYXlyZQ0KU2VudDogMDQgRmVicnVhcnkgMjAyMCAxMDoyOQ0KVG86IE1p cmphIEt1ZWhsZXdpbmQgPGlldGZAa3VlaGxld2luZC5uZXQ+DQpDYzogQUREIE1haWxpbmcgbGlz dCA8YWRkQGlldGYub3JnPjsgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT47IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPjsgYWRkLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBZGRd IEFkYW0gUm9hY2gncyBObyBPYmplY3Rpb24gb24gY2hhcnRlci1pZXRmLWFkZC0wMC0wMDogKHdp dGggQ09NTUVOVCkNCg0KT24gVHVlLCBGZWIgNCwgMjAyMCBhdCAyOjI2IEFNIE1pcmphIEt1ZWhs ZXdpbmQgPGlldGZAa3VlaGxld2luZC5uZXQ8bWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQ+PiB3 cm90ZToNCkp1c3QgdG8gY2xhcmlmeSBJIGRpZG7igJl0IHNheSB0aGF0IERvSCBpcyBub3QgYSBn b29kIHByb3RvY29sIG9yIHRoYXQgaXMgbm90IHN1Y2Nlc3NmdWw7IGp1c3Qgc2F5aW5nIGRpc2N1 c3Npb25zIHdlIGhhdmUgcmlnaHQgbm93IG1pZ2h0IGhhdmUgYmVlbiBtb3JlIHByb2R1Y3RpdmUg d2hlbiB3ZSB3b3VsZCBoYXZlIGhhZCB0aGF0IGRpc2N1c3Npb24gaW4gcGFyYWxsZWwgdG8gdGhl IHRlY2huaWNhbCB3b3JrLg0KDQpTdGlsbCBkbyBub3QgYWdyZWUuIFRoZSB0ZWNobmljYWwgd29y ayB3b3VsZCBub3QgYmUgZG9uZSBpZiB0aWVkIHRvIHRoZSAiZGlzY3Vzc2lvbnMiIHdlJ3JlIGhh dmluZyBub3cuDQoNCnRoYW5rcywNClJvYg0KDQo= --_000_LO2P123MB2256677A78095F1B5178C1CF9B030LO2P123MB2256GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4 dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+UkZDODQ4NCBpcyBhIHN1Y2Nlc3NmdWwgcHJvdG9jb2wsIGFu ZCBzb2x2ZXMgc29tZSBnZW51aW5lIHByaXZhY3kgcHJvYmxlbXMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkJ1dCBJIGFncmVlIHdpdGggTWlyamEgdGhhdCBpdCB3b3VsZCBoYXZlIGJl ZW4gYmV0dGVyIHRvIHN0YXJ0IHNvbHZpbmcgdGhlIGRlcGxveW1lbnQgaXNzdWVzIGluIDIwMTgg cmF0aGVyIHRoYW4gMjAyMC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V291bGQgdGhp cyBoYXZlIGRlbGF5ZWQgdGhlIHRlY2huaWNhbCB3b3JrPyBZZXMsIGJ1dCBpdCBpcyBlYXN5IHRv IHNlZSB0aGF0IHRoZSBhZG9wdGlvbiBvZiBEb0ggaGFzIGJlZW4gZGVsYXllZCBieSBmYWlsaW5n IHRvIGFkZHJlc3MgdGhlbS4gVGhlIHByb2JsZW1zIG5lZWQgc29sdmluZywgYW5kIGl0J3MgZ29v ZCB0aGF0IHRoZSBwcm9wb3NlZCBBREQgY2hhcnRlciB3aWxsIHRhY2tsZSB0aGlzIGlzc3VlLg0K IFdpdGhvdXQgdGhlIG5ldyB3b3JraW5nIGdyb3VwLCBhZG9wdGlvbiBvZiBEb0ggd2lsbCBpbiBw cmFjdGljZSBiZSBsaW1pdGVkIHRvIHBhcnRpY3VsYXIgYXJlYXMgb3IgdXNlIGNhc2VzLiBPciB3 ZSdsbCBmaW5kIHRoYXQgaXQgY3JlYXRlcyBhIG5ldyBjbGFzcyBvZiBwcm9ibGVtcy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlcmVmb3JlIEkgc3VwcG9ydCB0aGUgQUREIGNoYXJ0 ZXIsIGFuZCBJJ20gd2lsbGluZyB0byB3b3JrIG9uIHNvbWUgZHJhZnRzIGluIHRoZSB3ZywgaW4g YSBzcGlyaXQgb2YgcmVzcGVjdCBhbmQgY28tb3BlcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNocmlzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEFkZCAmbHQ7YWRk LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYiBTYXlyZTxicj4N CjxiPlNlbnQ6PC9iPiAwNCBGZWJydWFyeSAyMDIwIDEwOjI5PGJyPg0KPGI+VG86PC9iPiBNaXJq YSBLdWVobGV3aW5kICZsdDtpZXRmQGt1ZWhsZXdpbmQubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4g QUREIE1haWxpbmcgbGlzdCAmbHQ7YWRkQGlldGYub3JnJmd0OzsgQWRhbSBSb2FjaCAmbHQ7YWRh bUBub3N0cnVtLmNvbSZndDs7IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgYWRkLWNo YWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0FkZF0gQWRhbSBSb2FjaCdz IE5vIE9iamVjdGlvbiBvbiBjaGFydGVyLWlldGYtYWRkLTAwLTAwOiAod2l0aCBDT01NRU5UKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVHVlLCBGZWIgNCwgMjAyMCBhdCAyOjI2IEFNIE1pcmphIEt1ZWhsZXdpbmQgJmx0Ozxh IGhyZWY9Im1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0Ij5pZXRmQGt1ZWhsZXdpbmQubmV0PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCB0byBjbGFyaWZ5IEkgZGlkbuKAmXQgc2F5IHRoYXQg RG9IIGlzIG5vdCBhIGdvb2QgcHJvdG9jb2wgb3IgdGhhdCBpcyBub3Qgc3VjY2Vzc2Z1bDsganVz dCBzYXlpbmcgZGlzY3Vzc2lvbnMgd2UgaGF2ZSByaWdodCBub3cgbWlnaHQgaGF2ZSBiZWVuIG1v cmUgcHJvZHVjdGl2ZSB3aGVuIHdlIHdvdWxkIGhhdmUgaGFkIHRoYXQgZGlzY3Vzc2lvbiBpbiBw YXJhbGxlbCB0byB0aGUgdGVjaG5pY2FsIHdvcmsuDQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0aWxsIGRvIG5vdCBhZ3JlZS4g VGhlIHRlY2huaWNhbCB3b3JrIHdvdWxkIG5vdCBiZSBkb25lIGlmIHRpZWQgdG8gdGhlICZxdW90 O2Rpc2N1c3Npb25zJnF1b3Q7IHdlJ3JlIGhhdmluZyBub3cuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYW5rcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvYjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_LO2P123MB2256677A78095F1B5178C1CF9B030LO2P123MB2256GBRP_-- From nobody Tue Feb 4 03:33:14 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722B5120152 for ; Tue, 4 Feb 2020 03:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIRjNncr55tp for ; Tue, 4 Feb 2020 03:33:11 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12051120144 for ; Tue, 4 Feb 2020 03:33:11 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 09D5A2420C28; Tue, 4 Feb 2020 11:33:08 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> Date: Tue, 4 Feb 2020 11:33:06 +0000 Cc: ADD Mailing list , Barry Leiba Content-Transfer-Encoding: quoted-printable Message-Id: References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 11:33:13 -0000 With one minor tweak, I support the proposed charter and am willing to = work on the suggested deliverables. Thanks for putting this together = Tommy. IMO "develop an informational document that describes how client = applications and systems can manage selection of DNS resolvers in = various network environments and use cases=E2=80=9D might be too = ambitious for a single document. It might be better to say =E2=80=9Cdevelo= p a set of informational documents..=E2=80=9D in case it turns out that = precisely targeted documents for specific use cases -- split DNS, = enterprise networks, coffee shop captive portals, home nets lurking = behind NAT, etc -- are more digestible than one document which tries to = cover all possible scenarios. The recent comments about avoiding contentious issues in the new WG are = well intentioned. Though I think they=E2=80=99re been over-stated. Given = recent experiences, I very much doubt anyone will be stupid enough to = come to the new WG and propose working on topics that are likely to = create trouble and/or fail to make progress. Besides, there would be = plenty of objections (and therefore no consensus) if they tried. Next, = if it later transpired some work item did end up drifting into that = territory, we should be able to rely on the WG co-chairs and/or the = overseeing AD to intervene and ensure common sense prevails. It=E2=80=99s = not unknown for IETF WGs to have contentious or unproductive discussions = and charter wording hasn=E2=80=99t made much difference to that. From nobody Tue Feb 4 03:58:06 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A041200F7; Tue, 4 Feb 2020 03:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sky.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nSBKuLKN9Cn; Tue, 4 Feb 2020 03:57:59 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140045.outbound.protection.outlook.com [40.107.14.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6371200A4; Tue, 4 Feb 2020 03:57:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IUL5G04xI/Qv8xpsipvgEeU2Ovk2iHzt9OHq/8jCzxjm6kMLUC2226RGhhynwxNlJNIxbzfve6cNrt2xzMuqdjfprdRPE2ZgCrt0HSwnrH518EA30Q/P9eh6MxzoyInUaKU4dZEgjvOKPWR2uXptuWmneKD86yYLnur/LDi18BYwQIFAud4V0tPYZ4AjBnoQzbwAndosppZz59XpyqDemem7BaNg8iXRMiAU82wadILvLMMrydNI6rkHrSd24n8FF1kmxxtlPMFaasfW11ErbGvKZ6A+BZ3nW/kOekw4La+nmEkZd7Wgn1D+99e3FXk44r6Aqt2EdYqpOzhl105GZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lyxm8CksN4xJXK8I/gGFPi/yys2U8Ysjt90HP85XBvA=; b=Y3kqKJ4Mbe7TSKC5+9RsfONjru7GUsV/4gdlHXXUO/vVjERpy5EYjva3ojQKa5SPLjMDvo+KSC/yqHz2NkK2UccL4dFQDII+D2eVbGoa4UksCGczVmHVKrUj/BZq8F7RoiKVwxWWpgJE9LT80v3jSTbTdkuxGU/yarvUNHFln4SMUzpFIxyzvZEmnm6yBnx2T7n+AsXBdt+MHr/9J0drjbCf+PzwWViVRxMtaOGr22iGcmdpI20U1FsohiRexvGGxGv6OrJXXdzFLTr9pmndGcElEhm8qDiu1ux9t6hj6N3m07r5ndf69oRXVBjeYq7e8v/0mFWicIpZ+qp41OhTFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sky.uk; dmarc=pass action=none header.from=sky.uk; dkim=pass header.d=sky.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lyxm8CksN4xJXK8I/gGFPi/yys2U8Ysjt90HP85XBvA=; b=LEVVg/8IEg/EviOb47eaJ/gHBi89LkD9wxzt0AQBpIThABPX6g1xpgiJsdXFA55N3Ef6orhzK/+Y5OhlmPAHfultEo8G+CH3VEMNsKeJgp94mAVYWYMjo5S8nSxQg06K528oNvfyEc0165UViEK7cZD7x0NUAgh2MONpGf8bmkA= Received: from DB8PR06MB6521.eurprd06.prod.outlook.com (52.135.60.13) by DB8PR06MB6491.eurprd06.prod.outlook.com (52.135.61.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.30; Tue, 4 Feb 2020 11:57:52 +0000 Received: from DB8PR06MB6521.eurprd06.prod.outlook.com ([fe80::55b:cd77:10e9:ba71]) by DB8PR06MB6521.eurprd06.prod.outlook.com ([fe80::55b:cd77:10e9:ba71%7]) with mapi id 15.20.2686.034; Tue, 4 Feb 2020 11:57:52 +0000 From: "Winfield, Alister" To: "chris.box@bt.com" , "sayrer@gmail.com" , "ietf@kuehlewind.net" CC: "add@ietf.org" , "adam@nostrum.com" , "iesg@ietf.org" , "add-chairs@ietf.org" Thread-Topic: [EXTERNAL] Re: [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV2zcIXPBFLTirKESuStiyLHi2e6gKu3uAgAAEaQCAAArHAIAACeCAgAAA2YCAAAYYAIAAEryA Date: Tue, 4 Feb 2020 11:57:51 +0000 Message-ID: References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <76E8C9CA-1BFF-4D0B-836D-8C29EE2D4057@kuehlewind.net> <48EF7410-16B7-4B08-A9E2-5605D4714E1E@kuehlewind.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alister.Winfield@sky.uk; x-originating-ip: [90.216.150.239] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7830aef9-ef18-498d-7f58-08d7a9697683 x-ms-traffictypediagnostic: DB8PR06MB6491: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(199004)(189003)(33656002)(4326008)(81166006)(54906003)(53546011)(2616005)(8676002)(6506007)(2906002)(8936002)(71200400001)(110136005)(6512007)(498600001)(86362001)(5660300002)(26005)(81156014)(6486002)(66556008)(91956017)(66946007)(66476007)(186003)(76116006)(64756008)(66446008)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB8PR06MB6491; H:DB8PR06MB6521.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: sky.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ucOpXmUG258j15hrlUQEIWqnLGQgWuAbQLMVEC3s/DRBGhN5KluI8+vu0zdPiF3uzfE10EMI6PwNme3esYl3DVCxai2RziQJCzwoD3OnOssLY/MIcpqHP/V4SvUeHoPXio0aNlkX6s5P2oEyBZJlrey3gZhDG/fBlOxRIeYJNrtKisLQqVMMwqibdaag3BY9j3iScRkyFFNG7SXzBy4Lm1VhpQqkU7XTIkQF/5b4oS3zUXx2D6xG/RvZ4bmE/YPdBxVYLc9+1EDuJEYxGmKMnTRi2ficge1Cjck20Focbhp6k/FPZxyuV6h5u5xsSR73kVjlWPb25gLHDRk2xbt7/yQ2k5znspVloqubwmUD74S2D9wj3CIOMsOocEcfhrdNI1N0cjuDpieUYLpJklb6zzMAHHUblaM2LuC14k3rOXYSNHmbO658gj2LSdUXz3Rq x-ms-exchange-antispam-messagedata: Z9b4LH2Zk3eXdWmhTOpuN2zzjoyXG/hUYFoGnBuGDmZluw+bhGjxQ1Tehv6EqfiOjB172oAe5DlbqpipzgCJS63UlXhG1P44/IeD+UmiWw0krWHLTzWaMhki+wuEZ9qD7mQh/m8dNB8HrHxZEyFiDQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_A9ECC235C6E24C209EE6867CC6327951skyuk_" MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 7830aef9-ef18-498d-7f58-08d7a9697683 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 11:57:52.0009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JsGcnwiVaFAcHPN87vWT8PdXU6iP8dl+mZlNa/eVylLPd+6uenHMImcU4eCrGakoj1EyyITfLKE6m8LUnP9QWw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR06MB6491 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 11:58:01 -0000 --_000_A9ECC235C6E24C209EE6867CC6327951skyuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSBSRkM4NDg0IHdvcmtzIHdlbGwgYXMgYSBwcm90b2NvbCBhbmQgaGFzIHNvbWUgdmVy eSBnb29kIHVzZS1jYXNlcy4gVGhlcmUgYXJlLCBob3dldmVyLCBzb21lIGlzc3VlcyBpbiBkZXBs b3ltZW50cyB3aGljaCBJIGhvcGUgYW5kIGJlbGlldmUgY2FuIGJlIHNvbHZlZC4NCg0KVGhlcmVm b3JlLCBJIHN1cHBvcnQgdGhlIEFERCBjaGFydGVyIGFuZCBsb29rIGZvcndhcmQgdG8gd29ya2lu ZyBvbiBkcmFmdHMgaW4gdGhlIHdnLg0KDQpBbGlzdGVyIFdpbmZpZWxkLg0KDQpQczogSnVzdCBy ZWFkIEppbeKAmXMgY29tbWVudCBhbmQgYWdyZWUgdXNlLWNhc2VzIG91Z2h0IHRvIGJlIC8gYWxs b3cgbXVsdGlwbGUgdXNlLWNhc2UgZG9jdW1lbnRzLiBXZSBjYW4gYWx3YXlzIGNvbWJpbmUgdGhl bSBpZiBhbmQgd2hlbiBjb21tb25hbGl0aWVzIGFyZSBmb3VuZC4NCg0KDQpGcm9tOiBBZGQgPGFk ZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgImNocmlzLmJveEBidC5jb20iIDxjaHJp cy5ib3hAYnQuY29tPg0KRGF0ZTogVHVlc2RheSwgNCBGZWJydWFyeSAyMDIwIGF0IDEwOjUxDQpU bzogInNheXJlckBnbWFpbC5jb20iIDxzYXlyZXJAZ21haWwuY29tPiwgImlldGZAa3VlaGxld2lu ZC5uZXQiIDxpZXRmQGt1ZWhsZXdpbmQubmV0Pg0KQ2M6ICJhZGRAaWV0Zi5vcmciIDxhZGRAaWV0 Zi5vcmc+LCAiYWRhbUBub3N0cnVtLmNvbSIgPGFkYW1Abm9zdHJ1bS5jb20+LCAiaWVzZ0BpZXRm Lm9yZyIgPGllc2dAaWV0Zi5vcmc+LCAiYWRkLWNoYWlyc0BpZXRmLm9yZyIgPGFkZC1jaGFpcnNA aWV0Zi5vcmc+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbQWRkXSBBZGFtIFJvYWNoJ3MgTm8g T2JqZWN0aW9uIG9uIGNoYXJ0ZXItaWV0Zi1hZGQtMDAtMDA6ICh3aXRoIENPTU1FTlQpDQoNCg0K UkZDODQ4NCBpcyBhIHN1Y2Nlc3NmdWwgcHJvdG9jb2wsIGFuZCBzb2x2ZXMgc29tZSBnZW51aW5l IHByaXZhY3kgcHJvYmxlbXMuDQoNCg0KDQpCdXQgSSBhZ3JlZSB3aXRoIE1pcmphIHRoYXQgaXQg d291bGQgaGF2ZSBiZWVuIGJldHRlciB0byBzdGFydCBzb2x2aW5nIHRoZSBkZXBsb3ltZW50IGlz c3VlcyBpbiAyMDE4IHJhdGhlciB0aGFuIDIwMjAuDQoNCg0KDQpXb3VsZCB0aGlzIGhhdmUgZGVs YXllZCB0aGUgdGVjaG5pY2FsIHdvcms/IFllcywgYnV0IGl0IGlzIGVhc3kgdG8gc2VlIHRoYXQg dGhlIGFkb3B0aW9uIG9mIERvSCBoYXMgYmVlbiBkZWxheWVkIGJ5IGZhaWxpbmcgdG8gYWRkcmVz cyB0aGVtLiBUaGUgcHJvYmxlbXMgbmVlZCBzb2x2aW5nLCBhbmQgaXQncyBnb29kIHRoYXQgdGhl IHByb3Bvc2VkIEFERCBjaGFydGVyIHdpbGwgdGFja2xlIHRoaXMgaXNzdWUuIFdpdGhvdXQgdGhl IG5ldyB3b3JraW5nIGdyb3VwLCBhZG9wdGlvbiBvZiBEb0ggd2lsbCBpbiBwcmFjdGljZSBiZSBs aW1pdGVkIHRvIHBhcnRpY3VsYXIgYXJlYXMgb3IgdXNlIGNhc2VzLiBPciB3ZSdsbCBmaW5kIHRo YXQgaXQgY3JlYXRlcyBhIG5ldyBjbGFzcyBvZiBwcm9ibGVtcy4NCg0KDQoNClRoZXJlZm9yZSBJ IHN1cHBvcnQgdGhlIEFERCBjaGFydGVyLCBhbmQgSSdtIHdpbGxpbmcgdG8gd29yayBvbiBzb21l IGRyYWZ0cyBpbiB0aGUgd2csIGluIGEgc3Bpcml0IG9mIHJlc3BlY3QgYW5kIGNvLW9wZXJhdGlv bi4NCg0KDQoNCkNocmlzDQoNCg0KRnJvbTogQWRkIDxhZGQtYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIFJvYiBTYXlyZQ0KU2VudDogMDQgRmVicnVhcnkgMjAyMCAxMDoyOQ0KVG86IE1p cmphIEt1ZWhsZXdpbmQgPGlldGZAa3VlaGxld2luZC5uZXQ+DQpDYzogQUREIE1haWxpbmcgbGlz dCA8YWRkQGlldGYub3JnPjsgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT47IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPjsgYWRkLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBZGRd IEFkYW0gUm9hY2gncyBObyBPYmplY3Rpb24gb24gY2hhcnRlci1pZXRmLWFkZC0wMC0wMDogKHdp dGggQ09NTUVOVCkNCg0KT24gVHVlLCBGZWIgNCwgMjAyMCBhdCAyOjI2IEFNIE1pcmphIEt1ZWhs ZXdpbmQgPGlldGZAa3VlaGxld2luZC5uZXQ8bWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQ+PiB3 cm90ZToNCkp1c3QgdG8gY2xhcmlmeSBJIGRpZG7igJl0IHNheSB0aGF0IERvSCBpcyBub3QgYSBn b29kIHByb3RvY29sIG9yIHRoYXQgaXMgbm90IHN1Y2Nlc3NmdWw7IGp1c3Qgc2F5aW5nIGRpc2N1 c3Npb25zIHdlIGhhdmUgcmlnaHQgbm93IG1pZ2h0IGhhdmUgYmVlbiBtb3JlIHByb2R1Y3RpdmUg d2hlbiB3ZSB3b3VsZCBoYXZlIGhhZCB0aGF0IGRpc2N1c3Npb24gaW4gcGFyYWxsZWwgdG8gdGhl IHRlY2huaWNhbCB3b3JrLg0KDQpTdGlsbCBkbyBub3QgYWdyZWUuIFRoZSB0ZWNobmljYWwgd29y ayB3b3VsZCBub3QgYmUgZG9uZSBpZiB0aWVkIHRvIHRoZSAiZGlzY3Vzc2lvbnMiIHdlJ3JlIGhh dmluZyBub3cuDQoNCnRoYW5rcywNClJvYg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBlbWFpbCBpcyBm cm9tIGFuIGV4dGVybmFsIHNvdXJjZS4gUGxlYXNlIGRvIG5vdCBvcGVuIGF0dGFjaG1lbnRzIG9y IGNsaWNrIGxpbmtzIGZyb20gYW4gdW5rbm93biBvciBzdXNwaWNpb3VzIG9yaWdpbi4gUGhpc2hp bmcgYXR0ZW1wdHMgY2FuIGJlIHJlcG9ydGVkIGJ5IHNlbmRpbmcgdGhlbSB0byBwaGlzaGluZ0Bz a3kudWsgYXMgYXR0YWNobWVudHMuIFRoYW5rIHlvdQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSW5mb3JtYXRp b24gaW4gdGhpcyBlbWFpbCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzIG1heSBiZSBwcml2aWxl Z2VkLCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciB0aGUgYWRk cmVzc2VlLiBUaGUgdmlld3MgZXhwcmVzc2VkIG1heSBub3QgYmUgb2ZmaWNpYWwgcG9saWN5LCBi dXQgdGhlIHBlcnNvbmFsIHZpZXdzIG9mIHRoZSBvcmlnaW5hdG9yLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwgYW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLiBZb3Ugc2hvdWxkIG5vdCByZXByb2R1 Y2UsIGRpc3RyaWJ1dGUsIHN0b3JlLCByZXRyYW5zbWl0LCB1c2Ugb3IgZGlzY2xvc2UgaXRzIGNv bnRlbnRzIHRvIGFueW9uZS4gUGxlYXNlIG5vdGUgd2UgcmVzZXJ2ZSB0aGUgcmlnaHQgdG8gbW9u aXRvciBhbGwgZS1tYWlsIGNvbW11bmljYXRpb24gdGhyb3VnaCBvdXIgaW50ZXJuYWwgYW5kIGV4 dGVybmFsIG5ldHdvcmtzLiBTS1kgYW5kIHRoZSBTS1kgbWFya3MgYXJlIHRyYWRlbWFya3Mgb2Yg U2t5IExpbWl0ZWQgYW5kIFNreSBJbnRlcm5hdGlvbmFsIEFHIGFuZCBhcmUgdXNlZCB1bmRlciBs aWNlbmNlLg0KDQpTa3kgVUsgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyOTA2OTkxKSwgU2t5 LUluLUhvbWUgU2VydmljZSBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDIwNjcwNzUpLCBTa3kg U3Vic2NyaWJlcnMgU2VydmljZXMgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyMzQwMTUwKSBh bmQgU2t5IENQIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gOTUxMzI1OSkgYXJlIGRpcmVjdCBv ciBpbmRpcmVjdCBzdWJzaWRpYXJpZXMgb2YgU2t5IExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4g MjI0NzczNSkuIEFsbCBvZiB0aGUgY29tcGFuaWVzIG1lbnRpb25lZCBpbiB0aGlzIHBhcmFncmFw aCBhcmUgaW5jb3Jwb3JhdGVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzIGFuZCBzaGFyZSB0aGUgc2Ft ZSByZWdpc3RlcmVkIG9mZmljZSBhdCBHcmFudCBXYXksIElzbGV3b3J0aCwgTWlkZGxlc2V4IFRX NyA1UUQNCg== --_000_A9ECC235C6E24C209EE6867CC6327951skyuk_ Content-Type: text/html; charset="utf-8" Content-ID: <0D2821347A37344F8E8958D62BEEB53A@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWlu IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFn cmVlIFJGQzg0ODQgd29ya3Mgd2VsbCBhcyBhIHByb3RvY29sIGFuZCBoYXMgc29tZSB2ZXJ5IGdv b2QgdXNlLWNhc2VzLiBUaGVyZSBhcmUsIGhvd2V2ZXIsIHNvbWUgaXNzdWVzIGluIGRlcGxveW1l bnRzIHdoaWNoIEkgaG9wZSBhbmQgYmVsaWV2ZSBjYW4gYmUgc29sdmVkLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZXJl Zm9yZSwgSSBzdXBwb3J0IHRoZSBBREQgY2hhcnRlciBhbmQgbG9vayBmb3J3YXJkIHRvIHdvcmtp bmcgb24gZHJhZnRzIGluIHRoZSB3Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QWxpc3RlciBXaW5maWVsZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UHM6 IEp1c3QgcmVhZCBKaW3igJlzIGNvbW1lbnQgYW5kIGFncmVlIHVzZS1jYXNlcyBvdWdodCB0byBi ZSAvIGFsbG93IG11bHRpcGxlIHVzZS1jYXNlIGRvY3VtZW50cy4gV2UgY2FuIGFsd2F5cyBjb21i aW5lIHRoZW0gaWYgYW5kIHdoZW4gY29tbW9uYWxpdGllcyBhcmUgZm91bmQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5BZGQgJmx0O2FkZC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgJnF1 b3Q7Y2hyaXMuYm94QGJ0LmNvbSZxdW90OyAmbHQ7Y2hyaXMuYm94QGJ0LmNvbSZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+VHVlc2RheSwgNCBGZWJydWFyeSAyMDIwIGF0IDEwOjUxPGJyPg0KPGI+VG86 IDwvYj4mcXVvdDtzYXlyZXJAZ21haWwuY29tJnF1b3Q7ICZsdDtzYXlyZXJAZ21haWwuY29tJmd0 OywgJnF1b3Q7aWV0ZkBrdWVobGV3aW5kLm5ldCZxdW90OyAmbHQ7aWV0ZkBrdWVobGV3aW5kLm5l dCZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O2FkZEBpZXRmLm9yZyZxdW90OyAmbHQ7YWRkQGll dGYub3JnJmd0OywgJnF1b3Q7YWRhbUBub3N0cnVtLmNvbSZxdW90OyAmbHQ7YWRhbUBub3N0cnVt LmNvbSZndDssICZxdW90O2llc2dAaWV0Zi5vcmcmcXVvdDsgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7 LCAmcXVvdDthZGQtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDthZGQtY2hhaXJzQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bRVhURVJOQUxdIFJlOiBbQWRkXSBBZGFtIFJvYWNo J3MgTm8gT2JqZWN0aW9uIG9uIGNoYXJ0ZXItaWV0Zi1hZGQtMDAtMDA6ICh3aXRoIENPTU1FTlQp PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlJGQzg0ODQgaXMgYSBzdWNjZXNzZnVsIHByb3RvY29sLCBhbmQgc29sdmVzIHNvbWUgZ2VudWlu ZSBwcml2YWN5IHByb2JsZW1zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CdXQgSSBh Z3JlZSB3aXRoIE1pcmphIHRoYXQgaXQgd291bGQgaGF2ZSBiZWVuIGJldHRlciB0byBzdGFydCBz b2x2aW5nIHRoZSBkZXBsb3ltZW50IGlzc3VlcyBpbiAyMDE4IHJhdGhlciB0aGFuIDIwMjAuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldvdWxkIHRoaXMgaGF2ZSBkZWxheWVkIHRoZSB0 ZWNobmljYWwgd29yaz8gWWVzLCBidXQgaXQgaXMgZWFzeSB0byBzZWUgdGhhdCB0aGUgYWRvcHRp b24gb2YgRG9IIGhhcyBiZWVuIGRlbGF5ZWQgYnkgZmFpbGluZyB0byBhZGRyZXNzIHRoZW0uIFRo ZSBwcm9ibGVtcyBuZWVkIHNvbHZpbmcsIGFuZCBpdCdzIGdvb2QgdGhhdCB0aGUgcHJvcG9zZWQg QUREIGNoYXJ0ZXIgd2lsbCB0YWNrbGUgdGhpcyBpc3N1ZS4NCiBXaXRob3V0IHRoZSBuZXcgd29y a2luZyBncm91cCwgYWRvcHRpb24gb2YgRG9IIHdpbGwgaW4gcHJhY3RpY2UgYmUgbGltaXRlZCB0 byBwYXJ0aWN1bGFyIGFyZWFzIG9yIHVzZSBjYXNlcy4gT3Igd2UnbGwgZmluZCB0aGF0IGl0IGNy ZWF0ZXMgYSBuZXcgY2xhc3Mgb2YgcHJvYmxlbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlRoZXJlZm9yZSBJIHN1cHBvcnQgdGhlIEFERCBjaGFydGVyLCBhbmQgSSdtIHdpbGxpbmcg dG8gd29yayBvbiBzb21lIGRyYWZ0cyBpbiB0aGUgd2csIGluIGEgc3Bpcml0IG9mIHJlc3BlY3Qg YW5kIGNvLW9wZXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5DaHJpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBBZGQgJmx0O2FkZC1ib3VuY2VzQGlldGYub3JnJmd0 Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2IgU2F5cmU8YnI+DQo8Yj5TZW50OjwvYj4gMDQgRmVi cnVhcnkgMjAyMCAxMDoyOTxicj4NCjxiPlRvOjwvYj4gTWlyamEgS3VlaGxld2luZCAmbHQ7aWV0 ZkBrdWVobGV3aW5kLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IEFERCBNYWlsaW5nIGxpc3QgJmx0 O2FkZEBpZXRmLm9yZyZndDs7IEFkYW0gUm9hY2ggJmx0O2FkYW1Abm9zdHJ1bS5jb20mZ3Q7OyBU aGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7IGFkZC1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtBZGRdIEFkYW0gUm9hY2gncyBObyBPYmplY3Rpb24gb24gY2hh cnRlci1pZXRmLWFkZC0wMC0wMDogKHdpdGggQ09NTUVOVCk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDQsIDIw MjAgYXQgMjoyNiBBTSBNaXJqYSBLdWVobGV3aW5kICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBr dWVobGV3aW5kLm5ldCI+aWV0ZkBrdWVobGV3aW5kLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IHRvIGNsYXJpZnkgSSBk aWRu4oCZdCBzYXkgdGhhdCBEb0ggaXMgbm90IGEgZ29vZCBwcm90b2NvbCBvciB0aGF0IGlzIG5v dCBzdWNjZXNzZnVsOyBqdXN0IHNheWluZyBkaXNjdXNzaW9ucyB3ZSBoYXZlIHJpZ2h0IG5vdyBt aWdodCBoYXZlIGJlZW4gbW9yZSBwcm9kdWN0aXZlIHdoZW4gd2Ugd291bGQgaGF2ZSBoYWQgdGhh dCBkaXNjdXNzaW9uIGluIHBhcmFsbGVsIHRvIHRoZSB0ZWNobmljYWwgd29yay4NCjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3Rp bGwgZG8gbm90IGFncmVlLiBUaGUgdGVjaG5pY2FsIHdvcmsgd291bGQgbm90IGJlIGRvbmUgaWYg dGllZCB0byB0aGUgJnF1b3Q7ZGlzY3Vzc2lvbnMmcXVvdDsgd2UncmUgaGF2aW5nIG5vdy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmtz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9i PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48 Yj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48Yj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBlbWFpbCBp cyBmcm9tIGFuIGV4dGVybmFsIHNvdXJjZS4gUGxlYXNlIGRvIG5vdCBvcGVuIGF0dGFjaG1lbnRz IG9yIGNsaWNrIGxpbmtzIGZyb20gYW4gdW5rbm93biBvciBzdXNwaWNpb3VzIG9yaWdpbi4gUGhp c2hpbmcgYXR0ZW1wdHMNCiBjYW4gYmUgcmVwb3J0ZWQgYnkgc2VuZGluZyB0aGVtIHRvIHBoaXNo aW5nQHNreS51ayBhcyBhdHRhY2htZW50cy4gVGhhbmsgeW91PC9zcGFuPjwvYj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlciI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQpJbmZvcm1hdGlv biBpbiB0aGlzIGVtYWlsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMgbWF5IGJlIHByaXZpbGVn ZWQsIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIHRoZSBhZGRy ZXNzZWUuIFRoZSB2aWV3cyBleHByZXNzZWQgbWF5IG5vdCBiZSBvZmZpY2lhbCBwb2xpY3ksIGJ1 dCB0aGUgcGVyc29uYWwgdmlld3Mgb2YgdGhlIG9yaWdpbmF0b3IuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIGl0IGluIGVycm9yLCBwbGVhc2UNCiBub3RpZnkgdGhlIHNlbmRlciBieSByZXR1cm4gZS1t YWlsIGFuZCBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4gWW91IHNob3VsZCBub3QgcmVwcm9k dWNlLCBkaXN0cmlidXRlLCBzdG9yZSwgcmV0cmFuc21pdCwgdXNlIG9yIGRpc2Nsb3NlIGl0cyBj b250ZW50cyB0byBhbnlvbmUuIFBsZWFzZSBub3RlIHdlIHJlc2VydmUgdGhlIHJpZ2h0IHRvIG1v bml0b3IgYWxsIGUtbWFpbCBjb21tdW5pY2F0aW9uIHRocm91Z2ggb3VyIGludGVybmFsIGFuZA0K IGV4dGVybmFsIG5ldHdvcmtzLiBTS1kgYW5kIHRoZSBTS1kgbWFya3MgYXJlIHRyYWRlbWFya3Mg b2YgU2t5IExpbWl0ZWQgYW5kIFNreSBJbnRlcm5hdGlvbmFsIEFHIGFuZCBhcmUgdXNlZCB1bmRl ciBsaWNlbmNlLg0KPGJyPg0KPGJyPg0KU2t5IFVLIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4g MjkwNjk5MSksIFNreS1Jbi1Ib21lIFNlcnZpY2UgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAy MDY3MDc1KSwgU2t5IFN1YnNjcmliZXJzIFNlcnZpY2VzIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBO by4gMjM0MDE1MCkgYW5kIFNreSBDUCBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDk1MTMyNTkp IGFyZSBkaXJlY3Qgb3IgaW5kaXJlY3Qgc3Vic2lkaWFyaWVzIG9mIFNreSBMaW1pdGVkIChSZWdp c3RyYXRpb24NCiBOby4gMjI0NzczNSkuIEFsbCBvZiB0aGUgY29tcGFuaWVzIG1lbnRpb25lZCBp biB0aGlzIHBhcmFncmFwaCBhcmUgaW5jb3Jwb3JhdGVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzIGFu ZCBzaGFyZSB0aGUgc2FtZSByZWdpc3RlcmVkIG9mZmljZSBhdCBHcmFudCBXYXksIElzbGV3b3J0 aCwgTWlkZGxlc2V4IFRXNyA1UUQNCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A9ECC235C6E24C209EE6867CC6327951skyuk_-- From nobody Tue Feb 4 04:37:36 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8BF120071; Tue, 4 Feb 2020 04:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmAwxr_wDjNx; Tue, 4 Feb 2020 04:37:32 -0800 (PST) Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACE2120020; Tue, 4 Feb 2020 04:37:32 -0800 (PST) Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 014CbVXv028064 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 4 Feb 2020 12:37:31 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 Feb 2020 04:37:29 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.000; Tue, 4 Feb 2020 04:37:29 -0800 From: Paul Hoffman To: The IESG CC: ADD Mailing list , "add-chairs@ietf.org" Thread-Topic: [Ext] [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV2yJc/iWyUICO40WDKiTQaPSjN6gLf5GA Date: Tue, 4 Feb 2020 12:37:29 +0000 Message-ID: <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> In-Reply-To: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_4E1A3491-DFCF-4E54-9E06-2307DFF20F5D"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-04_03:2020-02-04, 2020-02-04 signatures=0 Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 12:37:34 -0000 --Apple-Mail=_4E1A3491-DFCF-4E54-9E06-2307DFF20F5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For: >> - 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; Adama proposed: > - 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 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.=20 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. >> - develop an informational document that describes how client >> applications and systems can manage selection of DNS resolvers >> in various network environments and use cases. >=20 > Here I agree with both EKR and =C3=89ric 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. 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= --Apple-Mail=_4E1A3491-DFCF-4E54-9E06-2307DFF20F5D Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwMjA0MTIzNzI5WjAvBgkqhkiG9w0BCQQxIgQgiA7/9J2qi5IZL/kD2MfXZDunbxVx mX7EO3y+iEujSKkwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAFqOyXqBC6A6Hcg4FPCFyVA530ohUiKsPrL8IJtOYPtS phWw5Yqzz4cezwLcStW+KDnp2c+YNpeV0SHtNE7YT2rKUo9c/qXw8B9xQAU66aNz/hB1HDAzQhfi JqEgyVg6i+5b4Yuj83+fU3bOZQwfMeXXtS4D8f+11gcJRlSXBCiNM5mXwu5Nwn44M8ESOoPbQmWW uUPgTq9DaQaO0ZqcS7zVudh4E5p1klyb/bHmoUGaY6wYRTgNxZ8bvN0albZV2dWQAnEmFOhBbGvu WOWLm66ehdQRw3ghWREyxOeEGixoX7yXVZBYIXhVF0AFdoFIHho4bEKwTtvOUnz1x+0k2XAAAAAA AAA= --Apple-Mail=_4E1A3491-DFCF-4E54-9E06-2307DFF20F5D-- From nobody Tue Feb 4 04:38:15 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE441200A4 for ; Tue, 4 Feb 2020 04:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qV9ywAmjrTf for ; Tue, 4 Feb 2020 04:38:11 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCD5120020 for ; Tue, 4 Feb 2020 04:38:10 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 738206A30C; Tue, 4 Feb 2020 13:38:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1580819887; bh=K460OpqPoO8su4DNB47zJto7DkLsnGGuzf4a1ht054M=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=c0Df0t3apTAuXNsKGJKP+lHfh76zCQ+uCWWH5xojwVxHRbhODUxX5gTLpM8XHMg8W e7BBmGVIUlBienxyVIjKH2RwKmJKC+PzVKKVikLyJVC3d7RrPJ3r6HmmUoFBx6ICSM 18LsZMfNKcRppLiYsgGYZp2NoY8uvRWT2ZRXknusrukYhPV/o3tfOTN9/R9MpEFhOj ZcEAq8R5deaUkZbaaFelrKWQZ0Po/QASd0bfAgj/dCXB5bUAMHS0J/rvYFuwwjagrB 4hJxDCR2v4A2hC6qAzGkzja7P8RZ8eXt0Oq+hDrs8tY5lvTXBpksW5ZzwfWy9sC1oQ MclEeHltYVK9g== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 65DAC3C04A7; Tue, 4 Feb 2020 13:38:07 +0100 (CET) Date: Tue, 4 Feb 2020 13:38:07 +0100 (CET) From: Vittorio Bertola To: Jim Reid , Tommy Pauly Cc: ADD Mailing list Message-ID: <1470947376.2281.1580819887323@appsuite-gw2.open-xchange.com> In-Reply-To: References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev3 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 12:38:14 -0000 > Il 04/02/2020 12:33 Jim Reid ha scritto: > > > With one minor tweak, I support the proposed charter and am willing to work on the suggested deliverables. Thanks for putting this together Tommy. I'd like to join in thanking Tommy, Glenn, Ben, the BoF chairs and everyone that has worked to advance the text. There are things in this charter that I would have written differently, starting from the name - while I see the merits of the "adaptive DNS" idea, I also think that spreading out DNS resolution queries to multiple servers at once would be a policy nightmare in terms of data protection, GDPR compliance, jurisdiction etc., and would create pushback against deployment. Still, I want to work with people that have other views and try to find common ground on a number of things on which this looks possible, so I am in favour of proceeding under the current charter. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Tue Feb 4 04:46:20 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B471200A4 for ; Tue, 4 Feb 2020 04:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IIgfMZGmXAv for ; Tue, 4 Feb 2020 04:46:13 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86635120020 for ; Tue, 4 Feb 2020 04:46:13 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id o15so12909838ljg.6 for ; Tue, 04 Feb 2020 04:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NSihEiU+ApD74KvQJgEFW2/xptKYjVjzgNfCzbKWmvU=; b=BOTOlZVK/BlMdvQ+XcTKqjJa2TTX3rk5uDmTXiEM5zGGrrjhA/GM0TJcTTrXZSU1Tn lKAVct+JVcL00kctbJLpHFvyN0DYtQdNz7ZFpn2nKUCp6N09ZlNRGL4LWTcHImhN5Crr o+mFvrtH8fCkjyySRkclnflajHIIrN0qIens4ABThyfrfnByMNpyyGGPJatxZC8B4/vd or64tpB1dDroTRFzzZkdyK2aTrh0IliPwiy4Ob6bQ8+SDd8C9T4UL6UOvWjmyWp+iQHy X5Plu+yQfsZs/EIsfiHDNMqdtpHAEn3aI2wK2JEPmOGWC9BAKoeSbRq/8y74cXkcnP4h IqgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NSihEiU+ApD74KvQJgEFW2/xptKYjVjzgNfCzbKWmvU=; b=ZQNPp5mwpPfNgWNqIlq5bWFvWw6esVc5ZpNQXZ6Gwlq6bf7tgV/Z113C0mw27UGdEB KGkb9vsMwAGtSExdSEtZTZxvQN0EkiM3VOx8p19qV18WhfbyNPxDHlpDU1xtY2ObTPNg ue674soXdcrffmGIoYiOvNQnUs0p+LMUQwLEWsbAhctpQGuqyaUJT7xZt9L//rnmmCUw SOn+usMWSL0IMfh+E8T2mJhGhmIwZ9WmtAFTqDbe9dJvzOi/XR4AKIRg9QNpkBbDlqE0 hYPcqXVJoYq2ehpZ+mAPM2tpbkb8w4yfpmTPC1SF2OZFp55rKVe1ctIyV05VSFEOrjFg tTpw== X-Gm-Message-State: APjAAAXeP7ge9hIFQg8oitqswwZyFOiLILuHB/YEClAtAn+a8pzcxutI 3D0jnDYQol121oDp+h0B79iHro9pAW3gGrPMzUdJOQ== X-Google-Smtp-Source: APXvYqwBPoQREY+j1T2oQbitcKfkghOLb8OV3v560yd7TO2pFrhKspG/XNMyxn2a8uEAua6P9W9+3eovXCK6uQnZylk= X-Received: by 2002:a2e:9b12:: with SMTP id u18mr17277325lji.274.1580820371526; Tue, 04 Feb 2020 04:46:11 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> In-Reply-To: <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> From: Eric Rescorla Date: Tue, 4 Feb 2020 04:45:35 -0800 Message-ID: To: Paul Hoffman Cc: The IESG , ADD Mailing list , "add-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b2ea9f059dbf6c68" Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 12:46:17 -0000 --000000000000b2ea9f059dbf6c68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020 at 4:37 AM Paul Hoffman wrote: > > >> - 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 =C3=89ric that the described work is ope= n-ended > > enough to result in unproductive and likely toxic interactions. It woul= d > > 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 conversation= s > > 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. > > However, taking it fully off the plate will lead to the same discussions > happening repeatedly due to current deployment strategies of major vendor= s. 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: > > - after the work on the two mechanisms above is complete, the Working Gro= up > will begin developing an informational document that describes how clie= nt > applications and systems can manage selection of DNS resolvers > in various network environments and use cases. > Why not simply recharter at that point? -Ekr --000000000000b2ea9f059dbf6c68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 4:37 AM Paul H= offman <paul.hoffman@icann.org= > wrote:

>> - develop an informational document that describes how client
>>=C2=A0 applications and systems can manage selection of DNS resolve= rs
>>=C2=A0 in various network environments and use cases.
>
> Here I agree with both EKR and =C3=89ric that the described work is op= en-ended
> enough to result in unproductive and likely toxic interactions. It wou= ld
> 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 conversatio= ns
> have so far been fruitless. But I fear that putting this on the plate<= br> > as part of the first tranche of work is likely to lead to the same
> acrimony that has dogged this endeavor in the past.

However, taking it fully off the plate will lead to the same discussions ha= ppening repeatedly due to current deployment strategies of major vendors. <= /blockquote>

Well, perhaps, but we don't need an IET= F WG for those discussions and the evidence is that that's not a produc= tive venue for them.


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

- after the work on the two mechanisms above is complete, the Working Group=
=C2=A0 will begin developing an informational document that describes how c= lient
=C2=A0 applications and systems can manage selection of DNS resolvers
=C2=A0 in various network environments and use cases.
=
Why not simply recharter at that point?

=
-Ekr

--000000000000b2ea9f059dbf6c68-- From nobody Tue Feb 4 04:59:35 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B0912004E for ; Tue, 4 Feb 2020 04:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBC_4EMqf0zg for ; Tue, 4 Feb 2020 04:59:32 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA7D1200A4 for ; Tue, 4 Feb 2020 04:59:31 -0800 (PST) Received: from tpw09926dag12e.domain1.systemhost.net (10.9.212.12) by RDW083A012ED68.bt.com (10.187.98.38) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 4 Feb 2020 12:57:03 +0000 Received: from tpw09926dag13e.domain1.systemhost.net (10.9.212.13) by tpw09926dag12e.domain1.systemhost.net (10.9.212.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 4 Feb 2020 12:59:27 +0000 Received: from RDW083A012ED68.bt.com (10.187.98.38) by tpw09926dag13e.domain1.systemhost.net (10.9.212.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 4 Feb 2020 12:59:27 +0000 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.52) by smtpe1.intersmtp.com (62.239.224.234) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 4 Feb 2020 12:57:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ceujOhwwv68bI0L+pMmV3/hKpxc8er93aJxUZZIdQh6g1rBU+bDxZupTtEhAupm0C/WfGrQo20OMmu5DVGBpB8luD3TbhkaxgM1q8YNJFO3CkFibiNf9/Aevnefwf0CpHuFJ1eeM7RffrRUTf46Jr6Bjq8MCaTIVzE0fZ2FlOcxxOUOxzblhDfGlK1P2OVggtfK9Sc91PAbYaBxFXiov3HQwfwHmbvfUGM6J1pH1Lc4DPG50A9nNlNqsx7pPTB74E71DooWtcXlv1mk7VA1S2+llsRBcStOlPA5IOwWDuhddvKIn4f42b2yzUwrAsuNLLDZfz7uPB4AWX1eFBbDh7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QHO9IBlpuOI43lKru49vY/FaNlD/35unKW+a6K5fRYI=; b=fAvIrFX4Hlp9eT9vU8pXR+tDGCbl9wDZpVZXqXO6QMMnff0zmzIUPJNZpWWqhTpB4Cc2ugwoeKhv60igUxxKNIe9D5XBg+TXkljG5jm/1nTID54n770h/IagE4WQUhUCX4OSc/uD8IYlytUUoDExnpCW2ixnM6GNJjcULRkse5662FkZMk1PRmWIqaejj8NEQkjIh6HfmvwAvRzId+zBMlQd3psaIYkDGTWwE5p9+q4rggof/e0btoIdz/NXScoV535YtGP8DV7en0iMXG1oV7lodtg9SoZRRQCa2qYll+MIRcaBO//g4kzycH4hfniU6NB+GDyAWfesbmqoxVRF4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QHO9IBlpuOI43lKru49vY/FaNlD/35unKW+a6K5fRYI=; b=bq6m6I2mKiqJexF9Bx7XZ01gQcoyqqO+YkhxRZTjEh/1Ji9oIYhg+LLdY9VXu8PE+O4pZTPHZ7Qv4CMXjHQhlqrOvLK4ED2dVbCu0K3kvuWvL3M/Oq+MrGrBmUKKFyAumcgeoUoQbG3087bkXl8SgQMVkr4lNS9+pMIMseaEcuM= Received: from LO2P123MB2573.GBRP123.PROD.OUTLOOK.COM (20.176.154.203) by LO2P123MB1807.GBRP123.PROD.OUTLOOK.COM (20.176.158.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.30; Tue, 4 Feb 2020 12:59:25 +0000 Received: from LO2P123MB2573.GBRP123.PROD.OUTLOOK.COM ([fe80::f0e7:b8a8:f7dd:a715]) by LO2P123MB2573.GBRP123.PROD.OUTLOOK.COM ([fe80::f0e7:b8a8:f7dd:a715%7]) with mapi id 15.20.2686.031; Tue, 4 Feb 2020 12:59:25 +0000 From: To: Thread-Topic: [Add] Charter proposal for ADD Thread-Index: AQHV207rH0v4VSUjDEaeCY/OYelvQqgK+UmAgAAFNEA= Date: Tue, 4 Feb 2020 12:59:24 +0000 Message-ID: References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> <1470947376.2281.1580819887323@appsuite-gw2.open-xchange.com> In-Reply-To: <1470947376.2281.1580819887323@appsuite-gw2.open-xchange.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bob.sleigh@bt.com; x-originating-ip: [2a00:23c4:ba03:4a00:29be:47a1:79a0:9002] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a9ad348a-c377-4fc7-eb3b-08d7a9720fd4 x-ms-traffictypediagnostic: LO2P123MB1807: x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(366004)(136003)(396003)(346002)(199004)(189003)(81166006)(81156014)(66946007)(2906002)(76116006)(33656002)(71200400001)(64756008)(66446008)(66556008)(7696005)(5660300002)(52536014)(66476007)(55016002)(9686003)(6916009)(6506007)(316002)(8936002)(186003)(8676002)(53546011)(86362001)(966005)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P123MB1807; H:LO2P123MB2573.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KMKwn/4vbnKScTfu0NdTHGFKIV7+wwifXIHPg0DNRj2Nemi8qGCKbbs2sTU8MI6K8rKEPFZzEjRTg3mqmU+KjN0lUyNSb/3Tv2UWeCcvx+ImTsOAocnHaMyG6ZVVoaJ6T6mIEiuttuhtuFsOLoi5XSw0/F/BvT+UJhLKC4PI7IQRNVrsCPU2BWMp17Dry+KJxzOaoxvqmTSTNXAn2gTLpp7w7cBryDA/kwAYw3wwlbNxNne9YixmViPd1V8njGfNtQ6zed6os98j0vIRYeAvWyldDzaC2CUsIjcKWEp0qZ1hsdSqhoM/ZZfCqGOzhabUkE+0ytJLnA0dZvh7Ts9Z4HfT7i3O/zJSLVUultsh8PpTWe91mMIYbFCJGgBWtwcFM675LeW2x8rhdrycS80GU9f+SIfTQxTou8f+wv61d7+lbk29K3oX/2owOybst+F+K/OQlAeDEtwvX+hZtyX9O8jantdQthsaj5nDreMYD1r0QDS49LDiPZAcrxJsppwkk4/T9NVOUfCw/RPXEE+KNw== x-ms-exchange-antispam-messagedata: A6bqBWX5RxPCrmtp6GxI/OvNY7k/QPFVXNCSgM8bOu8QxvmSqmEqNXRzBoWRNvkLV2GuE/FNTuIUd8KNA6FSpRfoasotKg6Lttl/ihVvkBKchKl3luCz6rhLFPgb9+KN7c1yiFc/hqe4lX3HjGgqsH50pB1wi24FUsXwjZff/BNygXzHW/4Zt0Y4syHy4krUIsrrWqtLsDcQSL5oVib7cA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a9ad348a-c377-4fc7-eb3b-08d7a9720fd4 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 12:59:25.2422 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: h3jtgtDq5niIZ64SUXdeafNCpeLm/Yt7eNIAfln6ubRSW7Y9v0KEfrqwyS8TjFkmyHr8juNRL2L9y0KfMIItrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1807 X-OriginatorOrg: bt.com Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 12:59:34 -0000 I'm too in favour of this proposed charter and am willing to work on the su= ggested deliverables With thanks to all who have contributed so far... Regards Bob -----Original Message----- From: Add On Behalf Of Vittorio Bertola Sent: 04 February 2020 12:38 To: Jim Reid ; Tommy Pauly Cc: ADD Mailing list Subject: Re: [Add] Charter proposal for ADD > Il 04/02/2020 12:33 Jim Reid ha scritto: >=20 > =20 > With one minor tweak, I support the proposed charter and am willing to wo= rk on the suggested deliverables. Thanks for putting this together Tommy. I'd like to join in thanking Tommy, Glenn, Ben, the BoF chairs and everyone= that has worked to advance the text. There are things in this charter that= I would have written differently, starting from the name - while I see the= merits of the "adaptive DNS" idea, I also think that spreading out DNS res= olution queries to multiple servers at once would be a policy nightmare in = terms of data protection, GDPR compliance, jurisdiction etc., and would cre= ate pushback against deployment. Still, I want to work with people that hav= e other views and try to find common ground on a number of things on which = this looks possible, so I am in favour of proceeding under the current char= ter. --=20 =20 Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.berto= la@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy -- Add mailing list Add@ietf.org https://www.ietf.org/mailman/listinfo/add From nobody Tue Feb 4 05:44:08 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219D31200C3 for ; Tue, 4 Feb 2020 05:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bVolK0ABUjX for ; Tue, 4 Feb 2020 05:44:04 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100065.outbound.protection.outlook.com [40.107.10.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6249B120020 for ; Tue, 4 Feb 2020 05:44:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QyBruUUzAxR1I1B45j29AJytAMaHiDPqSO3DhinactNnzcrLOR5FB3NfB26UAYGfelGPuOlbuAjoKg4oJEcM1WCOSJ+9NU1i4lF3oAH4PlFU7m6jigYoehnPkcjrtOIEkRVVZ3//wrp8k8jjnCmTT8j6f43bVBV7I8vti9EqyE2m/182J5i5udZTRpCMvhZCQMxhxWLc+7zx/NNS775BH4CrLVq23gyzR+QvyWCDHpeVx+r1PemftCJInDMtT3n2M4Ib2rFj0+zifGgwmGMwlO0EflQK6c/UCH8e5U9JA1xrs/QGXPv2vxaw0upmk9V6tSeIKkcF4Vdt2n2aGKB6ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mGSkzjmZOHEcby6ORvRTDY0ek0RUwkiOrFDCXrCsMrg=; b=Y+VlKFhWRYchYgS4cSvjotvS1ru67AGILjKxuCrE2TycPudAE8y8FJu7GJ6tXF4yeD/OkLIVu2UpX0LLlRzHTy2D7wGHbiYWVsDWm/bKAOq06bIyqeFXU7rogQgEjOHmiExRSx1BKld+6RWY75xNBN/GbBCh8sFbpt5dBVu2QRjPD3GRFNCXSJQt0z1bNzqbPApBMY6VrdRmmPA8LI2ZBmYQh4jfSKBoYlBm9VMEaD3cjTjc8+LmKOEFiQgPakDWZZpr2lFBZm1RsJTfBoVr0/iID5nmpz91lP4eG1uief8g7Bi2ICFy+yzxttqpWfoUzuknppdtPlLhqZqcZj6MZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mGSkzjmZOHEcby6ORvRTDY0ek0RUwkiOrFDCXrCsMrg=; b=YAte/1Bps0uQUqiQEBMvTXRTu/iEdY1hWq41LjVuoxqULK3Q69FPbsVemjcv5IY1ar141q2RTWVns2aKd7oE/XpgDs/SIEKNmMHb4gQydvyN1OAbl9geMz+3bpSsZ5gX26Y8XKdB3DNLrBTvahsV7prNHH246jcHRooeAWEDBew= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB0190.GBRP265.PROD.OUTLOOK.COM (10.166.101.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.32; Tue, 4 Feb 2020 13:44:01 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af%5]) with mapi id 15.20.2686.034; Tue, 4 Feb 2020 13:44:01 +0000 From: Andrew Campling To: Jim Reid , Tommy Pauly CC: ADD Mailing list , Barry Leiba Thread-Topic: [Add] Charter proposal for ADD Thread-Index: AQHV22EnwMhv7+nTNUmDYzBUjyxA/A== Date: Tue, 4 Feb 2020 13:44:01 +0000 Message-ID: References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [2a00:23c4:a499:2e00:bc12:c64f:3fad:1ac0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9813c894-3772-454a-9f5e-08d7a9784acc x-ms-traffictypediagnostic: LO2P265MB0190: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39830400003)(396003)(136003)(376002)(366004)(199004)(189003)(86362001)(966005)(5660300002)(9686003)(30864003)(4326008)(71200400001)(44832011)(55016002)(6506007)(8676002)(8936002)(2906002)(81156014)(81166006)(186003)(508600001)(7696005)(110136005)(66556008)(76116006)(66946007)(316002)(66476007)(64756008)(54906003)(33656002)(52536014)(66446008)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB0190; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YT4lQHgw+tFcwYkOi5eW/eyU1S0alWcPmBo5sxfxnjwS3oSrTUlxIps3W56hLaNSwCmdbWVlm+RGIA5pZeTtX2QqEtjD0wZUPupOuKTlRX+mql4IiaIvmglsA3ZidY+asjdwUOnXiiGvB2jtI/Tif75wxIEtmVI+KSgJ5rLsMZ/Dt3xXki4ZgEL/Ll+RbYpA0QlzqldBHoyNSVN9PxZAmVCMnpdcjitYVJHTt2nLByA6u1V/2eJnEHarUTgZerzEPmWg2L3WN+rb/xmNB4oX7iwJ520nkWBwHmGNyJlpYVsGVUP33OucX/E1zkISsO67E1su+VfPKMuNeXNh9dHO86oeugWELmmMmga1IdKCbBUq1B9rsopeKVL2oGNrCR65m01Nu5dWV1mIhg8YPgoRmyZYNclYY3O9Mmv2YcortlAjIM9w5gI4/oSsSidh4sWDjlog4E3t02p8ciYJ+DAzTrkydHaxCZfD8eJvfnLlUP0TDYKwp3EWF5REGR3JHNOx x-ms-exchange-antispam-messagedata: dwcnRkFu4OoyA7GrAxW7CSBHSIvZbNSuLZ+PfKVchVwfTI06Yvv7xfjR9VO7jplk4k0JoHGIQSjVtrwEhzTIQ/ch69iFEB2ysAq1BXaDSK+PzroWgHLiGrphv7EGG9ujGM32ogx9GbjV8q5sqSfYJTH4kt6cgYBOYrpqC/ofiPMwi6R1LyiUpruKTVOCKVLufylOeDSEYqKOnmH/4mq0mg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573075C1D6C312C35DD29AFC2030LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 9813c894-3772-454a-9f5e-08d7a9784acc X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 13:44:01.1508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MHMYWo9jdguqIkHvBFIySOVfWUa6i6UImE1+yYj7kKs14lR9Wf8HDgbiwxkYt/JP21bplAlISjG/ZYTcyAYUYwyipLMY4yYaX/35MIsLIz8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0190 Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 13:44:07 -0000 --_000_LO2P265MB0573075C1D6C312C35DD29AFC2030LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gVHVlLCBGZWIgNCwgMjAyMCBhdCAxMTozMyBBTSBKaW0gUmVpZCA8amltQHJmYzEwMzUuY29t PiB3cm90ZToNCg0KPiBJTU8gImRldmVsb3AgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCB0aGF0 IGRlc2NyaWJlcyBob3cgY2xpZW50IGFwcGxpY2F0aW9ucyBhbmQgc3lzdGVtcyBjYW4gbWFuYWdl IHNlbGVjdGlvbg0KPiBvZiBETlMgcmVzb2x2ZXJzIGluIHZhcmlvdXMgbmV0d29yayBlbnZpcm9u bWVudHMgYW5kIHVzZSBjYXNlc+KAnSBtaWdodCBiZSB0b28gYW1iaXRpb3VzIGZvciBhIHNpbmds ZSBkb2N1bWVudC4gSXQNCj4gbWlnaHQgYmUgYmV0dGVyIHRvIHNheSDigJxkZXZlbG9wIGEgc2V0 IG9mIGluZm9ybWF0aW9uYWwgZG9jdW1lbnRzLi7igJ0gaW4gY2FzZSBpdCB0dXJucyBvdXQgdGhh dCBwcmVjaXNlbHkgdGFyZ2V0ZWQNCj4gZG9jdW1lbnRzIGZvciBzcGVjaWZpYyB1c2UgY2FzZXMg LS0gc3BsaXQgRE5TLCBlbnRlcnByaXNlIG5ldHdvcmtzLCBjb2ZmZWUgc2hvcCBjYXB0aXZlIHBv cnRhbHMsIGhvbWUgbmV0cyBsdXJraW5nDQo+IGJlaGluZCBOQVQsIGV0YyAtLSBhcmUgbW9yZSBk aWdlc3RpYmxlIHRoYW4gb25lIGRvY3VtZW50IHdoaWNoIHRyaWVzIHRvIGNvdmVyIGFsbCBwb3Nz aWJsZSBzY2VuYXJpb3MuDQoNCkknbSBpbiBmYXZvdXIgb2YgdGhlIGNoYXJ0ZXIgcHJvcG9zZWQg YnkgVG9tbXkgUGF1bHksIHdpdGggdGhlIGFtZW5kbWVudCBvZiB0aGUgdGhpcmQgZGVsaXZlcmFi bGUgaW50byBhIHNldCBvZiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50cyByYXRoZXIgdGhhbiBhIHNp bmdsZSBpdGVtLCBhcyBzdWdnZXN0ZWQgYWJvdmUsIGFuZCBhbSB3aWxsaW5nIHRvIHdvcmsgb24g dGhlIHN1Z2dlc3RlZCBkZWxpdmVyYWJsZXMuICBUaGVyZSBpcyBjbGVhcmx5IHdvcmsgdG8gYmUg ZG9uZSBoZXJlOyBJJ20gY29uZmlkZW50IHRoYXQgbGVhZGVyc2hpcCBieSB0aGUgY28tY2hhaXJz IGFuZCBBRCB3aWxsIGhlbHAgYWRkcmVzcyB0aGUgcG90ZW50aWFsIGlzc3VlcyB0aGF0IHNvbWUg aGF2ZSBmbGFnZ2VkIG9uIHRoZSBsaXN0IHdpdGhvdXQgdGhlIG5lZWQgdG8gZW5nYWdlIGluIG9w ZW4tZW5kZWQgd29yZHNtaXRoaW5nIG9mIHRoZSBjaGFydGVyLg0KDQpBbmRyZXcNCg0KDQoNCg== --_000_LO2P265MB0573075C1D6C312C35DD29AFC2030LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEycHQ7Ij4NCjxkaXY+T24gVHVlLCBGZWIgNCwgMjAyMCBhdCAxMTozMyBB TSBKaW0gUmVpZCAmbHQ7amltQHJmYzEwMzUuY29tJmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8ZGl2PiZndDsgSU1PICZxdW90O2RldmVsb3AgYW4gaW5mb3JtYXRpb25hbCBk b2N1bWVudCB0aGF0IGRlc2NyaWJlcyBob3cgY2xpZW50IGFwcGxpY2F0aW9ucyBhbmQgc3lzdGVt cyBjYW4gbWFuYWdlIHNlbGVjdGlvbiA8L2Rpdj4NCjxkaXY+Jmd0OyBvZiBETlMgcmVzb2x2ZXJz IGluIHZhcmlvdXMgbmV0d29yayBlbnZpcm9ubWVudHMgYW5kIHVzZSBjYXNlc+KAnSBtaWdodCBi ZSB0b28gYW1iaXRpb3VzIGZvciBhIHNpbmdsZSBkb2N1bWVudC4gSXQgPC9kaXY+DQo8ZGl2PiZn dDsgbWlnaHQgYmUgYmV0dGVyIHRvIHNheSDigJxkZXZlbG9wIGEgc2V0IG9mIGluZm9ybWF0aW9u YWwgZG9jdW1lbnRzLi7igJ0gaW4gY2FzZSBpdCB0dXJucyBvdXQgdGhhdCBwcmVjaXNlbHkgdGFy Z2V0ZWQgPC9kaXY+DQo8ZGl2PiZndDsgZG9jdW1lbnRzIGZvciBzcGVjaWZpYyB1c2UgY2FzZXMg LS0gc3BsaXQgRE5TLCBlbnRlcnByaXNlIG5ldHdvcmtzLCBjb2ZmZWUgc2hvcCBjYXB0aXZlIHBv cnRhbHMsIGhvbWUgbmV0cyBsdXJraW5nIDwvZGl2Pg0KPGRpdj4mZ3Q7IGJlaGluZCBOQVQsIGV0 YyAtLSBhcmUgbW9yZSBkaWdlc3RpYmxlIHRoYW4gb25lIGRvY3VtZW50IHdoaWNoIHRyaWVzIHRv IGNvdmVyIGFsbCBwb3NzaWJsZSBzY2VuYXJpb3MuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj5JJ20gaW4gZmF2b3VyIG9mIHRoZSBjaGFydGVyIHByb3Bvc2VkIGJ5IFRvbW15IFBhdWx5 LCB3aXRoIHRoZSBhbWVuZG1lbnQgb2YgdGhlIHRoaXJkIGRlbGl2ZXJhYmxlIGludG8gYSBzZXQg b2YgaW5mb3JtYXRpb25hbCBkb2N1bWVudHMgcmF0aGVyIHRoYW4gYSBzaW5nbGUgaXRlbSwgYXMg c3VnZ2VzdGVkIGFib3ZlLCBhbmQgYW0gd2lsbGluZyB0byB3b3JrIG9uIHRoZSBzdWdnZXN0ZWQg ZGVsaXZlcmFibGVzLiZuYnNwOyBUaGVyZSBpcyBjbGVhcmx5DQp3b3JrIHRvIGJlIGRvbmUgaGVy ZTsgSSdtIGNvbmZpZGVudCB0aGF0IGxlYWRlcnNoaXAgYnkgdGhlIGNvLWNoYWlycyBhbmQgQUQg d2lsbCBoZWxwIGFkZHJlc3MgdGhlIHBvdGVudGlhbCBpc3N1ZXMgdGhhdCBzb21lIGhhdmUgZmxh Z2dlZCBvbiB0aGUgbGlzdCB3aXRob3V0IHRoZSBuZWVkIHRvIGVuZ2FnZSBpbiBvcGVuLWVuZGVk IHdvcmRzbWl0aGluZyBvZiB0aGUgY2hhcnRlci48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PjxiPkFuZHJldzwvYj48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_LO2P265MB0573075C1D6C312C35DD29AFC2030LO2P265MB0573GBRP_-- From nobody Tue Feb 4 05:50:03 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A6912080F; Tue, 4 Feb 2020 05:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pMs7CeyP-9h; Tue, 4 Feb 2020 05:49:54 -0800 (PST) Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C854E1200CE; Tue, 4 Feb 2020 05:49:54 -0800 (PST) Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 014DnrIH006539 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 4 Feb 2020 13:49:54 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 Feb 2020 05:49:51 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.000; Tue, 4 Feb 2020 05:49:51 -0800 From: Paul Hoffman To: Eric Rescorla CC: ADD Mailing list , The IESG , "add-chairs@ietf.org" Thread-Topic: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV21kbLpEca0+140ykyT8g4E8lGqgLk1uA Date: Tue, 4 Feb 2020 13:49:51 +0000 Message-ID: References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_E81CE475-2ADA-48EB-9FD9-68F420CC6F7A"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-04_04:2020-02-04, 2020-02-04 signatures=0 Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 13:49:57 -0000 --Apple-Mail=_E81CE475-2ADA-48EB-9FD9-68F420CC6F7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 4, 2020, at 12:45 PM, Eric Rescorla 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= --Apple-Mail=_E81CE475-2ADA-48EB-9FD9-68F420CC6F7A Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwMjA0MTM0OTUxWjAvBgkqhkiG9w0BCQQxIgQglUwp0mjU33MP9j7orO1xhlCUxGEv /kRn/kZUiqP2zmEwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAKepJpNO1Lbj3QtozE2ahSmBs7vM54yAD5WjWmQEtuSG V6Qq8lK4GijV3kmfaD7CmuOiD+7eg1KRDDHwg4/qE4aWlvtnQyH0yn/WusTrt6jnMLGjjunbyVjs c04UP8tz6SijwbBBjQE5AQIn0b+yMEGmhTFc0/ikFMntipCBtkC60y2DkMZ+fRhSINO/smAnKAIZ WX1aMJcRa5dl+07h0grKaOazy8XNnBy6y+fuAsokWnjuY3mcQ4GlT2YzUjQF6pLiyBOoxexJrbr6 LTqVhx4zQM4RHJVkDtPMUDJODRXiea44/0yd2CDt2gBImjJHVId3CGkRqiszlGp90oT2KooAAAAA AAA= --Apple-Mail=_E81CE475-2ADA-48EB-9FD9-68F420CC6F7A-- From nobody Tue Feb 4 06:28:08 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB5C120105 for ; Tue, 4 Feb 2020 06:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_WORDY=1.651, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owy75aQ-mogw for ; Tue, 4 Feb 2020 06:28:04 -0800 (PST) Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B6512008F for ; Tue, 4 Feb 2020 06:28:04 -0800 (PST) Date: Tue, 04 Feb 2020 14:27:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1580826481; bh=ZHOTlsEdJOagJCz+q/jIQ3vPv+qhaJiqD3Zt56ZkrFo=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=pbqBH/ZuXoH8vGk4LCKGluDfZgp3s0Z8F0zkdc+2WL5aGAfqqkjC3Sc5WMLylbMYX LxNXRukUnPkexFc6rjHXmZSd7RvHquGh2E0afcMPVBCHnPPc9eXenCGz99SekfP6n2 FN4QQ2wUD/Y2Q6u4gAQuD0dlkerEAMFc/gW9/+Tk= To: Andrew Campling From: "Arnaud.Taddei.IETF" Cc: Jim Reid , Tommy Pauly , ADD Mailing list , Barry Leiba Reply-To: "Arnaud.Taddei.IETF" Message-ID: In-Reply-To: References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> Feedback-ID: kou6vaSHQeY5dgFN9dCIYKo4z6hnnNmKuV4IBJw2wx4vSVPtftyhWUTBigri6zMJ3K1hxYJjI-3RAIGaizMt5g==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_d5f065b5908d9900791c605b440112b6" Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 14:28:07 -0000 This is a multi-part message in MIME format. --b1_d5f065b5908d9900791c605b440112b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SSBhbSBpbiBmYXZvciBvZiB0aGlzIGNoYXJ0ZXIgdG9vIGFuZCB3aWxsIGRvIG15IGJlc3QgdG8g c3VwcG9ydCBhbmQgcmV2aWV3CgpTZW50IHdpdGggW1Byb3Rvbk1haWxdKGh0dHBzOi8vcHJvdG9u bWFpbC5jb20pIFNlY3VyZSBFbWFpbC4KCuKAkOKAkOKAkOKAkOKAkOKAkOKAkCBPcmlnaW5hbCBN ZXNzYWdlIOKAkOKAkOKAkOKAkOKAkOKAkOKAkApPbiBUdWVzZGF5IDQgRmVicnVhcnkgMjAyMCAx NDo0NCwgQW5kcmV3IENhbXBsaW5nIDxhbmRyZXcuY2FtcGxpbmdANDE5LmNvbnN1bHRpbmc+IHdy b3RlOgoKPiBPbiBUdWUsIEZlYiA0LCAyMDIwIGF0IDExOjMzIEFNIEppbSBSZWlkIDxqaW1AcmZj MTAzNS5jb20+IHdyb3RlOgo+Cj4+IElNTyAiZGV2ZWxvcCBhbiBpbmZvcm1hdGlvbmFsIGRvY3Vt ZW50IHRoYXQgZGVzY3JpYmVzIGhvdyBjbGllbnQgYXBwbGljYXRpb25zIGFuZCBzeXN0ZW1zIGNh biBtYW5hZ2Ugc2VsZWN0aW9uCj4+IG9mIEROUyByZXNvbHZlcnMgaW4gdmFyaW91cyBuZXR3b3Jr IGVudmlyb25tZW50cyBhbmQgdXNlIGNhc2Vz4oCdIG1pZ2h0IGJlIHRvbyBhbWJpdGlvdXMgZm9y IGEgc2luZ2xlIGRvY3VtZW50LiBJdAo+PiBtaWdodCBiZSBiZXR0ZXIgdG8gc2F5IOKAnGRldmVs b3AgYSBzZXQgb2YgaW5mb3JtYXRpb25hbCBkb2N1bWVudHMuLuKAnSBpbiBjYXNlIGl0IHR1cm5z IG91dCB0aGF0IHByZWNpc2VseSB0YXJnZXRlZAo+PiBkb2N1bWVudHMgZm9yIHNwZWNpZmljIHVz ZSBjYXNlcyAtLSBzcGxpdCBETlMsIGVudGVycHJpc2UgbmV0d29ya3MsIGNvZmZlZSBzaG9wIGNh cHRpdmUgcG9ydGFscywgaG9tZSBuZXRzIGx1cmtpbmcKPj4gYmVoaW5kIE5BVCwgZXRjIC0tIGFy ZSBtb3JlIGRpZ2VzdGlibGUgdGhhbiBvbmUgZG9jdW1lbnQgd2hpY2ggdHJpZXMgdG8gY292ZXIg YWxsIHBvc3NpYmxlIHNjZW5hcmlvcy4KPgo+IEknbSBpbiBmYXZvdXIgb2YgdGhlIGNoYXJ0ZXIg cHJvcG9zZWQgYnkgVG9tbXkgUGF1bHksIHdpdGggdGhlIGFtZW5kbWVudCBvZiB0aGUgdGhpcmQg ZGVsaXZlcmFibGUgaW50byBhIHNldCBvZiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50cyByYXRoZXIg dGhhbiBhIHNpbmdsZSBpdGVtLCBhcyBzdWdnZXN0ZWQgYWJvdmUsIGFuZCBhbSB3aWxsaW5nIHRv IHdvcmsgb24gdGhlIHN1Z2dlc3RlZCBkZWxpdmVyYWJsZXMuICBUaGVyZSBpcyBjbGVhcmx5IHdv cmsgdG8gYmUgZG9uZSBoZXJlOyBJJ20gY29uZmlkZW50IHRoYXQgbGVhZGVyc2hpcCBieSB0aGUg Y28tY2hhaXJzIGFuZCBBRCB3aWxsIGhlbHAgYWRkcmVzcyB0aGUgcG90ZW50aWFsIGlzc3VlcyB0 aGF0IHNvbWUgaGF2ZSBmbGFnZ2VkIG9uIHRoZSBsaXN0IHdpdGhvdXQgdGhlIG5lZWQgdG8gZW5n YWdlIGluIG9wZW4tZW5kZWQgd29yZHNtaXRoaW5nIG9mIHRoZSBjaGFydGVyLgo+Cj4gQW5kcmV3 --b1_d5f065b5908d9900791c605b440112b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5JIGFtIGluIGZhdm9yIG9mIHRoaXMgY2hhcnRlciB0b28gYW5kIHdpbGwgZG8gbXkgYmVz dCB0byBzdXBwb3J0IGFuZCByZXZpZXc8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGNsYXNzPSJw cm90b25tYWlsX3NpZ25hdHVyZV9ibG9jayI+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1 cmVfYmxvY2stdXNlciBwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1lbXB0eSI+PGJyPjwvZGl2 PjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXByb3RvbiI+U2VudCB3aXRo IDxhIGhyZWY9Imh0dHBzOi8vcHJvdG9ubWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5Qcm90b25N YWlsPC9hPiBTZWN1cmUgRW1haWwuPGJyPjwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ 4oCQ4oCQ4oCQ4oCQ4oCQ4oCQ4oCQIE9yaWdpbmFsIE1lc3NhZ2Ug4oCQ4oCQ4oCQ4oCQ4oCQ4oCQ 4oCQPGJyPjwvZGl2PjxkaXY+IE9uIFR1ZXNkYXkgNCBGZWJydWFyeSAyMDIwIDE0OjQ0LCBBbmRy ZXcgQ2FtcGxpbmcgJmx0O2FuZHJldy5jYW1wbGluZ0A0MTkuY29uc3VsdGluZyZndDsgd3JvdGU6 PGJyPjwvZGl2PjxkaXY+IDxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0icHJvdG9ubWFpbF9x dW90ZSIgdHlwZT0iY2l0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTZweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij48ZGl2 Pk9uIFR1ZSwgRmViIDQsIDIwMjAgYXQgMTE6MzMgQU0gSmltIFJlaWQgJmx0O2ppbUByZmMxMDM1 LmNvbSZndDsgd3JvdGU6PGJyPjwvZGl2PjxkaXY+Jm5ic3A7PGJyPjwvZGl2PjxkaXY+Jmd0OyBJ TU8gImRldmVsb3AgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyBob3cg Y2xpZW50IGFwcGxpY2F0aW9ucyBhbmQgc3lzdGVtcyBjYW4gbWFuYWdlIHNlbGVjdGlvbjxicj48 L2Rpdj48ZGl2PiZndDsgb2YgRE5TIHJlc29sdmVycyBpbiB2YXJpb3VzIG5ldHdvcmsgZW52aXJv bm1lbnRzIGFuZCB1c2UgY2FzZXPigJ0gbWlnaHQgYmUgdG9vIGFtYml0aW91cyBmb3IgYSBzaW5n bGUgZG9jdW1lbnQuIEl0PGJyPjwvZGl2PjxkaXY+Jmd0OyBtaWdodCBiZSBiZXR0ZXIgdG8gc2F5 IOKAnGRldmVsb3AgYSBzZXQgb2YgaW5mb3JtYXRpb25hbCBkb2N1bWVudHMuLuKAnSBpbiBjYXNl IGl0IHR1cm5zIG91dCB0aGF0IHByZWNpc2VseSB0YXJnZXRlZDxicj48L2Rpdj48ZGl2PiZndDsg ZG9jdW1lbnRzIGZvciBzcGVjaWZpYyB1c2UgY2FzZXMgLS0gc3BsaXQgRE5TLCBlbnRlcnByaXNl IG5ldHdvcmtzLCBjb2ZmZWUgc2hvcCBjYXB0aXZlIHBvcnRhbHMsIGhvbWUgbmV0cyBsdXJraW5n PGJyPjwvZGl2PjxkaXY+Jmd0OyBiZWhpbmQgTkFULCBldGMgLS0gYXJlIG1vcmUgZGlnZXN0aWJs ZSB0aGFuIG9uZSBkb2N1bWVudCB3aGljaCB0cmllcyB0byBjb3ZlciBhbGwgcG9zc2libGUgc2Nl bmFyaW9zLjxicj48L2Rpdj48ZGl2PiZuYnNwOzxicj48L2Rpdj48ZGl2PkknbSBpbiBmYXZvdXIg b2YgdGhlIGNoYXJ0ZXIgcHJvcG9zZWQgYnkgVG9tbXkgUGF1bHksIHdpdGggdGhlIGFtZW5kbWVu dCBvZiB0aGUgdGhpcmQgZGVsaXZlcmFibGUgaW50byBhIHNldCBvZiBpbmZvcm1hdGlvbmFsIGRv Y3VtZW50cyByYXRoZXIgdGhhbiBhIHNpbmdsZSBpdGVtLCBhcyBzdWdnZXN0ZWQgYWJvdmUsIGFu ZCBhbSB3aWxsaW5nIHRvIHdvcmsgb24gdGhlIHN1Z2dlc3RlZCBkZWxpdmVyYWJsZXMuJm5ic3A7 IFRoZXJlIGlzIGNsZWFybHkNCndvcmsgdG8gYmUgZG9uZSBoZXJlOyBJJ20gY29uZmlkZW50IHRo YXQgbGVhZGVyc2hpcCBieSB0aGUgY28tY2hhaXJzIGFuZCBBRCB3aWxsIGhlbHAgYWRkcmVzcyB0 aGUgcG90ZW50aWFsIGlzc3VlcyB0aGF0IHNvbWUgaGF2ZSBmbGFnZ2VkIG9uIHRoZSBsaXN0IHdp dGhvdXQgdGhlIG5lZWQgdG8gZW5nYWdlIGluIG9wZW4tZW5kZWQgd29yZHNtaXRoaW5nIG9mIHRo ZSBjaGFydGVyLjxicj48L2Rpdj48ZGl2PiZuYnNwOzxicj48L2Rpdj48ZGl2PjxiPkFuZHJldzwv Yj48YnI+PC9kaXY+PGRpdj4mbmJzcDs8YnI+PC9kaXY+PGRpdj4mbmJzcDs8YnI+PC9kaXY+PGRp dj4mbmJzcDs8YnI+PC9kaXY+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9ibG9ja3F1b3RlPjxkaXY+ PGJyPjwvZGl2Pg== --b1_d5f065b5908d9900791c605b440112b6-- From nobody Tue Feb 4 06:37:53 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A9E120110 for ; Tue, 4 Feb 2020 06:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlDm3mYxksdg for ; Tue, 4 Feb 2020 06:37:49 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A0A120020 for ; Tue, 4 Feb 2020 06:37:49 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id 77so17279270oty.6 for ; Tue, 04 Feb 2020 06:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6qquuaYtYlB47ff+GiUJp0bcbwpQ+cRFr92UdIPt4o8=; b=Q5yuaoiTWtl1AM3Z2c0XrUFjf2EF/HQn+kJzLsXVUTuuKN+aCL9cTinWDKKRjIEP9U OaQQcz4WqljLs9FQd5YMxHTDrbd9SiDDWkvUzepHX9QOv/Zt+UlUsUH4cshe66pWMpHy hCh0hRk8GwDEWFwbP84eUtbX/+/8Zoy6A2uiGZVDkp0tbVqZzPSkokY1lbtHCXtbnZmv hqq9dwHckzsLLZvg7dGbSFkh8So+V8ZEl4oA17VQE8Kfc6OSnX2Cz23om36cCGYxrifb /IqIb5GSgpjnCPSEakpsoA/miuwiBBMhxTe5bmbGuJPAMs23zzOJYsTr9BhZCxKJRHjz 71LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6qquuaYtYlB47ff+GiUJp0bcbwpQ+cRFr92UdIPt4o8=; b=BHKygxHn0HUiDubbpAlq0FAPIpfhb25RVqpo/P2OQEPiRrIIHxnEeGxeAC5sOkm1P2 FCGKIkaIsVjHCAEN4iRL+c5UJXulz1hDgTi/4OSpWnCvc4YvgPAkuFXIBmHHfS1rZyao tnWnOfrDME7r6NOJbGFTWlJA852o+xghgTB+Qd33kmEcWwpeHjU6xDJ4DfC5K55UtBcD zsILzby33/1KBCv6zyW2nqeD3VpPQIK2xhLdXuu41p+EPTaKAyFj4Ajg9NHGjM77mhnB CPWlDuFTfEKLj/hlII/6ly8EHo7VPb0mRSfd9JGYlyHcfmzZirD1T5lsu+NrGRZeoCFW /KVw== X-Gm-Message-State: APjAAAWX+mLCh2kSyG1RFFTkPxoVu7pWHHpQfc7/7VkZKxIJdu4neyE1 uN79/D1In2E40FfcthFAQL8nMvEumkf7n+CYu4bJdw== X-Google-Smtp-Source: APXvYqx9oyQrzlS+6RIHx/07G4kVYvMlsnjg2x6HcGxdti7grfLEHVO/ui3ZmhxlgNJZ58QAdJywC3s8Kmrct+bRlog= X-Received: by 2002:a05:6830:11c8:: with SMTP id v8mr11811087otq.330.1580827068352; Tue, 04 Feb 2020 06:37:48 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> In-Reply-To: From: Kenji Baheux Date: Tue, 4 Feb 2020 08:37:36 -0600 Message-ID: To: Paul Hoffman Cc: Eric Rescorla , ADD Mailing list , The IESG , "add-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dca9a1059dc0fb83" Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 14:37:52 -0000 --000000000000dca9a1059dc0fb83 Content-Type: text/plain; charset="UTF-8" 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 wrote: > On Feb 4, 2020, at 12:45 PM, Eric Rescorla 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-- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000dca9a1059dc0fb83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After reading a few exchanges, I can't help but = wonder why there is a need to preclude specific items of interest to a sign= ificant number of participants, on what appears to be unsubstantiated doubt= s about the wg's ability to be productive, or to produce deliverables t= hat will meet various stakeholders' requirements, or of the wg's ch= airs inability to guide the group, etc.

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

If certain wg items result i= n 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 beli= ef and just have them implement/follow everything that would come out of th= is wg.

So, to the extent= that there are many folks and parties interested in these specific problem= s, 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 v= iewpoints and expertise. That would at least increases the chance that the = deliverables are acceptable by a wider set of stakeholders, or that the gro= up sees dead-ends earlier, etc.



On Tue, Feb 4, 2020, 07:50 Paul Hoffman <paul.hoffman@icann.org> wrote:
On Feb 4, 2020, at 12:45 PM, Eric Rescor= la <ekr@rtfm.com> 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 w= ork instead of ignoring likely future work. (Of course, there have also bee= n well-documented failures.) My preference would be to make it clear that t= here is a venue for the informational document, but not until the technical= work is done first.

--Paul Hoffman--
Add mailing list
Add@ie= tf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000dca9a1059dc0fb83-- From nobody Tue Feb 4 06:44:21 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1631200CD for ; Tue, 4 Feb 2020 06:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cww-jk9uEvR for ; Tue, 4 Feb 2020 06:44:14 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21ABD120105 for ; Tue, 4 Feb 2020 06:44:14 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id a13so18848804ljm.10 for ; Tue, 04 Feb 2020 06:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XbQ+m2hwm8biNrlUwmityvDqZiR9mN8ru5j7/R/m2j0=; b=i4lFayZYXmfr3Bxj866suWDnEyW5C1i6G7eopIFoIWen7JmMOZO8pVkA+obphux3bh XG5DgrTFXIcchUEViQboGp6fWVOwYo4UNkXt9uv4ow1NL4k8gIUQ4KCJqOzXrMINUxaF DD4R9skjO2DAXg0W8Hkk8akmddl+Ha/rHEzsWLcnsgEmyNHGbqveXnBT+sOpB61ox9Di yY/4LcNim4JbqRvXdUqPWk8jEEC8RXtSqCa2Jmj5ZcsTuNU2XNJBQYv0gKcGxO2bXRMK aBNENvwxbAb7If2MLip6mMUr372gk9BULlOswD21JQFjreqgmgUKMAK5CLI2pSkyTuun iHPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XbQ+m2hwm8biNrlUwmityvDqZiR9mN8ru5j7/R/m2j0=; b=gw22VhQcV7nnNd2S7Bmlj9s3T5HSyEjVOXhfF9FQJShw+N+bjcnbwHsPXRMGbRN/x/ K/Qk6N37/I05KQKtHs2KBkGoRcX5TCKj+40PfLDhs47wJOzE+Al8kVZnQgF5oLfhT7OO YlEKMRXoVvBO9mgldq67b+3p0xixODli7Yz7fusjPCtTj4fcOK0oJCeJGHSELL9W77Kc yLHHt+t5+qmLga+ND12AP/DkzYwpEYfMlcxxHPsx+/scwTRV0TOxuXXTi9KB7e1E2PHw ehRbIaUyuINh+dN12eNH44ngqpOHRp/eq88Xh3f4SPYqykbDuAoQO07co1dG1WIkLp6J SktA== X-Gm-Message-State: APjAAAX+CbHzxLB51RdjpT7dasMZ2PrsaAYTiL3s8umYg+8L/rrGEUsn bY/bcuBprj/gbP/R2nUjDK0mlX5weQfW+k1PqqZGRA== X-Google-Smtp-Source: APXvYqyPw6T8ARFHiNfjstF8i+PoPLyXwrBfc3iQTfJQ02QBh+fGfsAaB5yE/Hy0OF1rGn5bJMA9UAPqTEV8EGsdhAo= X-Received: by 2002:a2e:b0c4:: with SMTP id g4mr17864189ljl.83.1580827452132; Tue, 04 Feb 2020 06:44:12 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> In-Reply-To: From: Eric Rescorla Date: Tue, 4 Feb 2020 06:43:35 -0800 Message-ID: To: Kenji Baheux Cc: Paul Hoffman , ADD Mailing list , The IESG , "add-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bc6340059dc11275" Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 14:44:17 -0000 --000000000000bc6340059dc11275 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 6:37 AM Kenji Baheux 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. > 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 > 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 wrote: > >> On Feb 4, 2020, at 12:45 PM, Eric Rescorla 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-- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > --000000000000bc6340059dc11275 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 6:37 AM Kenji = Baheux <kenjibaheux@google.com= > 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 sign= ificant number of participants, on what appears to be unsubstantiated doubt= s about the wg's ability to be productive, or to produce deliverables t= hat will meet various stakeholders' requirements, or of the wg's ch= airs inability to guide the group, etc.

I'm not sure why you think those doubts are unsubstantiated. W= e 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 question= s.

-Ekr


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

If certain wg items re= sult 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 thei= r 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 p= roblems, the discussions will inevitably happen. It seems preferable to hav= e them happen in the context of the IETF so that the output benefits from o= ther viewpoints and expertise. That would at least increases the chance tha= t the deliverables are acceptable by a wider set of stakeholders, or that t= he group sees dead-ends earlier, etc.



On Tue, Feb 4, 2020, 07:50 Paul Hoffman <paul.hoffman@icann.or= g> wrote:
On Feb 4, 2020, at 12:45 PM, Eric Rescorla <ekr@rtfm.com> 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 w= ork instead of ignoring likely future work. (Of course, there have also bee= n well-documented failures.) My preference would be to make it clear that t= here is a venue for the informational document, but not until the technical= work is done first.

--Paul Hoffman--
Add mailing list
Add@ie= tf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000bc6340059dc11275-- From nobody Tue Feb 4 06:54:58 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45F6120812 for ; Tue, 4 Feb 2020 06:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck5b9DG08wCg for ; Tue, 4 Feb 2020 06:54:48 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28EAC120845 for ; Tue, 4 Feb 2020 06:54:48 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id z9so11203010wrs.10 for ; Tue, 04 Feb 2020 06:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1VtWn8RLUqZejldFjEzLOxxF1RNUBJETsbNqbwmXH68=; b=TM+6HVXlqGCyChlwtLhc2uNi7t+QWNLlF0AWFXQLRlDoZWVZp+djXeKnQ8WtLYUk5K ZU7e7I+0yZej/HDQTCDbZzfq1Bb91YdK1Ki6wkx0o9UwInXYLxjCETZablty1POdRbn2 f7MO3NHRQDiuBa6iqH5acZUbbeQGOrVgJI3UPcsFnHI4MlFjDotGWJq5snqM0/SuPnLy 0/WYi4orBX4/jauuUc+7dGzPHc8r7wjSnBugS5DKR8ztI23mPxldg2SDZlQXF7njQCWQ sR7lC3NcGWyd1xYpWGmLAv3z6qg/U7Q90kHvT25XRGNlt5zkJgfq8ttiMyQBwXsIjjlw QQKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1VtWn8RLUqZejldFjEzLOxxF1RNUBJETsbNqbwmXH68=; b=k2GTwVserWGTYReYgF5rVyNku5AzoH8avUAVFlluh2RqkaIBYBBQq8hlGMdXYF9fqF 4a3NqzDA98MPEgU/YTy345cwQ3XtzFaiUnsWPWLL2xoDcY7cYuhwGPVMGnAsizcGKuNd +Uwc/tHKEM3XHxq96GAtdPeTOt5jgra79ErzxH2zOQFpgB1pCcviZJXMNFD+0V3XkUSC 9s1B8dmNNIy9pgHVlq3x3PzV2vmMRm05I3+Xoxxf3Z634QwLoVv/W9OvJyzW3rS8UJG+ CPIQq+lm5uQOX1nfTmSN3H2T8boC06IjsHkfnB/sAwE2bVb2x5HU/xMn4iHuF9bteZsE Dwpw== X-Gm-Message-State: APjAAAUpII49RKOys/pY7gb3ERF4Y/8azpn9xyoyKtSHVNDh3NWH1Joz w6JrGYmB0rrIGqa+tsmpp7vu7eT+ytEEIuhmJ8+elQ== X-Google-Smtp-Source: APXvYqwOuTpVRwtZaAYrJ/twkz+HeJVa2zDvDwAWoviINM6lwNUmXGPcTrcFFp3USJTrj9FkH8X0mqnQGu4XZgU7bew= X-Received: by 2002:adf:ee0c:: with SMTP id y12mr22785151wrn.341.1580828086239; Tue, 04 Feb 2020 06:54:46 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> In-Reply-To: From: Kenji Baheux Date: Tue, 4 Feb 2020 08:54:31 -0600 Message-ID: To: Eric Rescorla Cc: Paul Hoffman , ADD Mailing list , The IESG , "add-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000886a79059dc13853" Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 14:54:56 -0000 --000000000000886a79059dc13853 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020, 08:44 Eric Rescorla wrote: > > > On Tue, Feb 4, 2020 at 6:37 AM Kenji Baheux > 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. >> > > 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. > >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. > -Ekr > > >> 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 wrote: >> >>> On Feb 4, 2020, at 12:45 PM, Eric Rescorla 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-- >>> Add mailing list >>> Add@ietf.org >>> https://www.ietf.org/mailman/listinfo/add >>> >> --000000000000886a79059dc13853 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 4, 2020, 08:44 Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Feb 4, 2020= at 6:37 AM Kenji Baheux <kenjibaheux@google.com> wrote:
<= /div>
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 pa= rticipants, on what appears to be unsubstantiated doubts about the wg's= ability to be productive, or to produce deliverables that will meet variou= s stakeholders' requirements, or of the wg's chairs inability to gu= ide the group, etc.

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 reachi= ng any kind of consensus on the general policy questions.

= >From the interactions I've had (out of these lists), I can tell you tha= t 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 d= iscussions to a broader group.


-Ekr


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 spe= cific 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 tha= t everyone feels the same. Beside, I don't think anyone has the power t= o force anyone else to change their belief and just have them implement/fol= low everything that would come out of this wg.

<= /div>
So, to the extent that there are many folks and part= ies 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 wi= der set of stakeholders, or that the group sees dead-ends earlier, etc.



On Tue, Feb 4, 2= 020, 07:50 Paul Hoffman <paul.hoffman@icann.org> wrote:
On Feb 4, 2020, at 12= :45 PM, Eric Rescorla <ekr@rtfm.com> 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 w= ork instead of ignoring likely future work. (Of course, there have also bee= n well-documented failures.) My preference would be to make it clear that t= here is a venue for the informational document, but not until the technical= work is done first.

--Paul Hoffman--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo= /add
--000000000000886a79059dc13853-- From nobody Tue Feb 4 07:00:10 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C143212011B for ; Tue, 4 Feb 2020 07:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g_WxVZW1tGy for ; Tue, 4 Feb 2020 07:00:05 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FFA12011F for ; Tue, 4 Feb 2020 07:00:05 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id t13so14532347qto.3 for ; Tue, 04 Feb 2020 07:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fug8UuB9GCa+tjpsCB5cs0O6zFD+u0TGRFQm7Uzdl1E=; b=KJCRBOhak0Swr20LjXTWIbkCX9RriV3kpuw3wP+ukgT6HRQSANygi3MOi+uzBvswz9 TZ1SVZV9pjpAX8MUO60feT3CsGsBGnSb7pOTEWI8v/osiiQUHJKJ9Q2d7v0eUTx3mn79 dMaVWxkIJ/WmaVNZGTv3963/uYlnebCCqqQKt/OGe6frE6RG86OtGeCJNLwEHa3Ee9PC iu0vYigrHv7IiLwC16SIhKNXK29WeNBDMi2Z3SQi1rEKCqPLEZa7XrWOc/ZoxYyQNKMF IyvxBlb2wmBiqb0Wb35Z9CjORcbK0BxMSvKxqKHDcc9EB3DGXEBsb3yW7BSYCan/xbZx eqsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fug8UuB9GCa+tjpsCB5cs0O6zFD+u0TGRFQm7Uzdl1E=; b=kiNPu/8n1XqT1p9qyHZXcnbHgxJkMFtwXAsLXjzU/XaNRKgGP8TBGYDSgUnwkRoYSQ YFnqlNX/WZxPJAvHeoYEjgddmtqKNWdOz8q8z0x37BftcHAXHx3aR5TWRz7WN3jtiU5n R9Ohqkj0eZHoCNoviQzqyX9r/23ZCxPBHN/tbg8x/ZMsT/KnmBl9+Wld+/W3bxP1s1kb 4OVTXiQJzudFbe4clm+tcRvkVNpe84xwlKMZs00d6Q06XtSFhmoktk2clD4R69uUal70 eFzzHwPcoBpCo11DytFpwhFZxCrgO6yZ4JbHtmjTC72D3NIkjcqY2YGvBlOlD5qK5fQi 18lw== X-Gm-Message-State: APjAAAW34A3UxKkyjGnwzxHBWVOH7ejEDNqpIpOlI1EAgs4N+jqQvyDT kNvNU1Ec7H4vAcyPS9T0+bMbBw== X-Google-Smtp-Source: APXvYqxY9XsyoAG6Fw6LVDqfcGpRpbON6whgIFO4Lz2jXD3lhhYdA4nL6vqppHT9Jf3QKBYP5hTZnw== X-Received: by 2002:ac8:3673:: with SMTP id n48mr29219058qtb.288.1580828404246; Tue, 04 Feb 2020 07:00:04 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:8bd:956:15f6:1652? ([2601:18b:300:36ee:8bd:956:15f6:1652]) by smtp.gmail.com with ESMTPSA id x19sm11911827qtm.47.2020.02.04.07.00.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Feb 2020 07:00:03 -0800 (PST) From: Ted Lemon Message-Id: <4ACF4FA6-A595-4ACE-99AB-2EAA2CE97638@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_76CD1E11-1CF8-486E-9B57-BE9712FE348B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.13.2.1\)) Date: Tue, 4 Feb 2020 10:00:01 -0500 In-Reply-To: Cc: Paul Hoffman , Eric Rescorla , ADD Mailing list , The IESG , "add-chairs@ietf.org" To: Kenji Baheux References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> X-Mailer: Apple Mail (2.3608.80.13.2.1) Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 15:00:09 -0000 --Apple-Mail=_76CD1E11-1CF8-486E-9B57-BE9712FE348B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 4, 2020, at 9:37 AM, Kenji Baheux = 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=E2=80=99s 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=E2=80=99t exist. So it really is important to exclude work items on which it=E2=80=99s = unlikely that consensus can be reached. --Apple-Mail=_76CD1E11-1CF8-486E-9B57-BE9712FE348B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Feb 4, 2020, at 9:37 AM, Kenji Baheux <kenjibaheux=3D40google.com@dmarc.ietf.org> = 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=E2=80=99s 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=E2=80=99= t exist.

So it really is important = to exclude work items on which it=E2=80=99s unlikely that consensus can = be reached.

= --Apple-Mail=_76CD1E11-1CF8-486E-9B57-BE9712FE348B-- From nobody Tue Feb 4 07:02:06 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8E4120105; Tue, 4 Feb 2020 07:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgrcOtdTfq_9; Tue, 4 Feb 2020 07:01:15 -0800 (PST) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F331200CD; Tue, 4 Feb 2020 07:01:15 -0800 (PST) Received: from pps.filterd (m0047964.ppops.net [127.0.0.1]) by m0047964.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 014F14hu010612; Tue, 4 Feb 2020 10:01:14 -0500 Received: from usaoamgip001.mail.tfayd.com ([173.213.212.135]) by m0047964.ppops.net-00176a04. with ESMTP id 2xw5tdjxwx-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT); Tue, 04 Feb 2020 10:01:11 -0500 Received: from unknown (HELO ashemwp00001.mail.tfayd.com) ([10.40.78.204]) by usaoamgip001.mail.tfayd.com with ESMTP; 04 Feb 2020 09:51:28 -0500 Received: from ashemwp00004.mail.tfayd.com (100.126.24.28) by ashemwp00001.mail.tfayd.com (100.126.24.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Tue, 4 Feb 2020 10:01:05 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (10.40.78.204) by ashemwp00004.mail.tfayd.com (100.126.24.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Tue, 4 Feb 2020 10:01:04 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HgHwAmNsWJQmLZAhqs2/aDuL4Ng65e4p7SKu83KdX9fNQKJMXqWtZNTMjSrWtJkklbWxnGHQa5ewHV81Ah7lAFOEAcCOAf74YITS+SaqU0XoY8GwyY3rXe+aDjgZDda0rIxSlJhVSNdz3Ll/XgymItcsKv2d2YMDsU2Ks2AyIfbmoVFfuiqfEc2NETOgAHKbIS0E3MSidG5dTUtPXNgC0AhlM9iPv/z/Nf7lr51cLWdGZAaSjlqcTb3wqO8VUBKVWLx5UHffo2yg3fAhjEi6og3uFFGcgv4GM+Jf4w+HgiUB7mpupoQSSBDS6WoUlZN/GhanaCVpaMmQRga106jqoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sWTzKGv8EWm7X8KnEdafumwDuSHnxSr9jN2w54CF/pc=; b=bAUci0bMB7V+zUtC+ByCrhmt5LvffQZ/FGgWhNwQxQbcEZ5+WUjxtJzZQgzkYDFHfs0xWzGSxAETa74Shujw0S4wEg89QYxs7MLUcLh48ohPn2muOEG2Y0ktBUalZT97MXIyYn/0eK48v2LCJiSq7MmPMKLPT9kCqJoahBu0ohE6ytWAFddsFyBhRukWG0IIPbu+lXIyxnZ15h2Tk5rPw7lpAf94PtSDapqWuGOW3J0OGHIQ+0U6kq6uQQaDYFB7Bou8dv5M+eClelwaWuiPohhiIMkdi/Qw5JEOtD1V/e0IdXhahRqw5+J/24t+1g1v+kUnwKMT58pJ2bw9hOb0nQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sWTzKGv8EWm7X8KnEdafumwDuSHnxSr9jN2w54CF/pc=; b=R16XKlDF5a7uwYc70jijymz+844S5Bl6DJwXXh49flBE4S7w5929Owss3CLUgSbS5Vz+y1v5pBSDCmhxXlli5f8xMICEckrm1OpiSa6RSn4iXaMVIKTNE85NLesTAfQK5SX3pZTRqGLpdSbdZUa8KyWJQDThTruyQich0w/afLA= Received: from DM6PR14MB3993.namprd14.prod.outlook.com (10.141.186.71) by DM6PR14MB4042.namprd14.prod.outlook.com (10.141.186.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Tue, 4 Feb 2020 15:01:04 +0000 Received: from DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592]) by DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592%5]) with mapi id 15.20.2707.020; Tue, 4 Feb 2020 15:01:03 +0000 From: "Deen, Glenn (NBCUniversal)" To: Eric Rescorla , Paul Hoffman CC: ADD Mailing list , The IESG , "add-chairs@ietf.org" Thread-Topic: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV22vrPcdD40Urck+l7pvZ13+j/A== Date: Tue, 4 Feb 2020 15:01:03 +0000 Message-ID: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-originating-ip: [69.241.73.100] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b85601f0-8606-41d0-a39c-08d7a9830e2b x-ms-traffictypediagnostic: DM6PR14MB4042: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(376002)(346002)(366004)(396003)(136003)(199004)(189003)(6506007)(66556008)(53546011)(64756008)(66446008)(2906002)(66476007)(186003)(36756003)(26005)(316002)(81166006)(8936002)(81156014)(8676002)(76116006)(33656002)(66946007)(6486002)(478600001)(6512007)(86362001)(5660300002)(54906003)(71200400001)(110136005)(2616005)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR14MB4042; H:DM6PR14MB3993.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nbcuni.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Hn9vH4iN4tRhMzIS4+KYrfOrJ1jGzTrc9jGE/KYs6540Ff9x9Jxq1xyzm/mEzpgEQ3jQYFUzREW9P1rKPZHxGRNNEjdVwJzd+XIiuKmFpwtAdG2HIxi9DltxCpWdLNpRODMByU9I0LInkuiHEJdSayaccfuFdIVMWmdfMP4fDJPI0Yb/uj4prnmpgcs3pT/8WSrhaQ8HXXbrCY4k6Z3GVQLmU1qTNqKChUlbVBddr0oD+0v+fuw54eoVW8YxQmO6eTE9uFnl1ObCrQcFWN7Yc0yKRnz8Wg17UOW4y+VXG9aZ2hrR3SkHJGdIEJhd5imnBIEgLGLQLF0h+bZKMqN0N/z+SL/Ft/Mkp14WDmGYA6l3t7TjZm3U3DztDuvIHu18KV50V1Wlyz27+Q9/X3iDDJ1GKJ+oQdel/HttPwF/5jBvCPkWYovL3l9TrvvQ4niW x-ms-exchange-antispam-messagedata: upNDBEHoTPuq/3QOUuEJS8PvDcihGiRDOgjXRY7YIuJRhpNfGay5QwxfweEJn10TloVtlj+lqoHDSJAteoVzIjQITwb7IfgJOAK6C1WhEX9fdKX0LTwjrcidjNscf29W+qhDxT/487lRxrqc6YXV3Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_1A08570C71454501A20CA6701F17F86Cnbcunicom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b85601f0-8606-41d0-a39c-08d7a9830e2b X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 15:01:03.8401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kAjP43yYkmQpx/ninWWKg0BWYphB56+0WVvEGSzkdO7KsY12ZLC3DKpkI6bEhM5xWAVGTb8IadH9uagNWRWGPg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB4042 X-OriginatorOrg: nbcuni.com X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-04_04:2020-02-04, 2020-02-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 mlxscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 mlxlogscore=999 suspectscore=0 clxscore=1011 impostorscore=0 priorityscore=1501 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2002040105 Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 15:01:18 -0000 --_000_1A08570C71454501A20CA6701F17F86Cnbcunicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIDIvNC8yMCwgNDo0NiBBTSwgIkFkZCBvbiBiZWhhbGYgb2YgRXJpYyBSZXNjb3JsYSIg PGFkZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphZGQtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVo YWxmIG9mIGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQoNCk9uIFR1 ZSwgRmViIDQsIDIwMjAgYXQgNDozNyBBTSBQYXVsIEhvZmZtYW4gPHBhdWwuaG9mZm1hbkBpY2Fu bi5vcmc8bWFpbHRvOnBhdWwuaG9mZm1hbkBpY2Fubi5vcmc+PiB3cm90ZToNCg0KPj4gLSBkZXZl bG9wIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgaG93IGNsaWVudA0K Pj4gIGFwcGxpY2F0aW9ucyBhbmQgc3lzdGVtcyBjYW4gbWFuYWdlIHNlbGVjdGlvbiBvZiBETlMg cmVzb2x2ZXJzDQo+PiAgaW4gdmFyaW91cyBuZXR3b3JrIGVudmlyb25tZW50cyBhbmQgdXNlIGNh c2VzLg0KPg0KPiBIZXJlIEkgYWdyZWUgd2l0aCBib3RoIEVLUiBhbmQgw4lyaWMgdGhhdCB0aGUg ZGVzY3JpYmVkIHdvcmsgaXMgb3Blbi1lbmRlZA0KPiBlbm91Z2ggdG8gcmVzdWx0IGluIHVucHJv ZHVjdGl2ZSBhbmQgbGlrZWx5IHRveGljIGludGVyYWN0aW9ucy4gSXQgd291bGQNCj4gYmUgbXkg c3Ryb25nIHJlY29tbWVuZGF0aW9uIHRvIHN0cmlrZSBpdCBmcm9tIHRoZSBjaGFydGVyIGF0IHRo aXMgdGltZSwNCj4gd2l0aCBhbiBpbnRlbnRpb24gb2YgcmUtdmlzaXRpbmcgaXQgaWYgdGhlIHdv cmtpbmcgZ3JvdXAgaXMgYWJsZSB0bw0KPiBwcm9kdWN0aXZlbHkgbWFrZSBoZWFkd2F5IG9uIHRo ZSBsZXNzLWNvbnRlbnRpb3VzIGlzc3VlcyBjYWxsZWQgZm9yIGJ5DQo+IHRoZSBvdGhlciBkZWxp dmVyYWJsZXMuIEl0IG1heSB3ZWxsIGJlIHRoYXQgdGhpcyBjb21tdW5pdHkgZmluZHMgYQ0KPiBw b3NpdGl2ZSB3YXkgb2YgaW50ZXJhY3RpbmcgYnkgc29sdmluZyB0aGUgY29uY3JldGUgZGlzY292 ZXJ5DQo+IG1lY2hhbmlzbXMgZGVzY3JpYmVkIGFib3ZlLCBhbmQgY2FuIHRoZW4gbGV2ZXJhZ2Ug dGhlIHJlbGF0aW9uc2hpcHMNCj4gYW5kIHRydXN0IHRoZXkgYnVpbGQgZHVyaW5nIHRoYXQgZXhl cmNpc2UgdG8gc3VjY2VlZCB3aGVyZSBjb252ZXJzYXRpb25zDQo+IGhhdmUgc28gZmFyIGJlZW4g ZnJ1aXRsZXNzLiBCdXQgSSBmZWFyIHRoYXQgcHV0dGluZyB0aGlzIG9uIHRoZSBwbGF0ZQ0KPiBh cyBwYXJ0IG9mIHRoZSBmaXJzdCB0cmFuY2hlIG9mIHdvcmsgaXMgbGlrZWx5IHRvIGxlYWQgdG8g dGhlIHNhbWUNCj4gYWNyaW1vbnkgdGhhdCBoYXMgZG9nZ2VkIHRoaXMgZW5kZWF2b3IgaW4gdGhl IHBhc3QuDQoNCkhvd2V2ZXIsIHRha2luZyBpdCBmdWxseSBvZmYgdGhlIHBsYXRlIHdpbGwgbGVh ZCB0byB0aGUgc2FtZSBkaXNjdXNzaW9ucyBoYXBwZW5pbmcgcmVwZWF0ZWRseSBkdWUgdG8gY3Vy cmVudCBkZXBsb3ltZW50IHN0cmF0ZWdpZXMgb2YgbWFqb3IgdmVuZG9ycy4NCg0KV2VsbCwgcGVy aGFwcywgYnV0IHdlIGRvbid0IG5lZWQgYW4gSUVURiBXRyBmb3IgdGhvc2UgZGlzY3Vzc2lvbnMg YW5kIHRoZSBldmlkZW5jZSBpcyB0aGF0IHRoYXQncyBub3QgYSBwcm9kdWN0aXZlIHZlbnVlIGZv ciB0aGVtLg0KDQpXaGlsZSB0aGUgQUREIGxpc3QgYW5kIEJvRnMgaGF2ZSBjZXJ0YWlubHkgbm90 IGJlZW4gcHJvZHVjdGl2ZSB2ZW51ZXMgZm9yIGRpc2N1c3Npb25zIHRoYXTigJlzIGxhcmdlbHkg YXR0cmlidXRhYmxlIHRvIGEgdmFyaWV0eSBvZiBmYWN0b3JzIHdoaWNoIGxpa2VseSB3b27igJl0 IGJlIHByZXNlbnQgaW4gYWN0dWFsIFdHLiAgIFRoZSBBREQgbGlzdCBhbmQgQm9GcyBoYXZlIGJl ZW4gdmVyeSBicm9hZCBhbmQgd2lkZSBvcGVuLCBhbmQgbGFja2VkIHRoZSBmb2N1cyBvZiBhIGNo YXJ0ZXIsIHdoaWNoIHJlc3VsdGVkIGluIHVucHJvZHVjdGl2ZSBkaXNjdXNzaW9ucyB0aGF0IGRp ZG7igJl0IHByb2dyZXNzLiAgVGhlIFdHIGNvbnZlcnNlbHkgd2lsbCBoYXZlIGEgc3BlY2lmaWMg Y2hhcnRlciB0byBmb2N1cyBpdCBhbmQgY2hhaXJzIHRvIGhlbHAgbWFuYWdlIHRoZSBhY3Rpdml0 eS4gICAgIFRoYXQgd2lsbCBsZXQgdGhlIElFVEYgcHJvY2VzcyBvZiBkcmFmdHMsIGRpc2N1c3Np b25zLCByZXZpc2lvbnMsIGFuZCBtb3JlIGRpc2N1c3Npb25zIHRvIG1vdmUgdGhpbmdzIGZvcndh cmQgcHJvZHVjdGl2ZWx5Lg0KDQpUaGUgZ2VuZXJhbCB0b3BpYyBoYXMgYWxzbyBldm9sdmVkIGNv bnNpZGVyYWJseSBzaW5jZSAyMDE5IHdoaWNoIHNob3VsZCBoZWxwLiAgTm93IHRoYXQgdGhlcmUg YXJlIGRlcGxveW1lbnQgZWZmb3J0cyBnb2luZyBvbiwgdGhlcmUgaXMgYSBncm93aW5nIGFtb3Vu dCBvZiBleHBlcmllbmNlIGJlaW5nIGdhaW5lZCB0aGF0IGlzIGhlbHBpbmcgcGVvcGxlIHVuZGVy c3RhbmQgd2hhdOKAmXMgYWN0dWFsbHkgbmVlZGVkIGFzIG9wcG9zZWQgdG8gb3BlbiBzcGVjdWxh dGlvbiwgYXNzZXJ0aW9uIGFuZCBvcGluaW9uLiAgVGhhdCBzaG91bGQgaGVscCBtb3ZlIHRoaW5n cyBmcm9tIHVucHJvZHVjdGl2ZSBvcGVuIGVuZGVkIGFic3RyYWN0IGRpc2N1c3Npb24gdG93YXJk IHByb2R1Y3RpdmUgZm9jdXNlZCBhY3Rpdml0eS4NCg0KLUdsZW5uDQoNCg0K --_000_1A08570C71454501A20CA6701F17F86Cnbcunicom_ Content-Type: text/html; charset="utf-8" Content-ID: <99B2ADD1F9A30740BB60528478870866@namprd14.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6 YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkhlbHZldGljYTsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Okhl bHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+T24gMi80LzIwLCA0OjQ2IEFNLCAmcXVvdDtBZGQgb24gYmVoYWxmIG9m IEVyaWMgUmVzY29ybGEmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphZGQtYm91bmNlc0BpZXRm Lm9yZyI+YWRkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFp bHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFj ayI+T24gVHVlLCBGZWIgNCwgMjAyMCBhdCA0OjM3IEFNIFBhdWwgSG9mZm1hbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBhdWwuaG9mZm1hbkBpY2Fubi5vcmciPnBhdWwuaG9mZm1hbkBpY2Fubi5vcmc8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbjtj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFu czogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow cHgiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2Nv bG9yOmJsYWNrIj48YnI+DQomZ3Q7Jmd0OyAtIGRldmVsb3AgYW4gaW5mb3JtYXRpb25hbCBkb2N1 bWVudCB0aGF0IGRlc2NyaWJlcyBob3cgY2xpZW50PGJyPg0KJmd0OyZndDsmbmJzcDsgYXBwbGlj YXRpb25zIGFuZCBzeXN0ZW1zIGNhbiBtYW5hZ2Ugc2VsZWN0aW9uIG9mIEROUyByZXNvbHZlcnM8 YnI+DQomZ3Q7Jmd0OyZuYnNwOyBpbiB2YXJpb3VzIG5ldHdvcmsgZW52aXJvbm1lbnRzIGFuZCB1 c2UgY2FzZXMuPGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YnI+DQomZ3Q7IEhlcmUgSSBhZ3JlZSB3aXRoIGJvdGggRUtSIGFuZCDDiXJp YyB0aGF0IHRoZSBkZXNjcmliZWQgd29yayBpcyBvcGVuLWVuZGVkPGJyPg0KJmd0OyBlbm91Z2gg dG8gcmVzdWx0IGluIHVucHJvZHVjdGl2ZSBhbmQgbGlrZWx5IHRveGljIGludGVyYWN0aW9ucy4g SXQgd291bGQ8YnI+DQomZ3Q7IGJlIG15IHN0cm9uZyByZWNvbW1lbmRhdGlvbiB0byBzdHJpa2Ug aXQgZnJvbSB0aGUgY2hhcnRlciBhdCB0aGlzIHRpbWUsPGJyPg0KJmd0OyB3aXRoIGFuIGludGVu dGlvbiBvZiByZS12aXNpdGluZyBpdCBpZiB0aGUgd29ya2luZyBncm91cCBpcyBhYmxlIHRvPGJy Pg0KJmd0OyBwcm9kdWN0aXZlbHkgbWFrZSBoZWFkd2F5IG9uIHRoZSBsZXNzLWNvbnRlbnRpb3Vz IGlzc3VlcyBjYWxsZWQgZm9yIGJ5PGJyPg0KJmd0OyB0aGUgb3RoZXIgZGVsaXZlcmFibGVzLiBJ dCBtYXkgd2VsbCBiZSB0aGF0IHRoaXMgY29tbXVuaXR5IGZpbmRzIGE8YnI+DQomZ3Q7IHBvc2l0 aXZlIHdheSBvZiBpbnRlcmFjdGluZyBieSBzb2x2aW5nIHRoZSBjb25jcmV0ZSBkaXNjb3Zlcnk8 YnI+DQomZ3Q7IG1lY2hhbmlzbXMgZGVzY3JpYmVkIGFib3ZlLCBhbmQgY2FuIHRoZW4gbGV2ZXJh Z2UgdGhlIHJlbGF0aW9uc2hpcHM8YnI+DQomZ3Q7IGFuZCB0cnVzdCB0aGV5IGJ1aWxkIGR1cmlu ZyB0aGF0IGV4ZXJjaXNlIHRvIHN1Y2NlZWQgd2hlcmUgY29udmVyc2F0aW9uczxicj4NCiZndDsg aGF2ZSBzbyBmYXIgYmVlbiBmcnVpdGxlc3MuIEJ1dCBJIGZlYXIgdGhhdCBwdXR0aW5nIHRoaXMg b24gdGhlIHBsYXRlPGJyPg0KJmd0OyBhcyBwYXJ0IG9mIHRoZSBmaXJzdCB0cmFuY2hlIG9mIHdv cmsgaXMgbGlrZWx5IHRvIGxlYWQgdG8gdGhlIHNhbWU8YnI+DQomZ3Q7IGFjcmltb255IHRoYXQg aGFzIGRvZ2dlZCB0aGlzIGVuZGVhdm9yIGluIHRoZSBwYXN0Ljxicj4NCjxicj4NCkhvd2V2ZXIs IHRha2luZyBpdCBmdWxseSBvZmYgdGhlIHBsYXRlIHdpbGwgbGVhZCB0byB0aGUgc2FtZSBkaXNj dXNzaW9ucyBoYXBwZW5pbmcgcmVwZWF0ZWRseSBkdWUgdG8gY3VycmVudCBkZXBsb3ltZW50IHN0 cmF0ZWdpZXMgb2YgbWFqb3IgdmVuZG9ycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LHNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7 Y29sb3I6YmxhY2siPldlbGwsIHBlcmhhcHMsIGJ1dCB3ZSBkb24ndCBuZWVkIGFuIElFVEYgV0cg Zm9yIHRob3NlIGRpc2N1c3Npb25zIGFuZCB0aGUgZXZpZGVuY2UgaXMgdGhhdCB0aGF0J3Mgbm90 IGEgcHJvZHVjdGl2ZSB2ZW51ZSBmb3IgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCldoaWxlIHRoZSBBREQgbGlzdCBhbmQgQm9G cyBoYXZlIGNlcnRhaW5seSBub3QgYmVlbiBwcm9kdWN0aXZlIHZlbnVlcyBmb3IgZGlzY3Vzc2lv bnMgdGhhdOKAmXMgbGFyZ2VseSBhdHRyaWJ1dGFibGUgdG8gYSB2YXJpZXR5IG9mIGZhY3RvcnMg d2hpY2ggbGlrZWx5IHdvbuKAmXQgYmUgcHJlc2VudCBpbiBhY3R1YWwgV0cuICZuYnNwOyZuYnNw O1RoZSBBREQgbGlzdCBhbmQgQm9GcyBoYXZlIGJlZW4gdmVyeSBicm9hZCBhbmQgd2lkZSBvcGVu LCBhbmQgbGFja2VkIHRoZQ0KIGZvY3VzIG9mIGEgY2hhcnRlciwgd2hpY2ggcmVzdWx0ZWQgaW4g dW5wcm9kdWN0aXZlIGRpc2N1c3Npb25zIHRoYXQgZGlkbuKAmXQgcHJvZ3Jlc3MuICZuYnNwO1Ro ZSBXRyBjb252ZXJzZWx5IHdpbGwgaGF2ZSBhIHNwZWNpZmljIGNoYXJ0ZXIgdG8gZm9jdXMgaXQg YW5kIGNoYWlycyB0byBoZWxwIG1hbmFnZSB0aGUgYWN0aXZpdHkuJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFRoYXQgd2lsbCBsZXQgdGhlIElFVEYgcHJvY2VzcyBvZiBkcmFmdHMsIGRpc2N1c3Np b25zLCByZXZpc2lvbnMsIGFuZA0KIG1vcmUgZGlzY3Vzc2lvbnMgdG8gbW92ZSB0aGluZ3MgZm9y d2FyZCBwcm9kdWN0aXZlbHkuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZ2VuZXJhbCB0 b3BpYyBoYXMgYWxzbyBldm9sdmVkIGNvbnNpZGVyYWJseSBzaW5jZSAyMDE5IHdoaWNoIHNob3Vs ZCBoZWxwLiZuYnNwOyBOb3cgdGhhdCB0aGVyZSBhcmUgZGVwbG95bWVudCBlZmZvcnRzIGdvaW5n IG9uLCB0aGVyZSBpcyBhIGdyb3dpbmcgYW1vdW50IG9mIGV4cGVyaWVuY2UgYmVpbmcgZ2FpbmVk IHRoYXQgaXMgaGVscGluZyBwZW9wbGUgdW5kZXJzdGFuZCB3aGF04oCZcyBhY3R1YWxseSBuZWVk ZWQNCiBhcyBvcHBvc2VkIHRvIG9wZW4gc3BlY3VsYXRpb24sIGFzc2VydGlvbiBhbmQgb3Bpbmlv bi4mbmJzcDsgVGhhdCBzaG91bGQgaGVscCBtb3ZlIHRoaW5ncyBmcm9tIHVucHJvZHVjdGl2ZSBv cGVuIGVuZGVkIGFic3RyYWN0IGRpc2N1c3Npb24gdG93YXJkIHByb2R1Y3RpdmUgZm9jdXNlZCBh Y3Rpdml0eS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tR2xlbm48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_1A08570C71454501A20CA6701F17F86Cnbcunicom_-- From nobody Tue Feb 4 07:24:19 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2716F12012E; Tue, 4 Feb 2020 07:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX0a5BqO_DpI; Tue, 4 Feb 2020 07:24:16 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100069.outbound.protection.outlook.com [40.107.10.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596D0120020; Tue, 4 Feb 2020 07:24:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rn0ajMAysjyN4CT1AYc2elaMYocOsWE8Rb9Tgp4dKyhtuqXiOQ9XFezQKs4M6a4PU7hR5y7WAiOazuRq+meJxR80VNIdj08v0L3teSFYOX7a6PTQMqhHhWwAZAhvDB51If3IUzKxkoijhXr/AgA2CRM4j/96tmECCstwub2A4cclG0YnV53Vokn+ztagz6pa60rDj4Z4pVrD1hNzDsR4WQ5/rYZNAt/QiL1M8kq8ic/WZB+zdDZBzEeuxMlzFK/jRWCntU82RZJzzILdGlpjAM9dLpbixEgzkG3DQEmFRg9ivZHEIQzT/HXy1mS9z7IuO+GoyB5cw3SWA7UqP+jgXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pds0dcXejwDQIIgy90Lrkgg4cMIJPU78TFiiBXdMELI=; b=cLYZhG7jc/eZMdSxzG6Q28CBhVm7p2Eqio6r0SwSGP+ST86dE01N3atwsZWUDbEttPgCYOWNE/i6VulVk73oPTfcan+BVGMWBTt7q9HE4U2WExQqyj0h8JOSG6jVHHqKi1tFqMuQI3qqweYXLZoYdM6AtyaLkBHPiZnSapGDqrtJ2WRVMXLyy2TTyRCSs53m1ovR/95fjEQAi64ggOvyMqkoOJfYuwShb/ggcrjxSYMvl7e09q7MEyRCxRTSyjsIW4CoYp84CWo+WIkyFqlE0yJfrodA3jDGKcdx5PoW1EQ8UlX0l4Rn2ABDgsVVCkHAi2ZUSTKX9cu8QkJ01Fomig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pds0dcXejwDQIIgy90Lrkgg4cMIJPU78TFiiBXdMELI=; b=UmZVupQ0J++5s2L3CxzY2DoVuZZZ50LdvG5EVlGl62UuGKA2+DAObmoPdToABWxAGf4aU1GbXXLVbhcUZLzPG4L08bnoqzYAUWB2wARcUwjU/NoiU52iOIexkr6DfJWm+DLg24g7kwY+07Bc3Bkc6C3C5kaLmW8gadi7/Uvuoes= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1149.GBRP265.PROD.OUTLOOK.COM (20.176.144.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Tue, 4 Feb 2020 15:24:13 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af%5]) with mapi id 15.20.2686.034; Tue, 4 Feb 2020 15:24:13 +0000 From: Andrew Campling To: Kenji Baheux , Paul Hoffman CC: Eric Rescorla , ADD Mailing list , The IESG , "add-chairs@ietf.org" Thread-Topic: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV22mZsPzsl1p1bE+Vg9cOrIFmYKgLJyiw Date: Tue, 4 Feb 2020 15:24:13 +0000 Message-ID: References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [109.152.16.200] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 216fb122-3e6a-484d-7647-08d7a9864a47 x-ms-traffictypediagnostic: LO2P265MB1149: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39830400003)(396003)(136003)(376002)(366004)(189003)(199004)(508600001)(2906002)(26005)(966005)(186003)(7696005)(54906003)(110136005)(316002)(71200400001)(81166006)(44832011)(6506007)(53546011)(81156014)(8676002)(52536014)(86362001)(5660300002)(4326008)(66476007)(76116006)(66446008)(55016002)(64756008)(66556008)(66946007)(9686003)(33656002)(8936002)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1149; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VHgN8mDzWReb631B6KtAzP/P4cvK1rNmDptMQDV6DhB4cr/11qSbc4jpMEGZ/5CbBXtNTPSfNYEe6hRyBjxlUQ84YU5Bi+l6NulfRgWdtNfc7ehPZg46yuPQwHvVelRN77JmsdGvkFveN/Q4GYh6PZvFaV7KO90uLAH/e3nYVTxlKff89mjZdhoBApJPnh1IZMHlFsm76FfbJcAzEaWa72FgnxakLu+Fqcv4PuaXTMWEXHnaHoIw9H7RKS9TspyVaswswCee42JXn0EVA1Qv93aKiezwoCKo6tHu8ajlGNRgIwjCAC+eRL403IcDg7JcaGngLOZwHZGPrqwf0Pk0POdip2+3aWLw0JsHwEMzNR1d9U2pf5Ayv3Hnj5BzscdvBi/4KA+HPZEwR641XhlipPlTKyrK9iA8GlkRZGCC/i4YanRoV8YYQVevb8qUvNmG2VqsqG+KUNtjSnw+mC/3Xy1Qkz/2oU/a1zbgarhpRo2Rd4Ord+LpZsKYNF414VdaIcqhBaPW/vI6NxAZUzsRQT5CtSz4NYxlQrlWSKS1Yd6s3wjSpzj7QDFJQXa+0Leu x-ms-exchange-antispam-messagedata: BK12z8gHmMoYnxKGvB+u+DLdqnCN89bW2P4lanI1gyY32JvpGHuDYTO9FX0kyoPRB+T6QkSSko0roc/O/xgScQXJpuhs/pW9APQ0mY+nt1tiG8uA+yEz3mpPPqn6ZgMthIY5MQX3MJl0ckkANxMKXQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573C97ABA50EEB3C375F154C2030LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 216fb122-3e6a-484d-7647-08d7a9864a47 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 15:24:13.2543 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ReWzBoPfJ2sEEwoD8Sf2ma57NqAO9L7RDGfROSQ40Yuug+1nLekQlJwJ/1guji6RKAKEyIDS+DnsuWLpN29iX6Y9suBojVqDwER8iKlm4Lo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1149 Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 15:24:18 -0000 --_000_LO2P265MB0573C97ABA50EEB3C375F154C2030LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gS2VuamkgYW5kIFBhdWzigJlzIHBvaW50cyBiZWxvdy4NCg0KQW5kcmV3DQoNCkZyb206 IEtlbmppIEJhaGV1eCA8a2VuamliYWhldXhAZ29vZ2xlLmNvbT4NClNlbnQ6IDA0IEZlYnJ1YXJ5 IDIwMjAgMTQ6MzgNClRvOiBQYXVsIEhvZmZtYW4gPHBhdWwuaG9mZm1hbkBpY2Fubi5vcmc+DQpD YzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPjsgQUREIE1haWxpbmcgbGlzdCA8YWRkQGll dGYub3JnPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBhZGQtY2hhaXJzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW0FkZF0gW0V4dF0gQWRhbSBSb2FjaCdzIE5vIE9iamVjdGlvbiBvbiBjaGFy dGVyLWlldGYtYWRkLTAwLTAwOiAod2l0aCBDT01NRU5UKQ0KDQpBZnRlciByZWFkaW5nIGEgZmV3 IGV4Y2hhbmdlcywgSSBjYW4ndCBoZWxwIGJ1dCB3b25kZXIgd2h5IHRoZXJlIGlzIGEgbmVlZCB0 byBwcmVjbHVkZSBzcGVjaWZpYyBpdGVtcyBvZiBpbnRlcmVzdCB0byBhIHNpZ25pZmljYW50IG51 bWJlciBvZiBwYXJ0aWNpcGFudHMsIG9uIHdoYXQgYXBwZWFycyB0byBiZSB1bnN1YnN0YW50aWF0 ZWQgZG91YnRzIGFib3V0IHRoZSB3ZydzIGFiaWxpdHkgdG8gYmUgcHJvZHVjdGl2ZSwgb3IgdG8g cHJvZHVjZSBkZWxpdmVyYWJsZXMgdGhhdCB3aWxsIG1lZXQgdmFyaW91cyBzdGFrZWhvbGRlcnMn IHJlcXVpcmVtZW50cywgb3Igb2YgdGhlIHdnJ3MgY2hhaXJzIGluYWJpbGl0eSB0byBndWlkZSB0 aGUgZ3JvdXAsIGV0Yy4NCg0KSWYgY2VydGFpbiB3ZyBpdGVtcyBlbmQgdXAgbm90IG1ha2luZyBw cm9ncmVzcyB0aGVuIHNvIGJlIGl0LiBDaGFpcnMgYW5kIGdyb3VwIG1lbWJlcnMgc2hvdWxkIG5v dGljZSBhbmQgbWFrZSBhIGNhbGwgb3IgYSBjaGFuZ2UuDQoNCklmIGNlcnRhaW4gd2cgaXRlbXMg cmVzdWx0IGluIHVuYWNjZXB0YWJsZSBkZWxpdmVyYWJsZXMgZm9yIHNwZWNpZmljIHN0YWtlaG9s ZGVycyB0aGVuIHNvIGJlIGl0LiBPciwgaWYgY2VydGFpbiB3ZyBpdGVtcyBhcmUgbm9uLXN0YXJ0 ZXJzIGZvciBzb21lIHN0YWtlaG9sZGVycywgdGhlbiBzbyBiZSBpdC4gSXQncyBub3QgbmVjZXNz YXJpbHkgdGhlIGNhc2UgdGhhdCBldmVyeW9uZSBmZWVscyB0aGUgc2FtZS4gQmVzaWRlLCBJIGRv bid0IHRoaW5rIGFueW9uZSBoYXMgdGhlIHBvd2VyIHRvIGZvcmNlIGFueW9uZSBlbHNlIHRvIGNo YW5nZSB0aGVpciBiZWxpZWYgYW5kIGp1c3QgaGF2ZSB0aGVtIGltcGxlbWVudC9mb2xsb3cgZXZl cnl0aGluZyB0aGF0IHdvdWxkIGNvbWUgb3V0IG9mIHRoaXMgd2cuDQoNClNvLCB0byB0aGUgZXh0 ZW50IHRoYXQgdGhlcmUgYXJlIG1hbnkgZm9sa3MgYW5kIHBhcnRpZXMgaW50ZXJlc3RlZCBpbiB0 aGVzZSBzcGVjaWZpYyBwcm9ibGVtcywgdGhlIGRpc2N1c3Npb25zIHdpbGwgaW5ldml0YWJseSBo YXBwZW4uIEl0IHNlZW1zIHByZWZlcmFibGUgdG8gaGF2ZSB0aGVtIGhhcHBlbiBpbiB0aGUgY29u dGV4dCBvZiB0aGUgSUVURiBzbyB0aGF0IHRoZSBvdXRwdXQgYmVuZWZpdHMgZnJvbSBvdGhlciB2 aWV3cG9pbnRzIGFuZCBleHBlcnRpc2UuIFRoYXQgd291bGQgYXQgbGVhc3QgaW5jcmVhc2VzIHRo ZSBjaGFuY2UgdGhhdCB0aGUgZGVsaXZlcmFibGVzIGFyZSBhY2NlcHRhYmxlIGJ5IGEgd2lkZXIg c2V0IG9mIHN0YWtlaG9sZGVycywgb3IgdGhhdCB0aGUgZ3JvdXAgc2VlcyBkZWFkLWVuZHMgZWFy bGllciwgZXRjLg0KDQoNCk9uIFR1ZSwgRmViIDQsIDIwMjAsIDA3OjUwIFBhdWwgSG9mZm1hbiA8 cGF1bC5ob2ZmbWFuQGljYW5uLm9yZzxtYWlsdG86cGF1bC5ob2ZmbWFuQGljYW5uLm9yZz4+IHdy b3RlOg0KT24gRmViIDQsIDIwMjAsIGF0IDEyOjQ1IFBNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRm bS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KPiBXZWxsLCBwZXJoYXBzLCBidXQg d2UgZG9uJ3QgbmVlZCBhbiBJRVRGIFdHIGZvciB0aG9zZSBkaXNjdXNzaW9ucyBhbmQgdGhlIGV2 aWRlbmNlIGlzIHRoYXQgdGhhdCdzIG5vdCBhIHByb2R1Y3RpdmUgdmVudWUgZm9yIHRoZW0uDQoN CldlIGRpc2FncmVlIHRoYXQgc3VjaCBldmlkZW5jZSBleGlzdHMuIE1hbnkgcGVvcGxlIGhhdmUg YmVlbiB3YWl0aW5nIGZvciBhIHdvcmtpbmcgZ3JvdXAgc28gdGhhdCBhIGRvY3VtZW50IGNhbiBi ZSBjcmVhdGVkIGluIHRoZSBJRVRGIHByb2Nlc3MuDQoNCj4gV2h5IG5vdCBzaW1wbHkgcmVjaGFy dGVyIGF0IHRoYXQgcG9pbnQ/DQoNClRoZXJlIGhhcyBiZWVuIHN1Y2Nlc3MgaW4gdGhlIHBhc3Qg d2l0aCB3b3JraW5nIGdyb3VwcyB0aGF0IG9yZGVyZWQgdGhlaXIgd29yayBpbnN0ZWFkIG9mIGln bm9yaW5nIGxpa2VseSBmdXR1cmUgd29yay4gKE9mIGNvdXJzZSwgdGhlcmUgaGF2ZSBhbHNvIGJl ZW4gd2VsbC1kb2N1bWVudGVkIGZhaWx1cmVzLikgTXkgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBt YWtlIGl0IGNsZWFyIHRoYXQgdGhlcmUgaXMgYSB2ZW51ZSBmb3IgdGhlIGluZm9ybWF0aW9uYWwg ZG9jdW1lbnQsIGJ1dCBub3QgdW50aWwgdGhlIHRlY2huaWNhbCB3b3JrIGlzIGRvbmUgZmlyc3Qu DQoNCi0tUGF1bCBIb2ZmbWFuLS0NCkFkZCBtYWlsaW5nIGxpc3QNCkFkZEBpZXRmLm9yZzxtYWls dG86QWRkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h ZGQNCg== --_000_LO2P265MB0573C97ABA50EEB3C375F154C2030LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+JiM0MzsxIHRvIEtlbmpp IGFuZCBQYXVs4oCZcyBwb2ludHMgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+QW5kcmV3DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiBLZW5qaSBCYWhldXggJmx0O2tlbmppYmFoZXV4QGdvb2dsZS5jb20m Z3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMDQgRmVicnVhcnkgMjAyMCAxNDozODxicj4NCjxiPlRv OjwvYj4gUGF1bCBIb2ZmbWFuICZsdDtwYXVsLmhvZmZtYW5AaWNhbm4ub3JnJmd0Ozxicj4NCjxi PkNjOjwvYj4gRXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0OzsgQUREIE1haWxpbmcg bGlzdCAmbHQ7YWRkQGlldGYub3JnJmd0OzsgVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7 OyBhZGQtY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQWRkXSBbRXh0 XSBBZGFtIFJvYWNoJ3MgTm8gT2JqZWN0aW9uIG9uIGNoYXJ0ZXItaWV0Zi1hZGQtMDAtMDA6ICh3 aXRoIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFmdGVyIHJlYWRpbmcgYSBmZXcgZXhjaGFuZ2VzLCBJIGNhbid0IGhlbHAgYnV0IHdvbmRlciB3 aHkgdGhlcmUgaXMgYSBuZWVkIHRvIHByZWNsdWRlIHNwZWNpZmljIGl0ZW1zIG9mIGludGVyZXN0 IHRvIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIHBhcnRpY2lwYW50cywgb24gd2hhdCBhcHBlYXJz IHRvIGJlIHVuc3Vic3RhbnRpYXRlZCBkb3VidHMgYWJvdXQgdGhlIHdnJ3MgYWJpbGl0eSB0byBi ZSBwcm9kdWN0aXZlLA0KIG9yIHRvIHByb2R1Y2UgZGVsaXZlcmFibGVzIHRoYXQgd2lsbCBtZWV0 IHZhcmlvdXMgc3Rha2Vob2xkZXJzJyByZXF1aXJlbWVudHMsIG9yIG9mIHRoZSB3ZydzIGNoYWly cyBpbmFiaWxpdHkgdG8gZ3VpZGUgdGhlIGdyb3VwLCBldGMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGNlcnRhaW4gd2cgaXRlbXMgZW5k IHVwIG5vdCBtYWtpbmcgcHJvZ3Jlc3MgdGhlbiBzbyBiZSBpdC4gQ2hhaXJzIGFuZCBncm91cCBt ZW1iZXJzIHNob3VsZCBub3RpY2UgYW5kIG1ha2UgYSBjYWxsIG9yIGEgY2hhbmdlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBjZXJ0YWlu IHdnIGl0ZW1zIHJlc3VsdCBpbiB1bmFjY2VwdGFibGUgZGVsaXZlcmFibGVzIGZvciBzcGVjaWZp YyBzdGFrZWhvbGRlcnMgdGhlbiBzbyBiZSBpdC4gT3IsIGlmIGNlcnRhaW4gd2cgaXRlbXMgYXJl IG5vbi1zdGFydGVycyBmb3Igc29tZSBzdGFrZWhvbGRlcnMsIHRoZW4gc28gYmUgaXQuIEl0J3Mg bm90IG5lY2Vzc2FyaWx5IHRoZSBjYXNlIHRoYXQgZXZlcnlvbmUgZmVlbHMgdGhlIHNhbWUuDQog QmVzaWRlLCBJIGRvbid0IHRoaW5rIGFueW9uZSBoYXMgdGhlIHBvd2VyIHRvIGZvcmNlIGFueW9u ZSBlbHNlIHRvIGNoYW5nZSB0aGVpciBiZWxpZWYgYW5kIGp1c3QgaGF2ZSB0aGVtIGltcGxlbWVu dC9mb2xsb3cgZXZlcnl0aGluZyB0aGF0IHdvdWxkIGNvbWUgb3V0IG9mIHRoaXMgd2cuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCB0byB0 aGUgZXh0ZW50IHRoYXQgdGhlcmUgYXJlIG1hbnkgZm9sa3MgYW5kIHBhcnRpZXMgaW50ZXJlc3Rl ZCBpbiB0aGVzZSBzcGVjaWZpYyBwcm9ibGVtcywgdGhlIGRpc2N1c3Npb25zIHdpbGwgaW5ldml0 YWJseSBoYXBwZW4uIEl0IHNlZW1zIHByZWZlcmFibGUgdG8gaGF2ZSB0aGVtIGhhcHBlbiBpbiB0 aGUgY29udGV4dCBvZiB0aGUgSUVURiBzbyB0aGF0IHRoZSBvdXRwdXQgYmVuZWZpdHMgZnJvbSBv dGhlcg0KIHZpZXdwb2ludHMgYW5kIGV4cGVydGlzZS4gVGhhdCB3b3VsZCBhdCBsZWFzdCBpbmNy ZWFzZXMgdGhlIGNoYW5jZSB0aGF0IHRoZSBkZWxpdmVyYWJsZXMgYXJlIGFjY2VwdGFibGUgYnkg YSB3aWRlciBzZXQgb2Ygc3Rha2Vob2xkZXJzLCBvciB0aGF0IHRoZSBncm91cCBzZWVzIGRlYWQt ZW5kcyBlYXJsaWVyLCBldGMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmVi IDQsIDIwMjAsIDA3OjUwIFBhdWwgSG9mZm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhdWwuaG9m Zm1hbkBpY2Fubi5vcmciPnBhdWwuaG9mZm1hbkBpY2Fubi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEZlYiA0LCAyMDIwLCBhdCAxMjo0NSBQTSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdy b3RlOjxicj4NCiZndDsgV2VsbCwgcGVyaGFwcywgYnV0IHdlIGRvbid0IG5lZWQgYW4gSUVURiBX RyBmb3IgdGhvc2UgZGlzY3Vzc2lvbnMgYW5kIHRoZSBldmlkZW5jZSBpcyB0aGF0IHRoYXQncyBu b3QgYSBwcm9kdWN0aXZlIHZlbnVlIGZvciB0aGVtLjxicj4NCjxicj4NCldlIGRpc2FncmVlIHRo YXQgc3VjaCBldmlkZW5jZSBleGlzdHMuIE1hbnkgcGVvcGxlIGhhdmUgYmVlbiB3YWl0aW5nIGZv ciBhIHdvcmtpbmcgZ3JvdXAgc28gdGhhdCBhIGRvY3VtZW50IGNhbiBiZSBjcmVhdGVkIGluIHRo ZSBJRVRGIHByb2Nlc3MuPGJyPg0KPGJyPg0KJmd0OyBXaHkgbm90IHNpbXBseSByZWNoYXJ0ZXIg YXQgdGhhdCBwb2ludD88YnI+DQo8YnI+DQpUaGVyZSBoYXMgYmVlbiBzdWNjZXNzIGluIHRoZSBw YXN0IHdpdGggd29ya2luZyBncm91cHMgdGhhdCBvcmRlcmVkIHRoZWlyIHdvcmsgaW5zdGVhZCBv ZiBpZ25vcmluZyBsaWtlbHkgZnV0dXJlIHdvcmsuIChPZiBjb3Vyc2UsIHRoZXJlIGhhdmUgYWxz byBiZWVuIHdlbGwtZG9jdW1lbnRlZCBmYWlsdXJlcy4pIE15IHByZWZlcmVuY2Ugd291bGQgYmUg dG8gbWFrZSBpdCBjbGVhciB0aGF0IHRoZXJlIGlzIGEgdmVudWUgZm9yIHRoZSBpbmZvcm1hdGlv bmFsDQogZG9jdW1lbnQsIGJ1dCBub3QgdW50aWwgdGhlIHRlY2huaWNhbCB3b3JrIGlzIGRvbmUg Zmlyc3QuPGJyPg0KPGJyPg0KLS1QYXVsIEhvZmZtYW4tLSA8YnI+DQpBZGQgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFkZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkFkZEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FkZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYWRkPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_LO2P265MB0573C97ABA50EEB3C375F154C2030LO2P265MB0573GBRP_-- From nobody Tue Feb 4 07:30:00 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED9C12011F; Tue, 4 Feb 2020 07:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYCexzOIpThy; Tue, 4 Feb 2020 07:29:52 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650122.outbound.protection.outlook.com [40.107.65.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E73F1200B2; Tue, 4 Feb 2020 07:29:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S733E4QVhKnRPwvIJ/tHL5Qy4HlP6E8K7LLTyTCkceRyDuMt924SYkbD3WBkwGUsEB6Us7Ejk53NZBvRppwFJLc3+bgu2pq0n4DYAfjLLxzQLFQs2lBB7mj8C1MI0t6qqppH8jLmXopFUZJ9qUOsGPYjjxBuOYo/qE/FHJK8mDoqw7baiYblZDpITzMCqgy2K0mOdMHg1H24f9CLduQyINSQwewdgpqjwcPvwN3KGCZgLt+mdnW8Hfw38MHjDoYiWDmwx4Ya7FeS7oXVOodrotl+V67yizG40+pXbRLtRW3z2tLKUgihm9QwaybUUhrXG5D+UgETkit+Gm067xVI4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bpXTxwLu1m8XOYAp6nAeV5AFiUbTi+2bOfGIbMC65HA=; b=CgIoplthsc9PeHf/pT58c3nNgnhPJTV/1HrcnXrxJpwqVovgs+UhNNTicYJv/ItIA0zYISfWE3Y4sVEn2mU0GGDtut48gJOP5jYWAZPwr/kO0cBudHAa4GoZkHQnqE3zAhYWDAXwOqExf8KoozfVygxc1H4n4JqESYS5kPtXN86Ft85SgKXOCxNzP6Al5nOkHrrjjBPV/ID+MRFAOlrXWJWx4fxBER9gWKkUCt7sMjXpkNv/xyjs7W0T3I8RdEp85+eDLEFfXETEx6xYwveR1U7Mb0o+e8Ue/o5de41550f56dzQ5mQwFJ6Z7b0/yCqQbslCpm/cGmSl2fLZUQbXZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bpXTxwLu1m8XOYAp6nAeV5AFiUbTi+2bOfGIbMC65HA=; b=ctO2hga+P1OH0Ly5vZiSXKUjSD7jyj2Owq7hJNFacljZSXn3dN6pkgen8fZbsr0bRQFNJqNXu0stv/TS0RIBgg/IjTOscVnZbXhrH/0XMqXoUJ3xmTIy4yzDWLleGXdcqy3KH7U1IlLdhlaJHSRvn/XeQk0auTQMSMIxH416b7k= Received: from BL0PR00MB0772.namprd00.prod.outlook.com (52.135.46.88) by BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2745.0; Tue, 4 Feb 2020 15:29:27 +0000 Received: from BL0PR00MB0772.namprd00.prod.outlook.com ([fe80::a4ff:bc21:157a:4072]) by BL0PR00MB0772.namprd00.prod.outlook.com ([fe80::a4ff:bc21:157a:4072%6]) with mapi id 15.20.2744.000; Tue, 4 Feb 2020 15:29:27 +0000 From: Tommy Jensen To: Adam Roach via Datatracker , The IESG , Adam Roach CC: "add@ietf.org" , "add-chairs@ietf.org" Thread-Topic: [EXTERNAL] [Add] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV2yJcMhrA+TTkDUiVmCtk1sS69qgLI0jL Date: Tue, 4 Feb 2020 15:29:27 +0000 Message-ID: References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> In-Reply-To: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jensen.Thomas@microsoft.com; x-originating-ip: [2601:600:a080:aff0:10ef:1394:740b:92e] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1323d2fa-f1f3-4b65-a8be-08d7a9870590 x-ms-traffictypediagnostic: BL0PR00MB0292: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(376002)(346002)(366004)(39860400002)(189003)(199004)(2906002)(66574012)(8990500004)(478600001)(10290500003)(316002)(52536014)(9686003)(55016002)(110136005)(54906003)(4326008)(33656002)(7696005)(5660300002)(66446008)(64756008)(66556008)(86362001)(71200400001)(66476007)(66946007)(76116006)(91956017)(8676002)(81166006)(8936002)(81156014)(186003)(6506007)(966005)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0292; H:BL0PR00MB0772.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n5ex9vKFOog4KLovHJNyBlti2D47SnIScouTqy6roIVG2brV210kTsWRG0914/JMoqPiDn/evE8D/9V2in6SZX0xfGC9fryp/2rmzEbjrlwGSnVDim2z7Yy14ynig2ya3gjTKjOjEVh+WeqHOwe/C5sI/QRcC/3e6W06Qa5KM2QRVliW688e1jP8xqnwxgPTbrsmh3jSOXuVO9bfQyg5VBid1NAu2l4I1rjCciw+pKov4BdiW6A70DjPShLYaSUpLDg4aLggraVx8Ktpvt87wpAWR0n9QyVnQrxJyNuUu5+XK9QYCrHVZU4aaMWc5TlUsuy67NI4U/bUuhq7svUpfjlQZ3F5ExuxzMctlp0+5IuqxxdJuXSBnliYtwgSv5pdYqkrJJ6ZMFhIK8OOJsl4dEnNbj7TlyBfda7K1sbTbdOxG2AKr0kFcpGCQ2VZBINAXk6PpiKwTp5TIThFAwp06usRlOaYXsaFKwuP13eeK6ZN78p7nbIY7tlNYflhG6aC35LO8qWsz3i057Z0jwF21A== x-ms-exchange-antispam-messagedata: AQA3eP4i5a0h1J3zUu7NKjdEPP1sBQ2kVGuY/4Wwe7Si3PyizJtrW15k2JzX9JPCn9watRnFoNrI3d9vNrrGLlmyseccresrubbBVxg8pXtuaX69BCKdprBCMfBwGgt0rPoWXrI59kxhoDACc4DyrgdnRayl8bVlNLImKjkwmSafGv/Sqwk4YAzacLTB5A6vwuidUlui5vLXfU8+/QYqxw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0772287D4F19CED040820D4FFA030BL0PR00MB0772namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1323d2fa-f1f3-4b65-a8be-08d7a9870590 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 15:29:27.3696 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eGgNZK5r7K2ORmnchonwvgc6WDUwlOc0Rh/USGRUD9uAAasEU8i/v5udWXjkKepJ/UmzbE5rj1l/0EqL5JXIzw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0292 Archived-At: Subject: Re: [Add] [EXTERNAL] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 15:29:56 -0000 --_000_BL0PR00MB0772287D4F19CED040820D4FFA030BL0PR00MB0772namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Like many on this list, I disagree that the third bullet from the charter s= hould be struck, and I support Tommy Pauly=92s 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, c= onversations 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 q= uality of the solutions we can build for bullets one and two if we ignore t= his difficult topic altogether. I look forward to bringing the productivity from offlist collaborations int= o a formal WG where that collaboration can have a greater ecosystem impact. Thanks, Tommy (the other one) ________________________________ From: Add on behalf of Adam Roach via Datatracker Sent: Monday, February 3, 2020 10:14 PM To: The IESG Cc: add@ietf.org ; add-chairs@ietf.org Subject: [EXTERNAL] [Add] Adam Roach's No Objection on charter-ietf-add-00-= 00: (with COMMENT) 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://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fcharter-ietf-add%2F&data=3D02%7C01%7CJensen.Thoma= s%40microsoft.com%7Cc6ad75f691664d08b32008d7a9397d82%7C72f988bf86f141af91ab= 2d7cd011db47%7C1%7C0%7C637163936698675465&sdata=3DZW1Gl9LEEfD5MGqLxY649= %2FrqzKCILBpPyVt3MTPntUs%3D&reserved=3D0 ---------------------------------------------------------------------- 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 a= t its current form, but still think that the working group would be well serv= ed 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 n= ot 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 =C9ric 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. -- Add mailing list Add@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fadd&data=3D02%7C01%7CJensen.Thomas%40micro= soft.com%7Cc6ad75f691664d08b32008d7a9397d82%7C72f988bf86f141af91ab2d7cd011d= b47%7C1%7C0%7C637163936698685422&sdata=3DOXlAX9Sz0NPLSqBaa2JcFKXmTVxGBS= 5VvdeGNvaKVtQ%3D&reserved=3D0 --_000_BL0PR00MB0772287D4F19CED040820D4FFA030BL0PR00MB0772namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Like many on this list, I disagree that the third bullet from the char= ter should be struck, and I support Tommy Pauly=92s charter as written.

Adam> It may well be that this community finds a
positive way of interacting b= y solving the concrete discovery
mechanisms described above, a= nd can then leverage the relationships
and trust they build during t= hat 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 declarin= g 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 quali= ty of the solutions we can build for bullets one and two if we ignore this = difficult topic altogether.

I look forward to bri= nging the productivity from offlist collaborations into a formal WG where t= hat collaboration can have a greater ecosystem impact. 

Thanks,
Tommy (the other one)=

From: Add <add-bounces@i= etf.org> on behalf of Adam Roach via Datatracker <noreply@ietf.org>= ;
Sent: Monday, February 3, 2020 10:14 PM
To: The IESG <iesg@ietf.org>
Cc: add@ietf.org <add@ietf.org>; add-chairs@ietf.org <add-c= hairs@ietf.org>
Subject: [EXTERNAL] [Add] Adam Roach's No Objection on charter-ietf-= add-00-00: (with COMMENT)
 
Adam Roach has entered the following ballot positi= on 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:= //nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fcharter-ietf-add%2F&amp;data=3D02%7C01%7CJensen.Thomas%= 40microsoft.com%7Cc6ad75f691664d08b32008d7a9397d82%7C72f988bf86f141af91ab2d= 7cd011db47%7C1%7C0%7C637163936698675465&amp;sdata=3DZW1Gl9LEEfD5MGqLxY6= 49%2FrqzKCILBpPyVt3MTPntUs%3D&amp;reserved=3D0



----------------------------------------------------------------------
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 th= at
have plagued conversations to date.

I can appreciate that the charter has undergone many iterations to arrive a= t
its current form, but still think that the working group would be well serv= ed
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<= br> 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 resol= vers
>   in various network environments and use cases.

Here I agree with both EKR and =C9ric 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.


--
Add mailing list
Add@ietf.org
https://nam06.saf= elinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2= Flistinfo%2Fadd&amp;data=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Cc6= ad75f691664d08b32008d7a9397d82%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7= C637163936698685422&amp;sdata=3DOXlAX9Sz0NPLSqBaa2JcFKXmTVxGBS5VvdeGNva= KVtQ%3D&amp;reserved=3D0
--_000_BL0PR00MB0772287D4F19CED040820D4FFA030BL0PR00MB0772namp_-- From nobody Tue Feb 4 07:31:02 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8DA120142 for ; Tue, 4 Feb 2020 07:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-0RVixP4IRu for ; Tue, 4 Feb 2020 07:30:57 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF18D120841 for ; Tue, 4 Feb 2020 07:30:57 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id i6so17451447otr.7 for ; Tue, 04 Feb 2020 07:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SVAoF7OU1vEM60ksW5abmzHe+VYIGZerI1LySGs4RhA=; b=aqaK0ndtvFgWEkragxDBgrDrLJkXGpAYVdkCgKtJsfTec/pSBAvjkbcZztbJ8RApk9 anFOo4NSk9MxPBqJ2qp6DgJrPAZRVo8chFIEdQ5e5FscTs4s5yp5h9XpHwFt9JbpWZcs 0u4XumCMrCKqVuctsIALShAC2IhxKs+jQexb2gd1KIhUe3Ur++EwaoB9rp8HZDrAIdR2 dGd+UM7zVOKTnusOK15pfHWdjwpziRmvHzcGSP1kDtW1uHn9ArVSrWssEso79LxJQ9vr dvb9saMzZNxRmGhm3DY5Fr2yXsf2buiFaz0xWNpNcUX/JQENAA/tyolyJra3cfaf7G90 l39g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SVAoF7OU1vEM60ksW5abmzHe+VYIGZerI1LySGs4RhA=; b=kR+99CE5GIvBLxx7mlBahb42mT8PhfUZoxcR7Up3LchAYTOgqJKjRQr23ITUZTu5Wg gAXeq2D0tHAhJlY28HyHUGQV2yR04jsjkb1nO0VBVRfMl2dXSOQhnLaIGaCBOTolKEIs YoKox7ieJhKFp1wQd8b+yUIKiXtox9nWoLry2isxfKCGxv6P2bgVHn7d/q4dub1R3f9Z b1NluPzbhUq3QXSvEk1Egw2cLuwCH9Kn6BoY3bSpqt/N8RVBp2wOBMYm+nynn/UjI0zQ e5PZBpn7mnUL+CccFSbRVZeZm9hr4r0uQ2bgL3EYCHRvCF11dOoRsuGtuAjDp5edSCIM Uc6Q== X-Gm-Message-State: APjAAAV/8ZM/paZ8Q7bxEQZFuiYQZuSxGCEt+mu8Vs/Lt2ZRzUIsixw4 yPyRvhMuqpKYUFiYQxbLzZXg+HHq0qdl9CPI038aNQ== X-Google-Smtp-Source: APXvYqwU9mFSJ+hcyjXmCUf0i6yIv7OIMRcGEUuK0FKwgP+wVMD81P3eIKOs5eAAf0Na6pnOujFC80qgSzMo0NMsRKo= X-Received: by 2002:a05:6830:11c8:: with SMTP id v8mr11968290otq.330.1580830256802; Tue, 04 Feb 2020 07:30:56 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> <4ACF4FA6-A595-4ACE-99AB-2EAA2CE97638@fugue.com> In-Reply-To: <4ACF4FA6-A595-4ACE-99AB-2EAA2CE97638@fugue.com> From: Kenji Baheux Date: Tue, 4 Feb 2020 09:30:44 -0600 Message-ID: To: Ted Lemon Cc: Paul Hoffman , Eric Rescorla , ADD Mailing list , The IESG , "add-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e889fa059dc1b96a" Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 15:31:00 -0000 --000000000000e889fa059dc1b96a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020, 09:00 Ted Lemon wrote: > On Feb 4, 2020, at 9:37 AM, Kenji Baheux < > kenjibaheux=3D40google.com@dmarc.ietf.org> wrote: > > After reading a few exchanges, I can't help but wonder why there is a nee= d > 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 vario= us > 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=E2=80=99s 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=E2=80=99t 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. > So it really is important to exclude work items on which it=E2=80=99s unl= ikely > that consensus can be reached. > > --000000000000e889fa059dc1b96a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 4, 2020, 09:00 Ted Lemon <mellon@fugue.co= m> wrote:
On Feb 4, 2020, at 9:37 AM, = Kenji Baheux <kenjibaheux=3D40google.c= om@dmarc.ietf.org> wrote:
After reading a few exchanges, I can't help but wonder wh= y there is a need to preclude specific items of interest to a significant n= umber of participants, on what appears to be unsubstantiated doubts about t= he wg's ability to be productive, or to produce deliverables that will = meet various stakeholders' requirements, or of the wg's chairs inab= ility to guide the group, etc.

The r= eason for this is that when a working group is given a work item on which i= t=E2=80=99s clear consensus cannot be reached, that working group becomes a= tax on the time of all the people who have to continually participate in o= rder to prevent consensus

It feels like we are keeping hostage the w= hole 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 &qu= ot;consensus"? Or if this is a question of requirements, can't the= se requirements be documented and justified once?


being reache= d 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 sai= d items are framed in terms of a specific (bad) idea and not a problem.

The latter can be fixed rig= ht now. The former could just be folks assuming a certain direction they di= sagree with or they could be right but evidence rather than belief seems pr= eferable. I don't think this should block the charter though. Couldn= 9;t the wg decide to drop the item as it is presented said evidence?
<= div dir=3D"auto">

=C2=A0If the work item = is not in the charter, then this (sometimes massive) time tax doesn=E2=80= =99t exist.

The work item will find a different home as long as ther= e 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 (unvo= iced) downsides.


So it really is important= to exclude work items on which it=E2=80=99s unlikely that consensus can be= reached.

<= div dir=3D"auto">
=

<= /div>
--000000000000e889fa059dc1b96a-- From nobody Tue Feb 4 07:33:14 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2F41200D7; Tue, 4 Feb 2020 07:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77zHRTOrKuFF; Tue, 4 Feb 2020 07:33:11 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650098.outbound.protection.outlook.com [40.107.65.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D11A1200B9; Tue, 4 Feb 2020 07:33:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PZMuZtZvD+LJla2cGhFEtnFeP+yXbwYUnBSO//OG3LFZQh1H0xN72yV/svf4204gqVt+E5eXmKR+a7M9Hv9K8NX7MMDC6TNap4uqxDMLsj66Jr7TilMC3U+0IJfdHTTDsY1DEoiCG/68mjsNlUryws4No6DzuYMp1ksR12jDX/FY1FP765rQ8kXjDH6W6pZUEVXBBanvuc3PX0/VFakPcVN5gi3eHjUNBbpEE8JMqWlH4mM6yuJD38qaGQ6CslB3oDoJLLg/8rqjsGrjKwZ8g0ziou9gC0L6swDzMARz6aODv2tIGxG8p97mj3DCc1MS7M2E+iOdpvfi8D8AjO41CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VcIGCV5DyVTM2I+jgWjTQbt4A26oQQecdBvLJWyQ+uQ=; b=VH7dPQzqjogRlJDh7NWwUyim//5vyHcOZ/0CCgvGEHGO6wClXGDV2Nme3bEdxTYxPRc45mSGVboDLnTABSRGG7kZjOjZ4nWHXBzvCxWAq2lRrpWRiePGmSIaxAQp3hoDd/nUSpddL/1M2izW1FjMUu7+hgauETSyRGNHqIVJtDLrMCzDytrczMQoHw3dty5dV6aOMmuO0BDRAHolEFByjL5jMleSYvaSjfQHJeUB+IqKF2pAVviDhXtpL64gAH+eUdhfkvDZZtkHaDjKuTZk32nvQHX8n1+KkVhtzxt4LKKDwz1srxOgpgjUYBVRzlEDd466Wgxa2HDwCp0mM6lzlQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VcIGCV5DyVTM2I+jgWjTQbt4A26oQQecdBvLJWyQ+uQ=; b=RVo4yo91uVGpc3Y33sHDZykYJXs64CDKO1AMWmjPloHfDBT0LuOAoDJ+S1k0hKOucYGoRNJAIyjFewmCpmsbWKyntg+NVt7ryLCOCdGAyugNFY9CgYipqKEcEl1wzO2hXxgHPFZ+E3aZqOXNetHcnH/CvIhsx2ao82lZfaGQqzI= Received: from BL0PR00MB0772.namprd00.prod.outlook.com (52.135.46.88) by BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2745.0; Tue, 4 Feb 2020 15:33:09 +0000 Received: from BL0PR00MB0772.namprd00.prod.outlook.com ([fe80::a4ff:bc21:157a:4072]) by BL0PR00MB0772.namprd00.prod.outlook.com ([fe80::a4ff:bc21:157a:4072%6]) with mapi id 15.20.2744.000; Tue, 4 Feb 2020 15:33:09 +0000 From: Tommy Jensen To: Andrew Campling , Kenji Baheux , Paul Hoffman CC: Eric Rescorla , ADD Mailing list , The IESG , "add-chairs@ietf.org" Thread-Topic: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV228y7CWsaCvEUE2E5AeRRW3VgqgLKSEz Date: Tue, 4 Feb 2020 15:33:09 +0000 Message-ID: References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jensen.Thomas@microsoft.com; x-originating-ip: [2601:600:a080:aff0:10ef:1394:740b:92e] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 65bf237b-9999-4424-b31b-08d7a9878a07 x-ms-traffictypediagnostic: BL0PR00MB0292: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(376002)(346002)(366004)(39860400002)(189003)(199004)(2906002)(8990500004)(478600001)(10290500003)(316002)(52536014)(9686003)(55016002)(110136005)(54906003)(4326008)(33656002)(7696005)(5660300002)(66446008)(64756008)(66556008)(86362001)(71200400001)(66476007)(66946007)(76116006)(91956017)(19627235002)(8676002)(81166006)(8936002)(81156014)(186003)(6506007)(966005)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0292; H:BL0PR00MB0772.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WrABTNAbE2eDCqdEn/5+keMrMCw6B6agZzVnkHR8GXPJ8fEmhpW1X2BylceyVatW70/CguBMZUD3QBWM6NVq9Lj6eG84JPgvj0/GEktG/EZFYOj8oIGnN7emUvRksOCFDNXARP3tjzRzNZpfXUGOcGMpEhgLFeZhdMS1DccFbZPNe23tjHa3xykgTXl3/EWx91QhmUeZG6xS0UlDEM5hvsu/eXwms3+r+3jXvcBlPQCM6bZfgMA2pphZC+daVLfkdoMoSBDC/R2YEGeTuogz2g/mxe/lq9HnlJsLAl8vtVMOkz2S68TJqDaT698vQ0ulxU95iXc0tUlQKFKA9mE0N9XMGVYUOywpLum3Ge2HDOoY9LmZm7YYhv7DJ9TyXRB/j4kZSDux3CskPURodKm0IgLrwQw1XWzj0B0CcSV0uEQZlqd1YIEgg2V1Npl1qku+Bq+deuxFRIT4Z7jfvmM42OB91nN0FZixof9twYSfdRD240VF+2FZaDMoHECbLBWGcA1hs87VrezDakDgpGU/sg== x-ms-exchange-antispam-messagedata: xMKQPWcn957xjfGV/z6KahoIcMA6hBIMI1C/W6xBLBY0DRagiOOx1AlZ/vwMuGz6LkMtmrcNXf00Doj6QRlX/uiJO4X7N7KmWttaXo83KgICHoTvjBmHz1cSRHqPyx/SFFXpi30M+6UBSk6WgJC4E910koIqm0Ix0TlCrCQTjVIQ9vrNAI2ujAIDxmflFWPof+PS8LWEK01BzgIv9Z04vg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0772B0612B82C75C4BF2B7AAFA030BL0PR00MB0772namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 65bf237b-9999-4424-b31b-08d7a9878a07 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 15:33:09.6598 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TaZsNX3RjFcPNGjDfhTOJeWGpZ3qXWIF+h1e0XqOzhjZwB/4JqhmbGmc9yqipR4kpWfdbOc8h3P0DTwc7UXgsA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0292 Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 15:33:14 -0000 --_000_BL0PR00MB0772B0612B82C75C4BF2B7AAFA030BL0PR00MB0772namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1, and calling this point out in particular (having a WG ignore parts of t= he charter just means the same conversations will occur without the WG lead= ing to a less ideal solution due to a smaller collaborative audience): > So, to the extent that there are many folks and parties interested in the= se specific problems, the discussions will inevitably happen. It seems pref= erable to have them happen in the context of the IETF so that the output be= nefits from other viewpoints and expertise. ________________________________ From: Add on behalf of Andrew Campling Sent: Tuesday, February 4, 2020 7:24 AM To: Kenji Baheux ; Paul Hoffman Cc: Eric Rescorla ; ADD Mailing list ; The IESG= ; add-chairs@ietf.org Subject: [EXTERNAL] Re: [Add] [Ext] Adam Roach's No Objection on charter-ie= tf-add-00-00: (with COMMENT) +1 to Kenji and Paul=92s points below. Andrew From: Kenji Baheux Sent: 04 February 2020 14:38 To: Paul Hoffman Cc: Eric Rescorla ; ADD Mailing list ; The IESG= ; add-chairs@ietf.org Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-0= 0: (with COMMENT) 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 participa= nts, on what appears to be unsubstantiated doubts about the wg's ability to= be productive, or to produce deliverables that will meet various stakehold= ers' 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 gr= oup members should notice and make a call or a change. If certain wg items result in unacceptable deliverables for specific stakeh= olders then so be it. Or, if certain wg items are non-starters for some sta= keholders, 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 prefer= able to have them happen in the context of the IETF so that the output bene= fits 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 > wrote: On Feb 4, 2020, at 12:45 PM, Eric Rescorla > 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 w= ork instead of ignoring likely future work. (Of course, there have also bee= n well-documented failures.) My preference would be to make it clear that t= here is a venue for the informational document, but not until the technical= work is done first. --Paul Hoffman-- Add mailing list Add@ietf.org https://www.ietf.org/mailman/listinfo/add --_000_BL0PR00MB0772B0612B82C75C4BF2B7AAFA030BL0PR00MB0772namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1, and calling this point out in particular (having a WG ignore p= arts of the charter just means the same conversations will occur without th= e WG leading to a less ideal solution due to a smaller collaborative audien= ce):

> So, to the extent that there are many folks and parties interested in these sp= ecific problems, the discussions will inevitably happen. It seems preferabl= e to have them happen in the context of the IETF so that the output benefit= s from other viewpoints and expertise.
From: Add <add-bounces@i= etf.org> on behalf of Andrew Campling <andrew.campling@419.consulting= >
Sent: Tuesday, February 4, 2020 7:24 AM
To: Kenji Baheux <kenjibaheux@google.com>; Paul Hoffman <pa= ul.hoffman@icann.org>
Cc: Eric Rescorla <ekr@rtfm.com>; ADD Mailing list <add@iet= f.org>; The IESG <iesg@ietf.org>; add-chairs@ietf.org <add-chai= rs@ietf.org>
Subject: [EXTERNAL] Re: [Add] [Ext] Adam Roach's No Objection on cha= rter-ietf-add-00-00: (with COMMENT)
 

+1 to Kenji a= nd Paul=92s points below.

 <= /b>

Andrew =

 

From: Kenji Baheux <kenjibaheux@google.com>
Sent: 04 February 2020 14:38
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: Eric Rescorla <ekr@rtfm.com>; ADD Mailing list <add@iet= f.org>; The IESG <iesg@ietf.org>; add-chairs@ietf.org
Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-a= dd-00-00: (with COMMENT)

 

After reading a few exchanges, I can't help but wo= nder why there is a need to preclude specific items of interest to a signif= icant 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' requiremen= ts, or of the wg's chairs inability to guide the group, etc.

 

If certain wg items end up not making progress the= n so be it. Chairs and group members should notice and make a call or a cha= nge.

 

If certain wg items result in unacceptable deliver= ables 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 pa= rties interested in these specific problems, the discussions will inevitabl= y happen. It seems preferable to have them happen in the context of the IET= F so that the output benefits from other viewpoints and expertise. That would at least increases the chance t= hat 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 <paul.hoffman@icann.org> wrote:

On Feb 4, 2020, at 12:45 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br> > 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 w= ork instead of ignoring likely future work. (Of course, there have also bee= n well-documented failures.) My preference would be to make it clear that t= here is a venue for the informational document, but not until the technical work is done first.

--Paul Hoffman--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

--_000_BL0PR00MB0772B0612B82C75C4BF2B7AAFA030BL0PR00MB0772namp_-- From nobody Tue Feb 4 07:56:55 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6014A12012C for ; Tue, 4 Feb 2020 07:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V45xGfs4mPpV for ; Tue, 4 Feb 2020 07:56:50 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE61D12011F for ; Tue, 4 Feb 2020 07:56:49 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id 21so1309819qki.5 for ; Tue, 04 Feb 2020 07:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QO/11jpqtOBV63kP/tucB5PNy4H+3Y+tROrdyUUM1S4=; b=gSb67/1r8PP+cBIS4/eCY3UI7Wzs2uL8hSbUymvGsZbLBmOcXP1ToQ/gHOqSIaBweP +EIpqSnDgX1Chx2u1JxT95401YL1y5eMllhiUy0Q/G/65SUPH4vVexTkMQGwwMvhUi6C KvMUZepQ0GxH6BogH80FC5xfaYQxLD1blA5cK8UrK7iGEFEyRITsvFJ67iXBSdjH55+X Cr+wFzAlz5cbBYXyHR2wEUUbhs7CRouFFUhCv4lz6NDaani/0R5fUye1Yqf3jfzXjUD7 Emi6zbXiZnI5r0TJ6tdKKSM0BWqWFtVeIxc14mIbYpEh68ELsI6GYDQOn4ThgxEb2jCx yYGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QO/11jpqtOBV63kP/tucB5PNy4H+3Y+tROrdyUUM1S4=; b=sTO+PwKnyWH0l7/jv5YwvjXUbJ6rqobOwfYT8DkTBsRFtJ/buGg2w1jgJl0Te/ERtK aZAYCpCeJpzxyI2sJJqtxlJITXOG4UaVmTmbLJt6BJaDoRTiS551EPJCWjcrv8IiRMZK KHaxwj/yxMbdC4Vl1vO6TF3//oiyxnRlm95MVoR2k6XCn7dN0u8aSqp5HOrs2Kdaazem L67+RnY76sO2O0ArKVc2+Kz2/YMuMaEYPbDcBBt2kwmkWnUrHAxuONoVOD0Clfvr/vsn 05C6BYuBOBq3FgbByozBIVFyECmOc/qpRfAHz+FMSmxVaG32mSdMWA5dzkVB6Ho3Mwua h15w== X-Gm-Message-State: APjAAAUHw3w/OrmdnaCoEveuIHZUTBB4XibdhMeMG/xdvhA89wPnu1bJ 3a6gnPEDdIBSW1E/qOreb0WwxA== X-Google-Smtp-Source: APXvYqw4M7U3b3tg1dYhuKQ3WHEDXZxMhZcXWWQg3RL8e+tiUj3KbkaqD76YQj1WToWge6ybSlrFjA== X-Received: by 2002:a37:bd85:: with SMTP id n127mr5347987qkf.113.1580831808835; Tue, 04 Feb 2020 07:56:48 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:8bd:956:15f6:1652? ([2601:18b:300:36ee:8bd:956:15f6:1652]) by smtp.gmail.com with ESMTPSA id t23sm11706744qtp.82.2020.02.04.07.56.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Feb 2020 07:56:48 -0800 (PST) From: Ted Lemon Message-Id: <37720CE6-E8E3-45B2-A795-9CE8A338C930@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_02FCAC92-F3C5-49BF-9364-A85D5C2E78AE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.13.2.1\)) Date: Tue, 4 Feb 2020 10:56:45 -0500 In-Reply-To: Cc: Paul Hoffman , Eric Rescorla , ADD Mailing list , The IESG , "add-chairs@ietf.org" To: Kenji Baheux References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> <4ACF4FA6-A595-4ACE-99AB-2EAA2CE97638@fugue.com> X-Mailer: Apple Mail (2.3608.80.13.2.1) Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 15:56:52 -0000 --Apple-Mail=_02FCAC92-F3C5-49BF-9364-A85D5C2E78AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 4, 2020, at 10:30 AM, Kenji Baheux = wrote: > On Tue, Feb 4, 2020, 09:00 Ted Lemon > wrote: > On Feb 4, 2020, at 9:37 AM, Kenji Baheux = > 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. >=20 > The reason for this is that when a working group is given a work item = on which it=E2=80=99s 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 >=20 > 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=E2=80=99s 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=E2=80=99= 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=E2=80=99s presumed that they are supposed = to publish something that corresponds to that work item; not publishing = it becomes an exception. So it=E2=80=99s 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=E2=80=99s harder to argue against adoption: proponents = can simply say =E2=80=9Cwell, we can address your concerns once the = document has been adopted.=E2=80=9D 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 =E2=80=9Cyeah, go = ahead and publish it,=E2=80=9D because it=E2=80=99s _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=E2=80=99t, the process of preventing them from passing is very = expensive. It=E2=80=99s 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=E2=80=99t publish anything without getting consensus to = add the work to the charter. This allows participants to choose their = battles more carefully=E2=80=94if something is a bad idea, but there=E2=80= =99s no recharter going on, you can say it=E2=80=99s a bad idea and then = ignore the discussion until the rechartering happens, at which point you = can point out that you=E2=80=99ve already objected and why, and = hopefully the right thing happens in the consensus process. --Apple-Mail=_02FCAC92-F3C5-49BF-9364-A85D5C2E78AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Feb 4, 2020, at 10:30 AM, Kenji Baheux <kenjibaheux@google.com> wrote:
On Tue, Feb 4, 2020, 09:00 Ted Lemon = <mellon@fugue.com> wrote:
On Feb 4, 2020, at 9:37 AM, Kenji Baheux <kenjibaheux=3D40google.com@dmarc.ietf.org> 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=E2=80=99s 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=E2=80=99s 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=E2=80=99s = 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=E2=80=99s = presumed that they are supposed to publish something that corresponds to = that work item; not publishing it becomes an exception.  So it=E2=80=99= 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=E2=80=99s harder to argue against adoption: proponents can = simply say =E2=80=9Cwell, we can address your concerns once the document = has been adopted.=E2=80=9D   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 =E2=80=9Cyeah, go ahead = and publish it,=E2=80=9D because it=E2=80=99s _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=E2=80=99t, the process of preventing them = from passing is very expensive.  It=E2=80=99s = 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=E2=80=99t publish anything without getting consensus to add the work = to the charter.  This allows participants to choose their battles = more carefully=E2=80=94if something is a bad idea, but there=E2=80=99s = no recharter going on, you can say it=E2=80=99s a bad idea and then = ignore the discussion until the rechartering happens, at which point you = can point out that you=E2=80=99ve already objected and why, and = hopefully the right thing happens in the consensus process.

= --Apple-Mail=_02FCAC92-F3C5-49BF-9364-A85D5C2E78AE-- From nobody Tue Feb 4 08:02:58 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C274C120144 for ; Tue, 4 Feb 2020 08:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWbbCk4xPlZN for ; Tue, 4 Feb 2020 08:02:50 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B031201AA for ; Tue, 4 Feb 2020 08:02:50 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id x1so18414281qkl.12 for ; Tue, 04 Feb 2020 08:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IdetwyM40wVBkRPsoHY6ve5uC4KE2zuGwRcHJu3bUZ4=; b=2Bdup8sxKS6z3pZj0DBZxvxNZ1kHJrvdbqTEC69obJdgF+9Cjp9s48UoiwC6j2yXlM RGWPedF5ouJvniSE5+gjcwpqxOPHlhQ6jvJ7QOBi7/yKsJ/B7LP++GN4ZmbPN3v0oDIg tR/s3CNwIBOg4EdOnMG6Riw4+pEso3Baxzph4bV0ONResddfAO58YtmlLe1NY5J5Bvy6 aCz+Jq6lNUj7789EH5T3nprNW6S8lxlZ+X2yq+kqX9WuYaCyTjTL+cl4OirudXOKAWT5 cBQR+++bmkIJmcBoPc4j9MjOtO74h1oyVb49o3OKDqR4LxC+cTnAJRY3GpVvQZcxZHKg IDdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IdetwyM40wVBkRPsoHY6ve5uC4KE2zuGwRcHJu3bUZ4=; b=oSPKM2EXaJR0ZQd0TI36DFnRrzMpcOCMkcEe2PCiPgYyoTzZ7N3O4uOO+rgGBEP9g+ dtRQD6MmDhdA0oq5frRjrOrHdjUU4JcYVVq9GTHJi45zepa5S92VMJ6Rymbfz/RcWvDq lLK3YcptkzuA7WK2j1Va8+2GNiKtwL8GW7krHTHiJJEEH46zWDG4d2Zg+C58+HmKLI7u Sw9HHOOtZJPZofayRU2SGQOjevawA1wMzZC77tlN7wOXNhBYrvm3S0K5DvyHaBS32S0c 2gARU5V14NTwsTUif09LXUQAwq6fzsHDIuypJ+ktcjf/HzvDenL3u5Sqf/qGCmx55BcQ ZZ3g== X-Gm-Message-State: APjAAAVJb/S6jqbuU1MsvV80m/DAKhrCPxTZ0Cf77W5FI57JzndnZYwD EMs2gm+lsCTRCf54BKsewvjI1jt5oxj27pHR1xrbGA== X-Google-Smtp-Source: APXvYqydbO9KBYB0RGzceHqKTJGVpesMK3eP4khHNlxWStIXm9pzwG4HDoLfCK3fETEK7B3MzurWRIF6zbWds1O6T6Y= X-Received: by 2002:a05:620a:15e9:: with SMTP id p9mr30099167qkm.490.1580832169474; Tue, 04 Feb 2020 08:02:49 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> <4ACF4FA6-A595-4ACE-99AB-2EAA2CE97638@fugue.com> In-Reply-To: From: Richard Barnes Date: Tue, 4 Feb 2020 11:02:21 -0500 Message-ID: To: Kenji Baheux Cc: Ted Lemon , Paul Hoffman , ADD Mailing list , "add-chairs@ietf.org" , Eric Rescorla , The IESG Content-Type: multipart/alternative; boundary="000000000000e94ca1059dc22b05" Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 16:02:54 -0000 --000000000000e94ca1059dc22b05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020 at 10:31 AM Kenji Baheux wrote: > > > On Tue, Feb 4, 2020, 09:00 Ted Lemon wrote: > >> On Feb 4, 2020, at 9:37 AM, Kenji Baheux < >> kenjibaheux=3D40google.com@dmarc.ietf.org> 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 vari= ous >> 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=E2=80=99s 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 on= e > 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 th= ey > 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 assumin= g > a certain direction they disagree with or they could be right but evidenc= e > 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 presente= d > said evidence? > > > If the work item is not in the charter, then this (sometimes massive) >> time tax doesn=E2=80=99t 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 "consensu= s" > on something that didn't get the full benefit of a broader panel of voice= s > with potential implementers unaware of the (unvoiced) downsides. > > >> So it really is important to exclude work items on which it=E2=80=99s un= likely >> that consensus can be reached. >> > > >> -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000e94ca1059dc22b05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 10:31 AM Kenji= Baheux <kenjibaheux=3D40= google.com@dmarc.ietf.org> wrote:


On Tue, Feb 4, 2020, 09:00 Te= d Lemon <mellon@fugue.com> wrote:
On Fe= b 4, 2020, at 9:37 AM, Kenji Baheux <k= enjibaheux=3D40google.com@dmarc.ietf.org> wrote:
After reading a few exchanges, I can&#= 39;t help but wonder why there is a need to preclude specific items of inte= rest to a significant number of participants, on what appears to be unsubst= antiated doubts about the wg's ability to be productive, or to produce = deliverables that will meet various stakeholders' requirements, or of t= he 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=E2=80=99s clear consensus cannot be reached, that = working group becomes a tax on the time of all the people who have to conti= nually participate in order to prevent consensus

It feels like we ar= e keeping hostage the whole charter just because of one item that's inf= ormational on top.

My impressi= on (as someone who's been mostly passive here) is actually the opposite= , namely that this one controversial work item is holding up progress on th= e things people agree are needed.=C2=A0 The work described in this third wo= rk item seems clearly separable from the other two items, in the sense that= the better discovery and decision support mechanisms can be built and depl= oyed without the deployment guidance.=C2=A0 Indeed, it is usually better to= write the deployment guidance after you have the mechanisms and some exper= ience 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.=C2=A0 That seems like a pretty cl= ear case for dropping it.

--Richard
<= div>


=C2=A0
Doe= s "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 &q= uot;consensus"? Or if this is a question of requirements, can't th= ese requirements be documented and justified once?
<= br>


being reached o= n what they consider to be a bad idea.
=

This seems to assume that som= e items in the charter would inevitably result in bad ideas, or that said i= tems are framed in terms of a specific (bad) idea and not a problem.
<= div dir=3D"auto">
The latter can be fixed right = now. The former could just be folks assuming a certain direction they disag= ree with or they could be right but evidence rather than belief seems prefe= rable. 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?


=C2=A0If the work item is not = in the charter, then this (sometimes massive) time tax doesn=E2=80=99t exis= t.

The work item will find a different home as long as there are par= ties interested in it. It might not be a tax time anymore for the unconvinc= ed folks but the outcome would be the same (worse in fact), i.e. a "co= nsensus" on something that didn't get the full benefit of a broade= r panel of voices with potential implementers unaware of the (unvoiced) dow= nsides.


So it really is important to exclude w= ork items on which it=E2=80=99s unlikely that consensus can be reached.


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000e94ca1059dc22b05-- From nobody Tue Feb 4 08:12:32 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE471201A3; Tue, 4 Feb 2020 08:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X5soBfvywmP; Tue, 4 Feb 2020 08:12:30 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8610D12018D; Tue, 4 Feb 2020 08:12:30 -0800 (PST) Received: from Zephyrus.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 014GC5W8014903 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 4 Feb 2020 10:12:06 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1580832728; bh=8XpFvUby8ClkjuvW1x1nxC7BK8nxsJJzrmb3/h0gkz4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=HSrUQe9aekCw1A6v7LMPuXv8F51S74JqebyXbnAJygaN21w6B3gN2g0KqEcocwX3d CzGxXTo7kaGdEmDmSBBujrNkDYx2/3MG0FNuyuviUdTwH/cEHz9uLH4W1sNZhbuIsf 0kWT6l+4HASFD8UnD7n3nOkFlzDz7WedSYboP/Ys= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Zephyrus.local To: "Deen, Glenn (NBCUniversal)" , Eric Rescorla , Paul Hoffman Cc: ADD Mailing list , The IESG , "add-chairs@ietf.org" References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> From: Adam Roach Message-ID: <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> Date: Tue, 4 Feb 2020 10:12:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> Content-Type: multipart/alternative; boundary="------------B3F7249CFC149A8A393B34CA" Content-Language: en-US Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 16:12:31 -0000 This is a multi-part message in MIME format. --------------B3F7249CFC149A8A393B34CA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/4/20 09:01, Deen, Glenn (NBCUniversal) wrote: > > On 2/4/20, 4:46 AM, "Add on behalf of Eric Rescorla" > on behalf of > ekr@rtfm.com > wrote: > > On Tue, Feb 4, 2020 at 4:37 AM Paul Hoffman > wrote: > > > >> - 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. > > 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. > > > While the ADD list and BoFs have certainly not been productive venues > for discussions that’s largely attributable to a variety of factors > which likely won’t be present in actual WG.   The ADD list and BoFs > have been very broad and wide open, and lacked the focus of a charter, > which resulted in unproductive discussions that didn’t progress.  The > WG conversely will have a specific charter to focus it and chairs to > help manage the activity. > Thanks. I completely agree that there is useful work that a tightly-scoped charter can foster. I also agree with the implied converse, which is that an insufficiently-tightly-scoped charter will make useful work difficult or impossible. /a --------------B3F7249CFC149A8A393B34CA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/4/20 09:01, Deen, Glenn (NBCUniversal) wrote:

 

 

On 2/4/20, 4:46 AM, "Add on behalf of Eric Rescorla" <add-bounces@ietf.org on behalf of ekr@rtfm.com> wrote:

 

On Tue, Feb 4, 2020 at 4:37 AM Paul Hoffman <paul.hoffman@icann.org> wrote:


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

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.


While the ADD list and BoFs have certainly not been productive venues for discussions that’s largely attributable to a variety of factors which likely won’t be present in actual WG.   The ADD list and BoFs have been very broad and wide open, and lacked the focus of a charter, which resulted in unproductive discussions that didn’t progress.  The WG conversely will have a specific charter to focus it and chairs to help manage the activity.


Thanks. I completely agree that there is useful work that a tightly-scoped charter can foster. I also agree with the implied converse, which is that an insufficiently-tightly-scoped charter will make useful work difficult or impossible.

/a

--------------B3F7249CFC149A8A393B34CA-- From nobody Tue Feb 4 08:14:37 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85A1120137 for ; Tue, 4 Feb 2020 08:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1gV1QrFjGru for ; Tue, 4 Feb 2020 08:14:33 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C899B120123 for ; Tue, 4 Feb 2020 08:14:33 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id w47so14716030qtk.4 for ; Tue, 04 Feb 2020 08:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fF/FiQXuH7+IdLOinrkljZkK9DFQmsrtoMZA8Nc9vb4=; b=OnXQz76rH9X9l+sEi8m0R1OYQ25+4DVKrBg+HF34zq8n6j8Ukzm7V9zEZsbh0j9cdY n0WhAu6b16/Mn8ACYuOWz6q98xMfTRO20eUa2yi/D6WBUREs56uWnka4MiTa01GmWQz4 P9pm60KRCGY47A9XxpNA7rxAMmEENYclkDQQC7iXRokAOLwEiqEBRmZlwehQiOXqAwdj FxGf2OvECe3JYnLEKzM1RRjeGsnHxjAgMHssBWnWxQShhUbkBGtDnKAxZ5NkqR4ADXtF SVoGk6C34mmkm4Dd0hHu2/PZC+QCdR/gcH9rxrMUJ/eMUEk/r2O389EVfQHgC3G5tUxk JPMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fF/FiQXuH7+IdLOinrkljZkK9DFQmsrtoMZA8Nc9vb4=; b=pxHleH8lDwkCDO/RGBCRpcUK/S2chei/HhDRWtAZ7blsnXsIygB1mF3rJ/GX16blQD chMnFG64q0h2b8omy+fN72lkFlijElapO6aIUNLyJYXGmvUhXpbKSutaTYNLLoowH+EH afO98jry6Y2UaMG8Cb7w6+eoSTCvlJo7l6Q7gMjKEVfHKHk0UJoRAWS473v/f2EikPOU Xk4jnVPWEJfW6+nM7W6off8cK7XoOv+tcBJYFIYwU0bRo9iO2mrVnUSqUO4pQcm/5gvw BZLc/U04AppTzpzas+YZtKA8duhmZQxicJ1h0pYQqnPD2SAYky+YaxqHZp5prWv6aRyG E96Q== X-Gm-Message-State: APjAAAW/3bRCuoe4kLKpV0unrPhdATlAHR/xQhttZClurTs73NhVrDLN seUpPwuxxz9pbtwVASg5XDr9y7ExpyJCKjobsvVHQecv2x8= X-Google-Smtp-Source: APXvYqy1RAxqXTC8dogngzcTRQJxxoZUGkqvtEvl87jnAsloZgnYInEyJXPPqekDk+lJCXImvbszt23uCMMyIceL3m4= X-Received: by 2002:ac8:387b:: with SMTP id r56mr28009554qtb.364.1580832872583; Tue, 04 Feb 2020 08:14:32 -0800 (PST) MIME-Version: 1.0 References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> In-Reply-To: From: Warren Kumari Date: Tue, 4 Feb 2020 11:13:56 -0500 Message-ID: To: Paul Hoffman Cc: Eric Rescorla , ADD Mailing list , The IESG , "add-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 16:14:36 -0000 On Tue, Feb 4, 2020 at 8:50 AM Paul Hoffman wrote: > > On Feb 4, 2020, at 12:45 PM, Eric Rescorla wrote: > > Well, perhaps, but we don't need an IETF WG for those discussions and t= he 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 b= een well-documented failures.) My preference would be to make it clear that= there is a venue for the informational document, but not until the technic= al work is done first. ... 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. --=20 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 nobody Tue Feb 4 08:38:16 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5091207FE for ; Tue, 4 Feb 2020 08:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqnWPQxcN4eg for ; Tue, 4 Feb 2020 08:38:07 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3B71201DC for ; Tue, 4 Feb 2020 08:38:07 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id q8so19275327ljj.11 for ; Tue, 04 Feb 2020 08:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ta9mgC7NLjxcmebzpRritIW90qM1Bz9TNxdF70l6A7Q=; b=MneS2LSXCluu04NU1MjB3EfdwPsXVmkctnp2VJqostkp9NHXHIaaPfUgyy1A+1oCHO v/fIk3b8UuImEooEAsByGWD7QQZV8PZj+FepqmSII2qBPxFKVenZ59FrNy+PxdXtU7aN DFiBMUPW1GexSlqrmgYm7twcmxOgrhJlYLyugQnKsu1g+yMmrA2g+r8MXdN2XRs+9Ncp xyodoVt0ZpGxu1fN5YJvGAjxXlwXSNKSVfZh07pgDLYx2dXy+rJQxOqFxHaxfu/IQXme Em3q43pI5W3iOF3dRZXTp5K02dfjZF9LPwDwoJ8fKaUAidNha5eDaIrGJxuX0w7VuY8/ scVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ta9mgC7NLjxcmebzpRritIW90qM1Bz9TNxdF70l6A7Q=; b=WMQwyGuanxDUz82TwIEdMHFdRpLwo8Csa8gzYoAPQ5bV3GMw28nv/kRW7f8LYFFPg5 u7I3T4cNXm3TwDbSs4UZ8zQ2g3NTr8I439KhIHx1W4l6/1udqH9FMhsM+l3FSK+VpaT5 VezipVm5aHXlULb5qUWQJucW25bsr6iLWXhVf9UuPiLIvt4VoEi7HYf6dgPojqrYhCOq BAEiTbTnAJ7EXlTz0fUholKHrlXxP/QR81JKVCQngCcCkQ+9lw5/noyMP2Rwh+YJvvp0 ZyM8qUEYtMAc15eM9zjQrmeCFri3n2PGG/dftQIR8K0w3Tz0K888FxY0agwYmPZ0WLEP B7pQ== X-Gm-Message-State: APjAAAX3NFBEcX+LG/op0WYaPln6jIfGxAcs2rRmIK/guOMP1RG4zdsO dzMn6ows1cBZcNuYs/3BPRUaTinzq5tfJXCzeQ8nHA== X-Google-Smtp-Source: APXvYqzMryWov80u2kcdSB8h6nuPtDvpeuHhc+lZOtkPdszpy5MhBcDeaaTDVcoHyLSusk1OOPgQd73P0cr4rZifktI= X-Received: by 2002:a2e:9b12:: with SMTP id u18mr17854815lji.274.1580834285327; Tue, 04 Feb 2020 08:38:05 -0800 (PST) MIME-Version: 1.0 References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> In-Reply-To: <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> From: Eric Rescorla Date: Tue, 4 Feb 2020 08:37:29 -0800 Message-ID: To: Adam Roach Cc: "Deen, Glenn (NBCUniversal)" , Paul Hoffman , ADD Mailing list , The IESG , "add-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000006d898059dc2aa76" Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 16:38:11 -0000 --00000000000006d898059dc2aa76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the interest of trying to move forward.... I agree that there are a bunch of tricky network scenarios that need to be handled (captive portals, VPNs, split DNS, etc.) and that providing some guidance here would be useful. What I'm trying to avoid is that bleeding into a lot of debating about policy and how particular clients ought to behave. With that in mind, here is what I suggest: 1. Revise that bullet to be more clearly technical: - develop an informational document that describes mechanisms for clients to detect specific network environments (captive portal, split horizon, etc.) and use that to inform their DNS configuration. 2. Add a sentence to the charter after the work items that says: "This working group is chartered solely to develop technical mechanisms. Making any recommendations about specific policies for clients and servers is out of scope." I think this would go a long way towards continuing the forms of productive engagement we have been seeing (which I agree there have been) while scoping out contentious and unproductive policy debates. -Ekr On Tue, Feb 4, 2020 at 8:12 AM Adam Roach wrote: > On 2/4/20 09:01, Deen, Glenn (NBCUniversal) wrote: > > > > > > On 2/4/20, 4:46 AM, "Add on behalf of Eric Rescorla" on behalf of ekr@rtfm.com> wrote: > > > > On Tue, Feb 4, 2020 at 4:37 AM Paul Hoffman > wrote: > > > >> - 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 =C3=89ric that the described work is ope= n-ended > > enough to result in unproductive and likely toxic interactions. It woul= d > > 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 conversation= s > > 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. > > However, taking it fully off the plate will lead to the same discussions > happening repeatedly due to current deployment strategies of major vendor= s. > > > > 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. > > > While the ADD list and BoFs have certainly not been productive venues for > discussions that=E2=80=99s largely attributable to a variety of factors w= hich > likely won=E2=80=99t be present in actual WG. The ADD list and BoFs hav= e been > very broad and wide open, and lacked the focus of a charter, which result= ed > in unproductive discussions that didn=E2=80=99t progress. The WG convers= ely will > have a specific charter to focus it and chairs to help manage the activit= y. > > > Thanks. I completely agree that there is useful work that a tightly-scope= d > charter can foster. I also agree with the implied converse, which is that > an insufficiently-tightly-scoped charter will make useful work difficult = or > impossible. > > /a > --00000000000006d898059dc2aa76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the interest of trying to move forward....

I agr= ee that there are a bunch of tricky network scenarios that
need to be ha= ndled (captive portals, VPNs, split DNS, etc.) and
that providing some g= uidance here would be useful. What I'm trying
to avoid is that bleed= ing into a lot of debating about policy and
how particular clients ought= to behave. With that in mind,
here is what I suggest:

1. Revise = that bullet to be more clearly technical:

=C2=A0 =C2=A0- develop an = informational document that describes mechanisms for
=C2=A0 =C2=A0client= s to detect specific network environments (captive portal,
=C2=A0 =C2=A0= split horizon, etc.) and use that to inform their DNS
=C2=A0 =C2=A0confi= guration.


2. Add a sentence to the charter after the work items = that says:

=C2=A0 =C2=A0"This working group is chartered solely= to develop technical
=C2=A0 =C2=A0mechanisms. Making any recommendation= s about specific policies
=C2=A0 =C2=A0for clients and servers is out of= scope."


I think this would go a long way towards continuin= g the forms
of productive engagement we have been seeing (which I agree<= br>there have been) while scoping out contentious and unproductive
polic= y debates.

-Ekr




=
On Tue, Feb 4, 2020 at 8:12 AM Adam R= oach <adam@nostrum.com> wrote= :
=20 =20 =20
On 2/4/20 09:01, Deen, Glenn (NBCUniversal) wrote:
=20 =20 =20

=C2=A0

=C2=A0

On 2/4/20, 4:46 AM, "Add on behalf of Eric Rescorla" <add-bounces@ietf.org on behalf of ekr@rtfm.co= m> wrote:

=C2=A0<= u>

On Tue, Feb 4, 2020 at 4:37 AM Paul Hoffman <paul.hoffman@icann.org> wrote:


>> - develop an informational document that describes how client
>>=C2=A0 applications and systems can manage selection = of DNS resolvers
>>=C2=A0 in various network environments and use cases.=
>=C2=A0
> Here I agree with both EKR and =C3=89ric 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.

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

=C2=A0<= u>

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.


While the ADD list and BoFs have certainly not been productive venues for discussions that=E2=80=99s largely attributable to a variety of factors which likely won=E2=80=99t be present in actua= l WG. =C2=A0=C2=A0The ADD list and BoFs have been very broad and wide o= pen, and lacked the focus of a charter, which resulted in unproductive discussions that didn=E2=80=99t progress.=C2=A0 The = WG conversely will have a specific charter to focus it and chairs to help manage the activity.


Thanks. I completely agree that there is useful work that a tightly-scoped charter can foster. I also agree with the implied converse, which is that an insufficiently-tightly-scoped charter will make useful work difficult or impossible.

/a

--00000000000006d898059dc2aa76-- From nobody Tue Feb 4 08:39:21 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F51120837; Tue, 4 Feb 2020 08:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.275, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF9BYCfsiJUc; Tue, 4 Feb 2020 08:39:14 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62AC120823; Tue, 4 Feb 2020 08:39:14 -0800 (PST) Received: from Zephyrus.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 014GcqsM019393 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 4 Feb 2020 10:38:53 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1580834334; bh=h3AIMAFM1mC6y5YSwtmfq6RnBeNbV/fj5KCvhcqAxjM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=kK45SLNxxlfAxUvMOCnrb8YCcn00gi5FS9TaABHkPnjG+t4pi1kXt03Bq8LHMwd1q tvTL/itnkeALDkPwKw5H+wzQHHYTMtQla2aKALvoM9j2cLCn9bIHn94O/57y+K9REI gS/q23GdY6ck5ViBeXYXtdf08kliuUHl26HarYzw= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Zephyrus.local To: Warren Kumari , Paul Hoffman Cc: Eric Rescorla , ADD Mailing list , The IESG , "add-chairs@ietf.org" References: <158079686065.28670.12404077861029265894.idtracker@ietfa.amsl.com> <553BBDBD-7A39-4C96-A76D-7BCE27157C77@icann.org> From: Adam Roach Message-ID: <1b9594e3-1aa5-8929-9a6c-7a00436e5e44@nostrum.com> Date: Tue, 4 Feb 2020 10:38:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 16:39:16 -0000 On 2/4/20 10:13, Warren Kumari wrote: > 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, 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 From nobody Tue Feb 4 08:41:58 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F7C120878; Tue, 4 Feb 2020 08:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.275, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AjBR6vHUk0c; Tue, 4 Feb 2020 08:41:56 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B119120873; Tue, 4 Feb 2020 08:41:56 -0800 (PST) Received: from Zephyrus.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 014GfqcZ019907 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 4 Feb 2020 10:41:53 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1580834514; bh=ic2PiCQQaxsSTzambAE904e15iNk+eVSysiM2it8gs0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=jrTgD7NY0l2PnQ0caXEh2kjGDGqWrGjAw7H+ytHFCGG60PIb8jX942E+tTelINZw7 Rxj0cdcLEIqgy+H4NtzACAANzRsjorvfL3E8nQKdn6Vk67fgQ3cgW+tYUXjW9zBAop tjLBvtgN/FnlbWgrQ+MVvbCohkeEeRgI5EXno2do= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Zephyrus.local To: Eric Rescorla Cc: "Deen, Glenn (NBCUniversal)" , Paul Hoffman , ADD Mailing list , The IESG , "add-chairs@ietf.org" References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> From: Adam Roach Message-ID: <9e1445a9-4030-706d-bee2-93905f470867@nostrum.com> Date: Tue, 4 Feb 2020 10:41:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 16:41:57 -0000 On 2/4/20 10:37, Eric Rescorla wrote: > In the interest of trying to move forward.... > > I agree that there are a bunch of tricky network scenarios that > need to be handled (captive portals, VPNs, split DNS, etc.) and > that providing some guidance here would be useful. What I'm trying > to avoid is that bleeding into a lot of debating about policy and > how particular clients ought to behave. With that in mind, > here is what I suggest: > > 1. Revise that bullet to be more clearly technical: > >    - develop an informational document that describes mechanisms for >    clients to detect specific network environments (captive portal, >    split horizon, etc.) and use that to inform their DNS >    configuration. > > > 2. Add a sentence to the charter after the work items that says: > >    "This working group is chartered solely to develop technical >    mechanisms. Making any recommendations about specific policies >    for clients and servers is out of scope." > > > I think this would go a long way towards continuing the forms > of productive engagement we have been seeing (which I agree > there have been) while scoping out contentious and unproductive > policy debates. Thanks. This crossed on the wire with my previous message, and I think it's a good example of the kinds of guiderails I was calling for. /a From nobody Tue Feb 4 09:43:42 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92AE120152; Tue, 4 Feb 2020 09:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mc1VqvpVp9iB; Tue, 4 Feb 2020 09:43:37 -0800 (PST) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5073B120132; Tue, 4 Feb 2020 09:43:37 -0800 (PST) Received: by mail-vk1-xa2a.google.com with SMTP id i4so5419147vkc.3; Tue, 04 Feb 2020 09:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hAPmXarA+LvT5gm1N9+O2jWeADlF9ZRPOQGPiNonSaw=; b=TpOiJfXBOSWR5TZ0/WZzhnSCRSuKOV2NhyGRTIhQ20mlFAVOGWF/eUkt5YOkVv8eGf 2n6WYU4zSgOSDBjz3tu+GNBxgB4GDhxNgzQKhGruNZYP08bfvVAkIFyrqlvJnlMv3THC Me0NT51fWfkE03S4qMzNyqpEcuw47wwC7e6FZyDw61pJ4VgHxKTtuoLWVH0N2Jv7XayC AGSKnbH34gGljCYssmA2lRxdfkRq5sT8wyg2Cv490H9H4DZWkQ/RU+CON5vLbV3PE2V8 6QXPXukOVqxybYBsNkKi9YX9uJXfRPyIiONRxPJDlJ9uDboCeHb4/110Debjq3PCGWYU PNaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hAPmXarA+LvT5gm1N9+O2jWeADlF9ZRPOQGPiNonSaw=; b=mYol+rlpzzcZKOXVyrNEe1ac82XmbDQNEnoxOrU9yn25Ar3OLK773R3VOQYWjDhmpn dnEBfaseXSvdanb0rDPNwFBU/GwJFH7Q1oj4W8RzHtxmRKmmy1HUoj0mC8UuxG+CMI6W mK40RsHTJWMyGJV6eGPrKTLawxD09nSZqT3L/HDERqXhPHZYcwdx1nfVHALyPJRQRKPU rXj16uK6FVAEyf+z7Zyb4KQCtU8DWYMUmyCe2bTF+SyG8WIxQw49T7xD3YW5j1ZrBaEl 2eICzAnc/x0mwH8b6YsbzNVErFy+RX040j0Ty/Mj8cQwGvCArT/dFsR7+nUZ99WV6iLo gxeA== X-Gm-Message-State: APjAAAUMfp8AvbriFsqeqls6EYW4IbdUf5EB5nsWMq3ntlIfH8zyaFc2 Cl5G8ruAm32zNbJgqjL5FYh92UYmTOP6OSPwaPw= X-Google-Smtp-Source: APXvYqxh9UF8H7cSGX8SOusZ2Vr+QMUjUO7ohEg1loeW+rv9Ow8NUN9lNoi6WQNbwOPwwm5IQgqHBW6ogEqQt47wLVU= X-Received: by 2002:a1f:7c0c:: with SMTP id x12mr17775679vkc.41.1580838216376; Tue, 04 Feb 2020 09:43:36 -0800 (PST) MIME-Version: 1.0 References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> In-Reply-To: From: Brian Dickson Date: Tue, 4 Feb 2020 09:43:25 -0800 Message-ID: To: Eric Rescorla Cc: Adam Roach , Paul Hoffman , ADD Mailing list , "add-chairs@ietf.org" , The IESG , "Deen, Glenn (NBCUniversal)" Content-Type: multipart/alternative; boundary="00000000000055a3fa059dc39464" Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 17:43:40 -0000 --00000000000055a3fa059dc39464 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020 at 8:38 AM Eric Rescorla wrote: > In the interest of trying to move forward.... > > I agree that there are a bunch of tricky network scenarios that > need to be handled (captive portals, VPNs, split DNS, etc.) and > that providing some guidance here would be useful. What I'm trying > to avoid is that bleeding into a lot of debating about policy and > how particular clients ought to behave. With that in mind, > here is what I suggest: > > 1. Revise that bullet to be more clearly technical: > > - develop an informational document that describes mechanisms for > clients to detect specific network environments (captive portal, > split horizon, etc.) and use that to inform their DNS > configuration. > > > 2. Add a sentence to the charter after the work items that says: > > "This working group is chartered solely to develop technical > mechanisms. Making any recommendations about specific policies > for clients and servers is out of scope." > > I'm fine if the wording on this can be adequately tuned, to match the goal. There are enough people in the world who can't distinguish these two kinds of things: "If X then Y" "X" I.e. What I am looking for, semantically, is that it is okay to have technical work for addressing policy goals, without that running afoul of the policy advocacy rule. That leaves any policy decisions to the developer/operator/user, but allows standardization (or informational documents or experimental work) on how to implement/operate/select the mechanism(s) that correspond to a particular policy.) The specifics of which work items within this area get worked on would be based on interest, etc., with adoption by the WG after initial work would be subject to WG adoption rules (consensus). Is this what you meant by, or is this consistent with, #1 and #2 above? Brian > > I think this would go a long way towards continuing the forms > of productive engagement we have been seeing (which I agree > there have been) while scoping out contentious and unproductive > policy debates. > > -Ekr > > > > > On Tue, Feb 4, 2020 at 8:12 AM Adam Roach wrote: > >> On 2/4/20 09:01, Deen, Glenn (NBCUniversal) wrote: >> >> >> >> >> >> On 2/4/20, 4:46 AM, "Add on behalf of Eric Rescorla" < >> add-bounces@ietf.org on behalf of ekr@rtfm.com> wrote: >> >> >> >> On Tue, Feb 4, 2020 at 4:37 AM Paul Hoffman >> wrote: >> >> >> >> - 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 =C3=89ric that the described work is >> open-ended >> > enough to result in unproductive and likely toxic interactions. It wou= ld >> > 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 conversatio= ns >> > 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. >> >> However, taking it fully off the plate will lead to the same discussions >> happening repeatedly due to current deployment strategies of major vendo= rs. >> >> >> >> Well, perhaps, but we don't need an IETF WG for those discussions and th= e >> evidence is that that's not a productive venue for them. >> >> >> While the ADD list and BoFs have certainly not been productive venues fo= r >> discussions that=E2=80=99s largely attributable to a variety of factors = which >> likely won=E2=80=99t be present in actual WG. The ADD list and BoFs ha= ve been >> very broad and wide open, and lacked the focus of a charter, which resul= ted >> in unproductive discussions that didn=E2=80=99t progress. The WG conver= sely will >> have a specific charter to focus it and chairs to help manage the activi= ty. >> >> >> Thanks. I completely agree that there is useful work that a >> tightly-scoped charter can foster. I also agree with the implied convers= e, >> which is that an insufficiently-tightly-scoped charter will make useful >> work difficult or impossible. >> >> /a >> > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000055a3fa059dc39464 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 8:38 AM Eric R= escorla <ekr@rtfm.com> wrote:
=
In= the interest of trying to move forward....

I agree that there are a= bunch of tricky network scenarios that
need to be handled (captive port= als, VPNs, split DNS, etc.) and
that providing some guidance here would = be useful. What I'm trying
to avoid is that bleeding into a lot of d= ebating about policy and
how particular clients ought to behave. With th= at in mind,
here is what I suggest:

1. Revise that bullet to be m= ore clearly technical:

=C2=A0 =C2=A0- develop an informational docum= ent that describes mechanisms for
=C2=A0 =C2=A0clients to detect specifi= c network environments (captive portal,
=C2=A0 =C2=A0split horizon, etc.= ) and use that to inform their DNS
=C2=A0 =C2=A0configuration.

2. Add a sentence to the charter after the work items that says:

= =C2=A0 =C2=A0"This working group is chartered solely to develop techni= cal
=C2=A0 =C2=A0mechanisms. Making any recommendations about specific p= olicies
=C2=A0 =C2=A0for clients and servers is out of scope."
<= br>

I'm fine if the wording on th= is can be adequately tuned, to match the goal.
There are enough p= eople in the world who can't distinguish these two kinds of things:
"If X then Y"
"X"

=
I.e. What I am looking for, semantically, is that it is okay to have t= echnical work for addressing
policy goals, without that running a= foul of the policy advocacy rule.
That leaves any policy decision= s to the developer/operator/user, but allows standardization
(or = informational documents or experimental work) on how to implement/operate/s= elect
the mechanism(s) that correspond to a particular policy.)

The specifics of which work items within this area = get worked on would be based on interest, etc.,
with adoption by = the WG after initial work would be subject to WG adoption rules (consensus)= .

Is this what you meant by, or is this consistent= with,=C2=A0 #1 and #2 above?

Brian

=
=C2=A0

I think this would go a long way towards continuing the = forms
of productive engagement we have been seeing (which I agree
the= re have been) while scoping out contentious and unproductive
policy deba= tes.

-Ekr




On Tue, Feb 4, 2020 at 8:12 AM Adam Roach &= lt;adam@nostrum.com> wrote:
=20 =20 =20
On 2/4/20 09:01, Deen, Glenn (NBCUniversal) wrote:
=20 =20 =20

=C2=A0

=C2=A0

=C2=A0<= u>

On Tue, Feb 4, 2020 at 4:37 AM Paul Hoffman <paul.hoffman@icann.org> wrote:


>> - develop an informational document that describes how client
>>=C2=A0 applications and systems can manage selection = of DNS resolvers
>>=C2=A0 in various network environments and use cases.=
>=C2=A0
> Here I agree with both EKR and =C3=89ric 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.

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

=C2=A0

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.


While the ADD list and BoFs have certainly not been productive venues for discussions that=E2=80=99s largely attributable to a variety of factors which likely won=E2=80=99t be present in actua= l WG. =C2=A0=C2=A0The ADD list and BoFs have been very broad and wide o= pen, and lacked the focus of a charter, which resulted in unproductive discussions that didn=E2=80=99t progress.=C2=A0 The = WG conversely will have a specific charter to focus it and chairs to help manage the activity.


Thanks. I completely agree that there is useful work that a tightly-scoped charter can foster. I also agree with the implied converse, which is that an insufficiently-tightly-scoped charter will make useful work difficult or impossible.

/a

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000055a3fa059dc39464-- From nobody Tue Feb 4 09:56:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87DE12087B; Tue, 4 Feb 2020 09:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CthKPp4Lk_8L; Tue, 4 Feb 2020 09:56:24 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE32120869; Tue, 4 Feb 2020 09:56:23 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id 014HqbUw037416; Tue, 4 Feb 2020 09:56:02 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=U9yOkTXAMumi4kefPikSYfISYRwYtRP3IzIakzrxb6k=; b=CGxHZ8WzUKkixrnGnM4mPvDwp4V0h4XYLoNhKCVUEI8O9KAxHwFlh3oeh6qW9QvSKb2w Xd2VOPvg+x5MQCRjknA+9j8+ozKVi6JYqgmZAP7WkZUFnaGhxAd08/n7d3c6zMZehNFj ihcseto1QRIjRJWW+iqLbdfNCrtdZ39EOgSE0DHfC5sWLiS1oBw1N4AJ9fEaUiXTEi30 aaIUK0SYYtn9RzTVVjSmWN4JrSqVUKDHl2ELSvbirObTOflQ6X0mTox/PlaPxuRm1rkO fAGyu613MFp5fNx2Ail9hQRaOe/m9OOAacwzlG+stgOeQ91vO6aIj3LW4LqbeSORfPmL 9A== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2xw971gxt9-12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 04 Feb 2020 09:56:02 -0800 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q56009LDV5DSW20@rn-mailsvcp-mta-lapp01.rno.apple.com>; Tue, 04 Feb 2020 09:56:01 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q5600600UTDCY00@nwk-mmpp-sz09.apple.com>; Tue, 04 Feb 2020 09:56:01 -0800 (PST) X-Va-A: X-Va-T-CD: f3fe944e6c679f2c3d972f4bd0691c8b X-Va-E-CD: 8dd54ad2e36200a3297bce3344705868 X-Va-R-CD: 2647f1cddbb9eb586154a74b589ce6cf X-Va-CD: 0 X-Va-ID: db6b0ce7-154a-4360-98a0-6385bb5d516b X-V-A: X-V-T-CD: f3fe944e6c679f2c3d972f4bd0691c8b X-V-E-CD: 8dd54ad2e36200a3297bce3344705868 X-V-R-CD: 2647f1cddbb9eb586154a74b589ce6cf X-V-CD: 0 X-V-ID: bf95d304-eb7c-4bf4-9dbd-58fb529df5ec X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-04_06:,, signatures=0 Received: from [17.230.171.197] (unknown [17.230.171.197]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q5600F4GV5DDK00@nwk-mmpp-sz09.apple.com>; Tue, 04 Feb 2020 09:56:01 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) From: Tommy Pauly In-reply-to: <9e1445a9-4030-706d-bee2-93905f470867@nostrum.com> Date: Tue, 04 Feb 2020 09:56:01 -0800 Cc: Eric Rescorla , Paul Hoffman , ADD Mailing list , "add-chairs@ietf.org" , The IESG , "Deen, Glenn (NBCUniversal)" Content-transfer-encoding: quoted-printable Message-id: References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> <9e1445a9-4030-706d-bee2-93905f470867@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-04_06:, , signatures=0 Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 17:56:26 -0000 > On Feb 4, 2020, at 8:41 AM, Adam Roach wrote: >=20 > On 2/4/20 10:37, Eric Rescorla wrote: >> In the interest of trying to move forward.... >>=20 >> I agree that there are a bunch of tricky network scenarios that >> need to be handled (captive portals, VPNs, split DNS, etc.) and >> that providing some guidance here would be useful. What I'm trying >> to avoid is that bleeding into a lot of debating about policy and >> how particular clients ought to behave. With that in mind, >> here is what I suggest: >>=20 >> 1. Revise that bullet to be more clearly technical: >>=20 >> - develop an informational document that describes mechanisms for >> clients to detect specific network environments (captive portal, >> split horizon, etc.) and use that to inform their DNS >> configuration. >>=20 >>=20 >> 2. Add a sentence to the charter after the work items that says: >>=20 >> "This working group is chartered solely to develop technical >> mechanisms. Making any recommendations about specific policies >> for clients and servers is out of scope." >>=20 >>=20 >> I think this would go a long way towards continuing the forms >> of productive engagement we have been seeing (which I agree >> there have been) while scoping out contentious and unproductive >> policy debates. >=20 >=20 > Thanks. This crossed on the wire with my previous message, and I think = it's a good example of the kinds of guiderails I was calling for. +1 I think both of these textual changes are appropriate, and clarify the = intent of the charter, without unduly constraining the technical work of = a group. I support performing both of these changes! Thanks ekr for the suggestions. Best, Tommy >=20 > /a >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Tue Feb 4 10:04:39 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A71E120895; Tue, 4 Feb 2020 10:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_JB6u6YB-oL; Tue, 4 Feb 2020 10:04:36 -0800 (PST) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60FD612088C; Tue, 4 Feb 2020 10:04:36 -0800 (PST) Received: from pps.filterd (m0047965.ppops.net [127.0.0.1]) by m0047965.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 014I3HNh044555; Tue, 4 Feb 2020 13:04:36 -0500 Received: from usushmgip002.mail.tfayd.com ([216.178.109.236]) by m0047965.ppops.net-00176a04. with ESMTP id 2xwqdten2r-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT); Tue, 04 Feb 2020 13:04:35 -0500 Received: from unknown (HELO ashemwp00001.mail.tfayd.com) ([10.40.33.204]) by usushmgip002.mail.tfayd.com with ESMTP; 04 Feb 2020 10:04:34 -0800 Received: from ashemwp00008.mail.tfayd.com (100.126.24.32) by ashemwp00003.mail.tfayd.com (100.126.24.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Tue, 4 Feb 2020 13:04:32 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (10.40.78.204) by ashemwp00008.mail.tfayd.com (100.126.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Tue, 4 Feb 2020 13:04:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mdsllzbFoPT3bqn72Kts5ZdjD72AvjQEr9P5xy3WQTFT2vbp7EVBx57QgtXm1Yf2iwmLf8No91Ff7/spGkFcuopxM0b0ewlG0dWAqf6Vdx4sW0gOldEQxhi6pX++0dzAEK2ek+DhwaFGR1RQa7F/6i//zFcvDP46ZaR4l36YdEbnsxCLLM9O4Qa5KN+uF56qJ03jawb2H8Ijfng4qtnMTm0AhjEHiOYoFJd6jfx1M2plekmJoFnJnXwyswFEZYAztY9Re/E1hUu2WphuAFNBN+AROsoTb/ZSfC0I3B6lG8mZPNcA9k3zsA9LWJgJ0ocF9ZVOFNAKg8aMXaH+TsPBOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ErLC2uP4EdBbr6TbV6SIDVZVghutfPLpwxrP56tRrO8=; b=HDJcH1BdHHyOZttblYQbQA5Rg1XfHynwK7Bet/Jn7m4EAJ3QlmXp/G0R0eCnwEprP5Zsqb4wpzFzz8/9sSim8o7O9HbWC9rU7wOBqb2svsbgJT7OKcn5gQgKwJJ8CV0YbvH4IkVm4TX7uoZjSBHLgciLE5lX7v1yqe9xqip0MG1tbqv0kTij82UA9lbAYUXrf4aHKSxJ4uO+sai8Zzm+1M2NZuo9gGAMJQSSMoHrlQzNhWW6Lr14zOmdBksiwASN36BJTG+PguG4nlEDgl6cl6zh5HIC1Hoic7H0nznC97M3R/MYFyVhP2OTNqWY4DrR8+Eo5CiKcMEzQLLOb7PPpg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ErLC2uP4EdBbr6TbV6SIDVZVghutfPLpwxrP56tRrO8=; b=jVbEvPvVOHSbWeSWVwL2p1EfnWfe7fUOH6tYg0wtOV6c7cIM13qShIivBVc/tht8lb6On5dkwUGTlfhJLpq+8BNTaHif3ImhpYsUpIWzzOY1XIePFGHxCtUeYMTmZD/JmY1vRanRfKjC4gbZ3kSk3waR0UGCZif9biFP0JAL/hQ= Received: from DM6PR14MB3993.namprd14.prod.outlook.com (10.141.186.71) by DM6PR14MB3130.namprd14.prod.outlook.com (20.179.162.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Tue, 4 Feb 2020 18:04:31 +0000 Received: from DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592]) by DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592%5]) with mapi id 15.20.2707.020; Tue, 4 Feb 2020 18:04:31 +0000 From: "Deen, Glenn (NBCUniversal)" To: Tommy Pauly , Adam Roach CC: Eric Rescorla , "add-chairs@ietf.org" , Paul Hoffman , ADD Mailing list , "The IESG" , "Deen, Glenn (NBCUniversal)" Thread-Topic: [EXTERNAL] Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV22vrPcdD40Urck+l7pvZ13+j/KgLNNEAgAAHHoCAAAE0gIAAFL6AgAACXgA= Date: Tue, 4 Feb 2020 18:04:31 +0000 Message-ID: References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> <9e1445a9-4030-706d-bee2-93905f470867@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-originating-ip: [69.241.73.100] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 82da51e4-445e-4135-6a0c-08d7a99caf02 x-ms-traffictypediagnostic: DM6PR14MB3130: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(346002)(396003)(376002)(136003)(39860400002)(189003)(199004)(316002)(6512007)(2616005)(966005)(478600001)(76116006)(5660300002)(36756003)(91956017)(6506007)(53546011)(66946007)(66476007)(66556008)(64756008)(66446008)(81156014)(186003)(81166006)(86362001)(8936002)(8676002)(54906003)(110136005)(2906002)(6486002)(4326008)(107886003)(33656002)(71200400001)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR14MB3130; H:DM6PR14MB3993.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nbcuni.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1bRyG7dZGzT38t3EuwQAPT5vNYlmBprWiefrMgI4UMRtAS0cU6ocWxVws0WqS+5X+IwG01lNx8ZGBp6tezP/2YnyAZElRpOwZpHMvH5kmWYNuQ9LyF4xyrZd405BNPuT9kIzbolWezcd6uKMJT8daiKWJVZVOIlcrnq0OiDvOHaFu+bHNS9fHlm8JrCPoHFhQhqIRJwEf6Q54eKCTjv57A6Z1uERtGTMOPJ/TwzTAEO77VZeuXdCem4v6doIqjta8HFb6yPrKAVb1KW9UUbAqZ2tqfUzdJ0CWO0Lyb7rAa8es/q3xn/m0wbQFJXQLWjYu0jlBRpkDep6K5LMFvb690LiWErTKMXN9eU/ChS7D7rXXQmKWlvGNAY0QuBGS/a3lsCrqM8H/iA0WAT/bIypFG2aTmk7JCjS5uo4QZejak04v/13eLMZk1NaNzHUXPdJ5w9V4fQeUnVLQ0DZHgqaKsrRt+hJSvknHRdYEEdnTQXiz6bhND0u618bvaeFJsw3QagjS4cswfm6TH7QnQyxCw== x-ms-exchange-antispam-messagedata: 7iNVfHOk8nxb/7O8p2HSOTHoXDhcTNA0zUhwFlxNbdOj/erd06Gv68XQNi5ZvoR4uRt4LJd55xiCAj3Ni4v3NUIvMh/TZvHkeHmLbaz5c1IiNL9i8oz70iKic5nPSLcLOviJST0uXnpvZBZAIpWxDw== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 82da51e4-445e-4135-6a0c-08d7a99caf02 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 18:04:31.0884 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FPNZ0fkpREzIekCmJZ6VYU01sON6xinKslcVn+qfU5DDY+fPeJ4hbe+RitiVtQDtcdupP38ZO/nq7fyeq/8Vgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB3130 X-OriginatorOrg: nbcuni.com X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-04_06:2020-02-04, 2020-02-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 malwarescore=0 suspectscore=0 spamscore=0 bulkscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 clxscore=1015 adultscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2002040120 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 18:04:38 -0000 DQoNCu+7v09uIDIvNC8yMCwgOTo1NiBBTSwgIkFkZCBvbiBiZWhhbGYgb2YgVG9tbXkgUGF1bHki IDxhZGQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgdHBhdWx5PTQwYXBwbGUuY29tQGRt YXJjLmlldGYub3JnPiB3cm90ZToNCg0KICAgIA0KICAgIA0KICAgID4gT24gRmViIDQsIDIwMjAs IGF0IDg6NDEgQU0sIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+IHdyb3RlOg0KICAgID4g DQogICAgPiBPbiAyLzQvMjAgMTA6MzcsIEVyaWMgUmVzY29ybGEgd3JvdGU6DQogICAgPj4gSW4g dGhlIGludGVyZXN0IG9mIHRyeWluZyB0byBtb3ZlIGZvcndhcmQuLi4uDQogICAgPj4gDQogICAg Pj4gSSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBhIGJ1bmNoIG9mIHRyaWNreSBuZXR3b3JrIHNjZW5h cmlvcyB0aGF0DQogICAgPj4gbmVlZCB0byBiZSBoYW5kbGVkIChjYXB0aXZlIHBvcnRhbHMsIFZQ TnMsIHNwbGl0IEROUywgZXRjLikgYW5kDQogICAgPj4gdGhhdCBwcm92aWRpbmcgc29tZSBndWlk YW5jZSBoZXJlIHdvdWxkIGJlIHVzZWZ1bC4gV2hhdCBJJ20gdHJ5aW5nDQogICAgPj4gdG8gYXZv aWQgaXMgdGhhdCBibGVlZGluZyBpbnRvIGEgbG90IG9mIGRlYmF0aW5nIGFib3V0IHBvbGljeSBh bmQNCiAgICA+PiBob3cgcGFydGljdWxhciBjbGllbnRzIG91Z2h0IHRvIGJlaGF2ZS4gV2l0aCB0 aGF0IGluIG1pbmQsDQogICAgPj4gaGVyZSBpcyB3aGF0IEkgc3VnZ2VzdDoNCiAgICA+PiANCiAg ICA+PiAxLiBSZXZpc2UgdGhhdCBidWxsZXQgdG8gYmUgbW9yZSBjbGVhcmx5IHRlY2huaWNhbDoN CiAgICA+PiANCiAgICA+PiAgICAtIGRldmVsb3AgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCB0 aGF0IGRlc2NyaWJlcyBtZWNoYW5pc21zIGZvcg0KICAgID4+ICAgIGNsaWVudHMgdG8gZGV0ZWN0 IHNwZWNpZmljIG5ldHdvcmsgZW52aXJvbm1lbnRzIChjYXB0aXZlIHBvcnRhbCwNCiAgICA+PiAg ICBzcGxpdCBob3Jpem9uLCBldGMuKSBhbmQgdXNlIHRoYXQgdG8gaW5mb3JtIHRoZWlyIEROUw0K ICAgID4+ICAgIGNvbmZpZ3VyYXRpb24uDQogICAgPj4gDQogICAgPj4gDQogICAgPj4gMi4gQWRk IGEgc2VudGVuY2UgdG8gdGhlIGNoYXJ0ZXIgYWZ0ZXIgdGhlIHdvcmsgaXRlbXMgdGhhdCBzYXlz Og0KICAgID4+IA0KICAgID4+ICAgICJUaGlzIHdvcmtpbmcgZ3JvdXAgaXMgY2hhcnRlcmVkIHNv bGVseSB0byBkZXZlbG9wIHRlY2huaWNhbA0KICAgID4+ICAgIG1lY2hhbmlzbXMuIE1ha2luZyBh bnkgcmVjb21tZW5kYXRpb25zIGFib3V0IHNwZWNpZmljIHBvbGljaWVzDQogICAgPj4gICAgZm9y IGNsaWVudHMgYW5kIHNlcnZlcnMgaXMgb3V0IG9mIHNjb3BlLiINCiAgICA+PiANCiAgICA+PiAN CiAgICA+PiBJIHRoaW5rIHRoaXMgd291bGQgZ28gYSBsb25nIHdheSB0b3dhcmRzIGNvbnRpbnVp bmcgdGhlIGZvcm1zDQogICAgPj4gb2YgcHJvZHVjdGl2ZSBlbmdhZ2VtZW50IHdlIGhhdmUgYmVl biBzZWVpbmcgKHdoaWNoIEkgYWdyZWUNCiAgICA+PiB0aGVyZSBoYXZlIGJlZW4pIHdoaWxlIHNj b3Bpbmcgb3V0IGNvbnRlbnRpb3VzIGFuZCB1bnByb2R1Y3RpdmUNCiAgICA+PiBwb2xpY3kgZGVi YXRlcy4NCiAgICA+IA0KICAgID4gDQogICAgPiBUaGFua3MuIFRoaXMgY3Jvc3NlZCBvbiB0aGUg d2lyZSB3aXRoIG15IHByZXZpb3VzIG1lc3NhZ2UsIGFuZCBJIHRoaW5rIGl0J3MgYSBnb29kIGV4 YW1wbGUgb2YgdGhlIGtpbmRzIG9mIGd1aWRlcmFpbHMgSSB3YXMgY2FsbGluZyBmb3IuDQogICAg DQogICAgKzENCiAgICANCiAgICBJIHRoaW5rIGJvdGggb2YgdGhlc2UgdGV4dHVhbCBjaGFuZ2Vz IGFyZSBhcHByb3ByaWF0ZSwgYW5kIGNsYXJpZnkgdGhlIGludGVudCBvZiB0aGUgY2hhcnRlciwg d2l0aG91dCB1bmR1bHkgY29uc3RyYWluaW5nIHRoZSB0ZWNobmljYWwgd29yayBvZiBhIGdyb3Vw LiBJIHN1cHBvcnQgcGVyZm9ybWluZyBib3RoIG9mIHRoZXNlIGNoYW5nZXMhDQogICAgDQogICAg VGhhbmtzIGVrciBmb3IgdGhlIHN1Z2dlc3Rpb25zLg0KICAgIA0KICAgIEJlc3QsDQogICAgVG9t bXkNCg0KKzENCg0KSSBhbHNvIGRvbid0IGhhdmUgYW55IGhlYXJ0YnVybiB3aXRoIGVpdGhlciBv ZiB0aGUgc3VnZ2VzdGVkIGNoYW5nZXMuIFRoZXkgY2xhcmlmeSB0aGUgbWlzc2lvbiB3aGlsZSBr ZWVwaW5nIHRoZSBjaGFydGVyIGNsZWFuIGVub3VnaCB0aGF0IGl0J3Mgc2ltcGxlIHRvIHJlYWQg YW5kIHVuZGVyc3RhbmQuDQoNCi1nbGVubg0KDQogICAgLS0gDQogICAgQWRkIG1haWxpbmcgbGlz dA0KICAgIEFkZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FkZF9fOyEhUElaZWVXNXdzY3luUlEh NU9HRUJXaTVEenZqczQ3cHlIS3JHX3lfa1NEV3o2Y3d4NFk1eW9VM0hMMjYzdW5KeFN0VDdMWkEw UkpKcHoyVyQgDQogICAgDQoNCg== From nobody Tue Feb 4 10:20:57 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3C7120834; Tue, 4 Feb 2020 10:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwwdaktueheH; Tue, 4 Feb 2020 10:20:48 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640096.outbound.protection.outlook.com [40.107.64.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8698A12082B; Tue, 4 Feb 2020 10:20:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CO2AlMQIrjWkLrWlDJPsxjwIMJYQWG5I5MIoTSEuEB1RYGtg7Ze2TzQZdWGXT4xojDrcbuw/qGMgDnfSaEZVW1rqH8d7b9UPDO/JWCw+2YR+4MDgC+qrmXMOJvzgCU4KY4PTyBJkVbF5hxd3ytE2i9FloEHvPrjaXZVtJnPqZi9FWXMbDj4I9rYRubkqnEnAx8gzKwUuPW66dWQPcI5Z05iEYVqYproCotT2hETFVCswHH7cAQJBSVEKOOwETrESKfBAaC0EzlNpYBA7SZQzyUMTUPdN3M9vzlQXmFoOE4iyi0okzqaVD/QG1lrZK5KdhjbPYEGQDpnxQSNXsmeIfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r7fjYt0zgVFRvqiVv0d9WrISFu5gZCDgMDhy3q2yeWk=; b=E0oUogp551YpRxyEwpwGsg+GOLIvjeieW94jmWzW06hCYOgVr3ru9iP0FT4AmgvE3p7ZPVsHJVCxY+6TEme/kaae2nazEkAZ9J/jaZeufTeENTPv3GCrXnb7Y9C+dhuMQ5KyuWSH3PVbJJadOWKrMefrAYtiC/g4R65iJUHA2w3p43U7kuNC0+uZZ4bcBUZd5hqhguR/REfsSOoxSD5+glP6Z/K1ZA3OvpfDb5ESqk3aH8o0X/TAjOe2us+hnx00kjW5A1xbzIkVpu2ds9+t4bdCNINm6ouC8YNsam7Rb3xdvPW5zljIebBg7zY5lkjLE4N4Zloh4KysbELnccSL4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r7fjYt0zgVFRvqiVv0d9WrISFu5gZCDgMDhy3q2yeWk=; b=TvFDBI3TABGUS6s1ylCv8oy/tTKVhgxcHLdt3rT5f00eVowEZA5Ofxpx5NmzcO69ZtMUTsyXgXN6Joy/+GsBW7/K03UQwQ95dn/Hnt+jnEUmV6uqaUOg34CTqHPScbVj0MAe9eB0xXrPDL2LP96+StBpk1cxn+qiUMgwZjdm+MU= Received: from BL0PR00MB0772.namprd00.prod.outlook.com (52.135.46.88) by BL0PR00MB0387.namprd00.prod.outlook.com (52.132.20.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2745.0; Tue, 4 Feb 2020 18:20:45 +0000 Received: from BL0PR00MB0772.namprd00.prod.outlook.com ([fe80::a4ff:bc21:157a:4072]) by BL0PR00MB0772.namprd00.prod.outlook.com ([fe80::a4ff:bc21:157a:4072%6]) with mapi id 15.20.2744.000; Tue, 4 Feb 2020 18:20:45 +0000 From: Tommy Jensen To: "Deen, Glenn (NBCUniversal)" , Tommy Pauly , Adam Roach CC: Eric Rescorla , "add-chairs@ietf.org" , Paul Hoffman , ADD Mailing list , The IESG Thread-Topic: [Add] [EXTERNAL] Re: [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV24WYIP3lmx3oLEqH8zeXJJDqw6gLWG7t Date: Tue, 4 Feb 2020 18:20:45 +0000 Message-ID: References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> <9e1445a9-4030-706d-bee2-93905f470867@nostrum.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jensen.Thomas@microsoft.com; x-originating-ip: [167.220.58.20] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 43814fe0-857f-4c19-a27e-08d7a99ef3d5 x-ms-traffictypediagnostic: BL0PR00MB0387: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(396003)(376002)(366004)(39860400002)(136003)(189003)(199004)(2906002)(8990500004)(10290500003)(316002)(52536014)(478600001)(9686003)(55016002)(110136005)(54906003)(4326008)(33656002)(7696005)(5660300002)(66446008)(64756008)(66556008)(53546011)(86362001)(71200400001)(66946007)(76116006)(66476007)(8676002)(81166006)(8936002)(81156014)(186003)(26005)(6506007)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0387; H:BL0PR00MB0772.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +8Hi60ggiGgyKISQNBCpXrk8zAAxT+yP6CmU3fYtpNbvS8g2km4Xmr/sTVmEfvY0rLyy4SUCc13ewbUXoK4NOcUI9pG4Xg+cPfV71U4CtyOMpcAjTLwM0sfpgr6p4Ay3rHq8672U+Pjs8X4Wk5hwGNwmephFQNHvIksnpCw5Ht3U5gOUA4xSKyvFnc1+OhZimjB9WbGt8x0gQhlhKzmrjR8NAChHhW3xqeLoEU8dm5JSzaUGMp3gweyIN+reYs86skgVLB9Er1KaDZeVcrqWZq6blNtBfiLRH0aDH6/WQl0shI+v1anA470QVmibQOX2h89NfY01DVmv7Z07S148gl80qO79BYyY7oJMYmtirwgM+hv2xfhwI5auilZVzwpny3bFg8YY/owjHUkAMjorQCOJLQ19fpVKtLfVT5//PwgxNUn/1U6a4e+/Jhf0OGEv4kTqNd8iggLeEk78ZazLitGd74XmjfvJzIADDmFtmP2QPNRb4wm9BQPF7XFSuTL3E89ypgL62872Dtx51agqJA== x-ms-exchange-antispam-messagedata: bsM5KrjTymGKQP3NH8NAjjq9mFZBkVq35Qx6tap38/ovGGqHFJcMgU2di/MbKvxL2F2arXUl+dF3zUoyuH5fF3TbsTavNN5PnVreH5rI9F6b/+U1g6R8xHJ98+L9R2uoVxEYCr4FSDEASFuKilCg8Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0772E6A0078B955EF291F074FA030BL0PR00MB0772namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43814fe0-857f-4c19-a27e-08d7a99ef3d5 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 18:20:45.4526 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9vsu2VOIJ2xAZBysQU5uJRP0940XDOieNwjOXetTA+06IHDuGQzjfRLXeiNpYP8QUopqfiQTvtlsBtGnADtmdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0387 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 18:20:52 -0000 --_000_BL0PR00MB0772E6A0078B955EF291F074FA030BL0PR00MB0772namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEsIHRoZSBzcGlyaXQgb2Ygd2hhdCBJIHdhbnQgZnJvbSB0aGUgY2hhcnRlciBpcyBwcmVzZXJ2 ZWQuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBBZGQgPGFkZC1i b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGVlbiwgR2xlbm4gKE5CQ1VuaXZlcnNhbCkg PEdsZW5uLkRlZW5AbmJjdW5pLmNvbT4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDQsIDIwMjAg MTA6MDQgQU0NClRvOiBUb21teSBQYXVseSA8dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYu b3JnPjsgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT4NCkNjOiBFcmljIFJlc2NvcmxhIDxl a3JAcnRmbS5jb20+OyBEZWVuLCBHbGVubiAoTkJDVW5pdmVyc2FsKSA8R2xlbm4uRGVlbkBuYmN1 bmkuY29tPjsgYWRkLWNoYWlyc0BpZXRmLm9yZyA8YWRkLWNoYWlyc0BpZXRmLm9yZz47IFBhdWwg SG9mZm1hbiA8cGF1bC5ob2ZmbWFuQGljYW5uLm9yZz47IEFERCBNYWlsaW5nIGxpc3QgPGFkZEBp ZXRmLm9yZz47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtBZGRdIFtF WFRFUk5BTF0gUmU6IFtFeHRdIEFkYW0gUm9hY2gncyBObyBPYmplY3Rpb24gb24gY2hhcnRlci1p ZXRmLWFkZC0wMC0wMDogKHdpdGggQ09NTUVOVCkNCg0KDQoNCu+7v09uIDIvNC8yMCwgOTo1NiBB TSwgIkFkZCBvbiBiZWhhbGYgb2YgVG9tbXkgUGF1bHkiIDxhZGQtYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgdHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCg0K DQoNCiAgICA+IE9uIEZlYiA0LCAyMDIwLCBhdCA4OjQxIEFNLCBBZGFtIFJvYWNoIDxhZGFtQG5v c3RydW0uY29tPiB3cm90ZToNCiAgICA+DQogICAgPiBPbiAyLzQvMjAgMTA6MzcsIEVyaWMgUmVz Y29ybGEgd3JvdGU6DQogICAgPj4gSW4gdGhlIGludGVyZXN0IG9mIHRyeWluZyB0byBtb3ZlIGZv cndhcmQuLi4uDQogICAgPj4NCiAgICA+PiBJIGFncmVlIHRoYXQgdGhlcmUgYXJlIGEgYnVuY2gg b2YgdHJpY2t5IG5ldHdvcmsgc2NlbmFyaW9zIHRoYXQNCiAgICA+PiBuZWVkIHRvIGJlIGhhbmRs ZWQgKGNhcHRpdmUgcG9ydGFscywgVlBOcywgc3BsaXQgRE5TLCBldGMuKSBhbmQNCiAgICA+PiB0 aGF0IHByb3ZpZGluZyBzb21lIGd1aWRhbmNlIGhlcmUgd291bGQgYmUgdXNlZnVsLiBXaGF0IEkn bSB0cnlpbmcNCiAgICA+PiB0byBhdm9pZCBpcyB0aGF0IGJsZWVkaW5nIGludG8gYSBsb3Qgb2Yg ZGViYXRpbmcgYWJvdXQgcG9saWN5IGFuZA0KICAgID4+IGhvdyBwYXJ0aWN1bGFyIGNsaWVudHMg b3VnaHQgdG8gYmVoYXZlLiBXaXRoIHRoYXQgaW4gbWluZCwNCiAgICA+PiBoZXJlIGlzIHdoYXQg SSBzdWdnZXN0Og0KICAgID4+DQogICAgPj4gMS4gUmV2aXNlIHRoYXQgYnVsbGV0IHRvIGJlIG1v cmUgY2xlYXJseSB0ZWNobmljYWw6DQogICAgPj4NCiAgICA+PiAgICAtIGRldmVsb3AgYW4gaW5m b3JtYXRpb25hbCBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyBtZWNoYW5pc21zIGZvcg0KICAgID4+ ICAgIGNsaWVudHMgdG8gZGV0ZWN0IHNwZWNpZmljIG5ldHdvcmsgZW52aXJvbm1lbnRzIChjYXB0 aXZlIHBvcnRhbCwNCiAgICA+PiAgICBzcGxpdCBob3Jpem9uLCBldGMuKSBhbmQgdXNlIHRoYXQg dG8gaW5mb3JtIHRoZWlyIEROUw0KICAgID4+ICAgIGNvbmZpZ3VyYXRpb24uDQogICAgPj4NCiAg ICA+Pg0KICAgID4+IDIuIEFkZCBhIHNlbnRlbmNlIHRvIHRoZSBjaGFydGVyIGFmdGVyIHRoZSB3 b3JrIGl0ZW1zIHRoYXQgc2F5czoNCiAgICA+Pg0KICAgID4+ICAgICJUaGlzIHdvcmtpbmcgZ3Jv dXAgaXMgY2hhcnRlcmVkIHNvbGVseSB0byBkZXZlbG9wIHRlY2huaWNhbA0KICAgID4+ICAgIG1l Y2hhbmlzbXMuIE1ha2luZyBhbnkgcmVjb21tZW5kYXRpb25zIGFib3V0IHNwZWNpZmljIHBvbGlj aWVzDQogICAgPj4gICAgZm9yIGNsaWVudHMgYW5kIHNlcnZlcnMgaXMgb3V0IG9mIHNjb3BlLiIN CiAgICA+Pg0KICAgID4+DQogICAgPj4gSSB0aGluayB0aGlzIHdvdWxkIGdvIGEgbG9uZyB3YXkg dG93YXJkcyBjb250aW51aW5nIHRoZSBmb3Jtcw0KICAgID4+IG9mIHByb2R1Y3RpdmUgZW5nYWdl bWVudCB3ZSBoYXZlIGJlZW4gc2VlaW5nICh3aGljaCBJIGFncmVlDQogICAgPj4gdGhlcmUgaGF2 ZSBiZWVuKSB3aGlsZSBzY29waW5nIG91dCBjb250ZW50aW91cyBhbmQgdW5wcm9kdWN0aXZlDQog ICAgPj4gcG9saWN5IGRlYmF0ZXMuDQogICAgPg0KICAgID4NCiAgICA+IFRoYW5rcy4gVGhpcyBj cm9zc2VkIG9uIHRoZSB3aXJlIHdpdGggbXkgcHJldmlvdXMgbWVzc2FnZSwgYW5kIEkgdGhpbmsg aXQncyBhIGdvb2QgZXhhbXBsZSBvZiB0aGUga2luZHMgb2YgZ3VpZGVyYWlscyBJIHdhcyBjYWxs aW5nIGZvci4NCg0KICAgICsxDQoNCiAgICBJIHRoaW5rIGJvdGggb2YgdGhlc2UgdGV4dHVhbCBj aGFuZ2VzIGFyZSBhcHByb3ByaWF0ZSwgYW5kIGNsYXJpZnkgdGhlIGludGVudCBvZiB0aGUgY2hh cnRlciwgd2l0aG91dCB1bmR1bHkgY29uc3RyYWluaW5nIHRoZSB0ZWNobmljYWwgd29yayBvZiBh IGdyb3VwLiBJIHN1cHBvcnQgcGVyZm9ybWluZyBib3RoIG9mIHRoZXNlIGNoYW5nZXMhDQoNCiAg ICBUaGFua3MgZWtyIGZvciB0aGUgc3VnZ2VzdGlvbnMuDQoNCiAgICBCZXN0LA0KICAgIFRvbW15 DQoNCisxDQoNCkkgYWxzbyBkb24ndCBoYXZlIGFueSBoZWFydGJ1cm4gd2l0aCBlaXRoZXIgb2Yg dGhlIHN1Z2dlc3RlZCBjaGFuZ2VzLiBUaGV5IGNsYXJpZnkgdGhlIG1pc3Npb24gd2hpbGUga2Vl cGluZyB0aGUgY2hhcnRlciBjbGVhbiBlbm91Z2ggdGhhdCBpdCdzIHNpbXBsZSB0byByZWFkIGFu ZCB1bmRlcnN0YW5kLg0KDQotZ2xlbm4NCg0KICAgIC0tDQogICAgQWRkIG1haWxpbmcgbGlzdA0K ICAgIEFkZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZs aXN0aW5mbyUyRmFkZCZhbXA7ZGF0YT0wMiU3QzAxJTdDSmVuc2VuLlRob21hcyU0MG1pY3Jvc29m dC5jb20lN0M0NDIzZWQ1ZWJlNTc0NjcxODE4NjA4ZDdhOTljYjY4MiU3QzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNjQzNjI4OTQwNDM3ODgmYW1wO3NkYXRh PTBEc0xpSyUyRmdPRHVWQk9CTXYxOTVoRmxHemwxQU9rYXd2UWszZVJMJTJGU0IwJTNEJmFtcDty ZXNlcnZlZD0wDQoNCg0KLS0NCkFkZCBtYWlsaW5nIGxpc3QNCkFkZEBpZXRmLm9yZw0KaHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGYWRkJmFtcDtkYXRhPTAyJTdD MDElN0NKZW5zZW4uVGhvbWFzJTQwbWljcm9zb2Z0LmNvbSU3QzQ0MjNlZDVlYmU1NzQ2NzE4MTg2 MDhkN2E5OWNiNjgyJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNzE2NDM2Mjg5NDA0Mzc4OCZhbXA7c2RhdGE9MERzTGlLJTJGZ09EdVZCT0JNdjE5NWhGbEd6 bDFBT2thd3ZRazNlUkwlMkZTQjAlM0QmYW1wO3Jlc2VydmVkPTANCg== --_000_BL0PR00MB0772E6A0078B955EF291F074FA030BL0PR00MB0772namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4mIzQzOzEs IHRoZSBzcGlyaXQgb2Ygd2hhdCBJIHdhbnQgZnJvbSB0aGUgY2hhcnRlciBpcyBwcmVzZXJ2ZWQu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGhyIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9j azt3aWR0aDo5OCUiIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9 Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc3R5bGU9ImZvbnQtc2l6ZTox MXB0IiBjb2xvcj0iIzAwMDAwMCI+PGI+RnJvbTo8L2I+IEFkZCAmbHQ7YWRkLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBEZWVuLCBHbGVubiAoTkJDVW5pdmVyc2FsKSAmbHQ7R2xl bm4uRGVlbkBuYmN1bmkuY29tJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFy eSA0LCAyMDIwIDEwOjA0IEFNPGJyPg0KPGI+VG86PC9iPiBUb21teSBQYXVseSAmbHQ7dHBhdWx5 PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnJmd0OzsgQWRhbSBSb2FjaCAmbHQ7YWRhbUBub3N0 cnVtLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNv bSZndDs7IERlZW4sIEdsZW5uIChOQkNVbml2ZXJzYWwpICZsdDtHbGVubi5EZWVuQG5iY3VuaS5j b20mZ3Q7OyBhZGQtY2hhaXJzQGlldGYub3JnICZsdDthZGQtY2hhaXJzQGlldGYub3JnJmd0Ozsg UGF1bCBIb2ZmbWFuICZsdDtwYXVsLmhvZmZtYW5AaWNhbm4ub3JnJmd0OzsgQUREIE1haWxpbmcg bGlzdCAmbHQ7YWRkQGlldGYub3JnJmd0OzsgVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQWRkXSBbRVhURVJOQUxdIFJlOiBbRXh0XSBBZGFt IFJvYWNoJ3MgTm8gT2JqZWN0aW9uIG9uIGNoYXJ0ZXItaWV0Zi1hZGQtMDAtMDA6ICh3aXRoIENP TU1FTlQpPC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iQm9k eUZyYWdtZW50Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4N CjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+PGJyPg0KPGJyPg0K77u/T24gMi80LzIwLCA5OjU2IEFN LCAmcXVvdDtBZGQgb24gYmVoYWxmIG9mIFRvbW15IFBhdWx5JnF1b3Q7ICZsdDthZGQtYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgdHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3Jn Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IE9uIEZlYiA0LCAyMDIwLCBh dCA4OjQxIEFNLCBBZGFtIFJvYWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0OyB3cm90ZTo8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBP biAyLzQvMjAgMTA6MzcsIEVyaWMgUmVzY29ybGEgd3JvdGU6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7IEluIHRoZSBpbnRlcmVzdCBvZiB0cnlpbmcgdG8gbW92ZSBmb3J3YXJkLi4u Ljxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsgSSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBhIGJ1bmNoIG9mIHRyaWNreSBuZXR3 b3JrIHNjZW5hcmlvcyB0aGF0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IG5lZWQg dG8gYmUgaGFuZGxlZCAoY2FwdGl2ZSBwb3J0YWxzLCBWUE5zLCBzcGxpdCBETlMsIGV0Yy4pIGFu ZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyB0aGF0IHByb3ZpZGluZyBzb21lIGd1 aWRhbmNlIGhlcmUgd291bGQgYmUgdXNlZnVsLiBXaGF0IEknbSB0cnlpbmc8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsgdG8gYXZvaWQgaXMgdGhhdCBibGVlZGluZyBpbnRvIGEgbG90 IG9mIGRlYmF0aW5nIGFib3V0IHBvbGljeSBhbmQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsgaG93IHBhcnRpY3VsYXIgY2xpZW50cyBvdWdodCB0byBiZWhhdmUuIFdpdGggdGhhdCBp biBtaW5kLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBoZXJlIGlzIHdoYXQgSSBz dWdnZXN0Ojxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsgMS4gUmV2aXNlIHRoYXQgYnVsbGV0IHRvIGJlIG1vcmUgY2xlYXJs eSB0ZWNobmljYWw6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAtIGRldmVsb3AgYW4gaW5m b3JtYXRpb25hbCBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyBtZWNoYW5pc21zIGZvcjxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBjbGllbnRzIHRvIGRl dGVjdCBzcGVjaWZpYyBuZXR3b3JrIGVudmlyb25tZW50cyAoY2FwdGl2ZSBwb3J0YWwsPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwbGl0IGhvcml6 b24sIGV0Yy4pIGFuZCB1c2UgdGhhdCB0byBpbmZvcm0gdGhlaXIgRE5TPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24uPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgMi4gQWRkIGEgc2VudGVuY2Ug dG8gdGhlIGNoYXJ0ZXIgYWZ0ZXIgdGhlIHdvcmsgaXRlbXMgdGhhdCBzYXlzOjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhpcyB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0ZXJlZCBz b2xlbHkgdG8gZGV2ZWxvcCB0ZWNobmljYWw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgbWVjaGFuaXNtcy4gTWFraW5nIGFueSByZWNvbW1lbmRhdGlv bnMgYWJvdXQgc3BlY2lmaWMgcG9saWNpZXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9yIGNsaWVudHMgYW5kIHNlcnZlcnMgaXMgb3V0IG9mIHNj b3BlLiZxdW90Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IEkg dGhpbmsgdGhpcyB3b3VsZCBnbyBhIGxvbmcgd2F5IHRvd2FyZHMgY29udGludWluZyB0aGUgZm9y bXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgb2YgcHJvZHVjdGl2ZSBlbmdhZ2Vt ZW50IHdlIGhhdmUgYmVlbiBzZWVpbmcgKHdoaWNoIEkgYWdyZWU8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsgdGhlcmUgaGF2ZSBiZWVuKSB3aGlsZSBzY29waW5nIG91dCBjb250ZW50 aW91cyBhbmQgdW5wcm9kdWN0aXZlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IHBv bGljeSBkZWJhdGVzLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFRoYW5rcy4gVGhp cyBjcm9zc2VkIG9uIHRoZSB3aXJlIHdpdGggbXkgcHJldmlvdXMgbWVzc2FnZSwgYW5kIEkgdGhp bmsgaXQncyBhIGdvb2QgZXhhbXBsZSBvZiB0aGUga2luZHMgb2YgZ3VpZGVyYWlscyBJIHdhcyBj YWxsaW5nIGZvci48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7MTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgSSB0aGluayBib3RoIG9mIHRoZXNlIHRleHR1YWwgY2hhbmdlcyBhcmUgYXBwcm9wcmlhdGUs IGFuZCBjbGFyaWZ5IHRoZSBpbnRlbnQgb2YgdGhlIGNoYXJ0ZXIsIHdpdGhvdXQgdW5kdWx5IGNv bnN0cmFpbmluZyB0aGUgdGVjaG5pY2FsIHdvcmsgb2YgYSBncm91cC4gSSBzdXBwb3J0IHBlcmZv cm1pbmcgYm90aCBvZiB0aGVzZSBjaGFuZ2VzITxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzIGVrciBmb3IgdGhlIHN1Z2dlc3Rpb25zLjxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgQmVzdCw8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgVG9tbXk8YnI+DQo8YnI+DQomIzQzOzE8YnI+DQo8YnI+DQpJIGFs c28gZG9uJ3QgaGF2ZSBhbnkgaGVhcnRidXJuIHdpdGggZWl0aGVyIG9mIHRoZSBzdWdnZXN0ZWQg Y2hhbmdlcy4gVGhleSBjbGFyaWZ5IHRoZSBtaXNzaW9uIHdoaWxlIGtlZXBpbmcgdGhlIGNoYXJ0 ZXIgY2xlYW4gZW5vdWdoIHRoYXQgaXQncyBzaW1wbGUgdG8gcmVhZCBhbmQgdW5kZXJzdGFuZC48 YnI+DQo8YnI+DQotZ2xlbm48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgLS0gPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFkZCBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgQWRkQGlldGYub3JnPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8v bmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy Rnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmFkZCZhbXA7YW1wO2RhdGE9MDIl N0MwMSU3Q0plbnNlbi5UaG9tYXMlNDBtaWNyb3NvZnQuY29tJTdDNDQyM2VkNWViZTU3NDY3MTgx ODYwOGQ3YTk5Y2I2ODIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM3MTY0MzYyODk0MDQzNzg4JmFtcDthbXA7c2RhdGE9MERzTGlLJTJGZ09EdVZCT0JNdjE5 NWhGbEd6bDFBT2thd3ZRazNlUkwlMkZTQjAlM0QmYW1wO2FtcDtyZXNlcnZlZD0wIj4NCmh0dHBz Oi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmFkZCZhbXA7YW1wO2RhdGE9 MDIlN0MwMSU3Q0plbnNlbi5UaG9tYXMlNDBtaWNyb3NvZnQuY29tJTdDNDQyM2VkNWViZTU3NDY3 MTgxODYwOGQ3YTk5Y2I2ODIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM3MTY0MzYyODk0MDQzNzg4JmFtcDthbXA7c2RhdGE9MERzTGlLJTJGZ09EdVZCT0JN djE5NWhGbEd6bDFBT2thd3ZRazNlUkwlMkZTQjAlM0QmYW1wO2FtcDtyZXNlcnZlZD0wPC9hPg0K PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCjxicj4NCi0tIDxicj4NCkFkZCBtYWlsaW5n IGxpc3Q8YnI+DQpBZGRAaWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5v cmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZhZGQmYW1wO2FtcDtkYXRhPTAyJTdDMDElN0NKZW5z ZW4uVGhvbWFzJTQwbWljcm9zb2Z0LmNvbSU3QzQ0MjNlZDVlYmU1NzQ2NzE4MTg2MDhkN2E5OWNi NjgyJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE2NDM2 Mjg5NDA0Mzc4OCZhbXA7YW1wO3NkYXRhPTBEc0xpSyUyRmdPRHVWQk9CTXYxOTVoRmxHemwxQU9r YXd2UWszZVJMJTJGU0IwJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly9uYW0wNi5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGYWRkJmFtcDthbXA7ZGF0YT0wMiU3QzAxJTdDSmVu c2VuLlRob21hcyU0MG1pY3Jvc29mdC5jb20lN0M0NDIzZWQ1ZWJlNTc0NjcxODE4NjA4ZDdhOTlj YjY4MiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNjQz NjI4OTQwNDM3ODgmYW1wO2FtcDtzZGF0YT0wRHNMaUslMkZnT0R1VkJPQk12MTk1aEZsR3psMUFP a2F3dlFrM2VSTCUyRlNCMCUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8L2E+PGJyPg0KPC9kaXY+DQo8 L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL0PR00MB0772E6A0078B955EF291F074FA030BL0PR00MB0772namp_-- From nobody Tue Feb 4 10:25:25 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0D2120850; Tue, 4 Feb 2020 10:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no1r1ihq-iiB; Tue, 4 Feb 2020 10:25:21 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100082.outbound.protection.outlook.com [40.107.10.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70467120849; Tue, 4 Feb 2020 10:25:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hcPvyfMWywlqT3dPTlIe1luLz9N+1N/s2cEyhElaRepLDsaS1vMOdwUw3fuHwuCmZCsiU6bjRcSC9n/hqhF+7c4yjTM5lgWjtZi0CYgvvNWz1RicvgdfgQacdOzSY9CkhUb+aVa8YBNpWxMBtvCNylAMEWBxYe6haJdTr45QyL7PKsOpc4vyGsINka33mZb4+B/7+tz5cjC/UYlsnE/Vl8Z/5MzE16pauyvQI/mQPzr13bF+Du9f1ytjjuL09lVELlA2FtbVHaPSbUi1My+73GAaWPTyrHQLyWv33OLoFiTi3MKdZzEMJVYycgX3GAqFO22z80SNmU1az0ollF9bwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gvs50T3Dc5wytOTrofdOqTzALvOKPVGJwYj97wpa4bw=; b=dS2jqlVXi11Lhm1UgW49LBv0E6I0vUlCD+2UrFqh2h/7Lp2l3k1sSeZ+boekzrDa0GAgMIWpOkmCxXTxZXAS808kp7W5wBIFzef6EdkH5uvs75vAytvQK/K/MVJI3p8ap8CLpdEfTHBytRdd6sswoOxs4lKrlepTgWHeq1P4aoIOPlZzo/gsgV4SRx9gUkL1raELjcC+rdFQMnP/GTgehRT90yoLRRHpd5g9R5Nj7rP4x9LbVLyEck/KB6nn7flBs26sG7tm3Lfu0xe1KOEuAXKCl5jjBSQ3QIogp9CeAPn7iCGb2dbz5NzROl5Pr+njNaTVU2KnWVsLmK9021xn9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gvs50T3Dc5wytOTrofdOqTzALvOKPVGJwYj97wpa4bw=; b=Ab1e3z8Avn5hzHK8p6timZQMJEcSwuG0yG8hcdtlMyu4yKyT7UJhlRYdw488FM+sb//3fRGOd3aBhPp9V8NMWzFCf6+SBEBRqYZjS4tMOQmo9Nz36Be4pMgYgfkpqt/awitMpQajv6v5se8CTDe7tlFjUVe+0+lzCanjvAOAoAg= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB0798.GBRP265.PROD.OUTLOOK.COM (10.166.105.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.33; Tue, 4 Feb 2020 18:24:58 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af%5]) with mapi id 15.20.2686.034; Tue, 4 Feb 2020 18:24:58 +0000 From: Andrew Campling To: Tommy Jensen , "Deen, Glenn (NBCUniversal)" , Tommy Pauly , Adam Roach CC: Eric Rescorla , "add-chairs@ietf.org" , Paul Hoffman , ADD Mailing list , The IESG Thread-Topic: [Add] [EXTERNAL] Re: [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV24fcXY8m9WHYkkGr4jB2d+LVu6gLWRTA Date: Tue, 4 Feb 2020 18:24:58 +0000 Message-ID: References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> <9e1445a9-4030-706d-bee2-93905f470867@nostrum.com> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [109.152.16.200] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 648a9e98-12e6-4b5b-1425-08d7a99f8a50 x-ms-traffictypediagnostic: LO2P265MB0798: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(366004)(396003)(346002)(376002)(136003)(199004)(189003)(316002)(45080400002)(2906002)(26005)(110136005)(54906003)(53546011)(7696005)(6506007)(76116006)(186003)(4326008)(508600001)(71200400001)(64756008)(66946007)(66556008)(66476007)(66446008)(9686003)(966005)(52536014)(55016002)(33656002)(8676002)(44832011)(8936002)(86362001)(5660300002)(81166006)(81156014)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB0798; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 450KgkReqtVGyD82ctBT5yMhG7DpUOnM6vnZrY1ktAMqHawTjRUAaFZy3xnyzttnhmSz3oQf9eMcIDKkmElwHAqvaGuUWTxFeD1HNenn+as42WJXgk1XJpdog1265sWOYsoZSmLGW+OF5uGhQKF3c6kbVvI4W1DV4+y/R4hvESmA7TFNZjg8xQ/Vyt//pE0PGEP26gK8SuLCcTZojbtpnxdPPLWS8+mYoPK8+8E07QeQmmIXa6PowogS9edfhrlULj0HsYepJct8OWgPx0QtjSbsUzt+NjF2Emyq556EercdbQK4ZfTaxjBnJ1DhD7ipCs7hPXxZy2wFhFe2rcFs248oM0ANdTjR/bzts9GgHtVIFpiWQfqGyW+l8EOpa8H5RkI4MsU0bX7fnr+PFe+xdYRvk0OIlGhFbtVj8MAOBCLWx2gqiI/Z64iTyFL3KtKkl9y6gbI4Ce+bHn+P1WJp7iUljFLZawsszgio9VG3pqJr17fL3jIKlJ7sQITcUi1IF0PcOIiFQjwAdsscDSasGWuKJNj5+lVr8ttTkYUJcFmft1Cj5mFCoxnsfNZIC8Yw x-ms-exchange-antispam-messagedata: Aii4HPp0SSTNUiY+XRwcrXWWLxVB8GE6PnM/ZYIVkYgfiQDs0qgGqDr2vNp13jxeX/sJeKjh6nAoM2cmWPaXG0lomu/HvRcAp9Eo07NvFV9YLUeXBTN6JhYrTV42HlLGMm3TJJgswiGliq4g9Q83PA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB05730676E4BBF2B65F658E2DC2030LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 648a9e98-12e6-4b5b-1425-08d7a99f8a50 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 18:24:58.0543 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +e/2Bf+G91dFO/tx+6M2iuvMNtH3EGlbaA43N4yqNTFyo3ifpOQ/lzi2GBX3aJLZKKpoTA6OiJmPZ7/dW6Dgnwit1BML6za0MmZ3Y+93IeU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0798 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 18:25:23 -0000 --_000_LO2P265MB05730676E4BBF2B65F658E2DC2030LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5vdGhlciArMSDigJMgYSBoZWxwZnVsIGNoYW5nZSBpZiB0aGlzIHByb3ZpZGVzIHJlYXNzdXJh bmNlIHRoYXQgdGhlcmUgaXMgbm8gaW50ZW5kZWQgbWlzc2lvbiBjcmVlcCBhbmQgcHJvdmlkZXMg dGhlIGJhc2lzIGZvciB0aGUgd29ya2luZyBncm91cCBjaGFydGVyaW5nIHByb2Nlc3MgdG8gbW92 ZSBmb3J3YXJkLg0KDQpBbmRyZXcNCg0KRnJvbTogVG9tbXkgSmVuc2VuIDxKZW5zZW4uVGhvbWFz QG1pY3Jvc29mdC5jb20+DQpTZW50OiAwNCBGZWJydWFyeSAyMDIwIDE4OjIxDQpUbzogRGVlbiwg R2xlbm4gKE5CQ1VuaXZlcnNhbCkgPEdsZW5uLkRlZW5AbmJjdW5pLmNvbT47IFRvbW15IFBhdWx5 IDx0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc+OyBBZGFtIFJvYWNoIDxhZGFtQG5v c3RydW0uY29tPg0KQ2M6IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT47IGFkZC1jaGFpcnNA aWV0Zi5vcmc7IFBhdWwgSG9mZm1hbiA8cGF1bC5ob2ZmbWFuQGljYW5uLm9yZz47IEFERCBNYWls aW5nIGxpc3QgPGFkZEBpZXRmLm9yZz47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtBZGRdIFtFWFRFUk5BTF0gUmU6IFtFeHRdIEFkYW0gUm9hY2gncyBObyBPYmplY3Rp b24gb24gY2hhcnRlci1pZXRmLWFkZC0wMC0wMDogKHdpdGggQ09NTUVOVCkNCg0KKzEsIHRoZSBz cGlyaXQgb2Ygd2hhdCBJIHdhbnQgZnJvbSB0aGUgY2hhcnRlciBpcyBwcmVzZXJ2ZWQuDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBBZGQgPGFkZC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzphZGQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBEZWVuLCBH bGVubiAoTkJDVW5pdmVyc2FsKSA8R2xlbm4uRGVlbkBuYmN1bmkuY29tPG1haWx0bzpHbGVubi5E ZWVuQG5iY3VuaS5jb20+Pg0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgNCwgMjAyMCAxMDowNCBB TQ0KVG86IFRvbW15IFBhdWx5IDx0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOnRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZz4+OyBBZGFtIFJvYWNoIDxhZGFt QG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0uY29tPj4NCkNjOiBFcmljIFJlc2Nvcmxh IDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+OyBEZWVuLCBHbGVubiAoTkJDVW5p dmVyc2FsKSA8R2xlbm4uRGVlbkBuYmN1bmkuY29tPG1haWx0bzpHbGVubi5EZWVuQG5iY3VuaS5j b20+PjsgYWRkLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86YWRkLWNoYWlyc0BpZXRmLm9yZz4gPGFk ZC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmFkZC1jaGFpcnNAaWV0Zi5vcmc+PjsgUGF1bCBIb2Zm bWFuIDxwYXVsLmhvZmZtYW5AaWNhbm4ub3JnPG1haWx0bzpwYXVsLmhvZmZtYW5AaWNhbm4ub3Jn Pj47IEFERCBNYWlsaW5nIGxpc3QgPGFkZEBpZXRmLm9yZzxtYWlsdG86YWRkQGlldGYub3JnPj47 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPj4NClN1YmplY3Q6 IFJlOiBbQWRkXSBbRVhURVJOQUxdIFJlOiBbRXh0XSBBZGFtIFJvYWNoJ3MgTm8gT2JqZWN0aW9u IG9uIGNoYXJ0ZXItaWV0Zi1hZGQtMDAtMDA6ICh3aXRoIENPTU1FTlQpDQoNCg0KDQrvu79PbiAy LzQvMjAsIDk6NTYgQU0sICJBZGQgb24gYmVoYWxmIG9mIFRvbW15IFBhdWx5IiA8YWRkLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9y ZzxtYWlsdG86YWRkLWJvdW5jZXNAaWV0Zi5vcmclMjBvbiUyMGJlaGFsZiUyMG9mJTIwdHBhdWx5 PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCg0KDQogICAgPiBPbiBGZWIg NCwgMjAyMCwgYXQgODo0MSBBTSwgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86 YWRhbUBub3N0cnVtLmNvbT4+IHdyb3RlOg0KICAgID4NCiAgICA+IE9uIDIvNC8yMCAxMDozNywg RXJpYyBSZXNjb3JsYSB3cm90ZToNCiAgICA+PiBJbiB0aGUgaW50ZXJlc3Qgb2YgdHJ5aW5nIHRv IG1vdmUgZm9yd2FyZC4uLi4NCiAgICA+Pg0KICAgID4+IEkgYWdyZWUgdGhhdCB0aGVyZSBhcmUg YSBidW5jaCBvZiB0cmlja3kgbmV0d29yayBzY2VuYXJpb3MgdGhhdA0KICAgID4+IG5lZWQgdG8g YmUgaGFuZGxlZCAoY2FwdGl2ZSBwb3J0YWxzLCBWUE5zLCBzcGxpdCBETlMsIGV0Yy4pIGFuZA0K ICAgID4+IHRoYXQgcHJvdmlkaW5nIHNvbWUgZ3VpZGFuY2UgaGVyZSB3b3VsZCBiZSB1c2VmdWwu IFdoYXQgSSdtIHRyeWluZw0KICAgID4+IHRvIGF2b2lkIGlzIHRoYXQgYmxlZWRpbmcgaW50byBh IGxvdCBvZiBkZWJhdGluZyBhYm91dCBwb2xpY3kgYW5kDQogICAgPj4gaG93IHBhcnRpY3VsYXIg Y2xpZW50cyBvdWdodCB0byBiZWhhdmUuIFdpdGggdGhhdCBpbiBtaW5kLA0KICAgID4+IGhlcmUg aXMgd2hhdCBJIHN1Z2dlc3Q6DQogICAgPj4NCiAgICA+PiAxLiBSZXZpc2UgdGhhdCBidWxsZXQg dG8gYmUgbW9yZSBjbGVhcmx5IHRlY2huaWNhbDoNCiAgICA+Pg0KICAgID4+ICAgIC0gZGV2ZWxv cCBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIG1lY2hhbmlzbXMgZm9y DQogICAgPj4gICAgY2xpZW50cyB0byBkZXRlY3Qgc3BlY2lmaWMgbmV0d29yayBlbnZpcm9ubWVu dHMgKGNhcHRpdmUgcG9ydGFsLA0KICAgID4+ICAgIHNwbGl0IGhvcml6b24sIGV0Yy4pIGFuZCB1 c2UgdGhhdCB0byBpbmZvcm0gdGhlaXIgRE5TDQogICAgPj4gICAgY29uZmlndXJhdGlvbi4NCiAg ICA+Pg0KICAgID4+DQogICAgPj4gMi4gQWRkIGEgc2VudGVuY2UgdG8gdGhlIGNoYXJ0ZXIgYWZ0 ZXIgdGhlIHdvcmsgaXRlbXMgdGhhdCBzYXlzOg0KICAgID4+DQogICAgPj4gICAgIlRoaXMgd29y a2luZyBncm91cCBpcyBjaGFydGVyZWQgc29sZWx5IHRvIGRldmVsb3AgdGVjaG5pY2FsDQogICAg Pj4gICAgbWVjaGFuaXNtcy4gTWFraW5nIGFueSByZWNvbW1lbmRhdGlvbnMgYWJvdXQgc3BlY2lm aWMgcG9saWNpZXMNCiAgICA+PiAgICBmb3IgY2xpZW50cyBhbmQgc2VydmVycyBpcyBvdXQgb2Yg c2NvcGUuIg0KICAgID4+DQogICAgPj4NCiAgICA+PiBJIHRoaW5rIHRoaXMgd291bGQgZ28gYSBs b25nIHdheSB0b3dhcmRzIGNvbnRpbnVpbmcgdGhlIGZvcm1zDQogICAgPj4gb2YgcHJvZHVjdGl2 ZSBlbmdhZ2VtZW50IHdlIGhhdmUgYmVlbiBzZWVpbmcgKHdoaWNoIEkgYWdyZWUNCiAgICA+PiB0 aGVyZSBoYXZlIGJlZW4pIHdoaWxlIHNjb3Bpbmcgb3V0IGNvbnRlbnRpb3VzIGFuZCB1bnByb2R1 Y3RpdmUNCiAgICA+PiBwb2xpY3kgZGViYXRlcy4NCiAgICA+DQogICAgPg0KICAgID4gVGhhbmtz LiBUaGlzIGNyb3NzZWQgb24gdGhlIHdpcmUgd2l0aCBteSBwcmV2aW91cyBtZXNzYWdlLCBhbmQg SSB0aGluayBpdCdzIGEgZ29vZCBleGFtcGxlIG9mIHRoZSBraW5kcyBvZiBndWlkZXJhaWxzIEkg d2FzIGNhbGxpbmcgZm9yLg0KDQogICAgKzENCg0KICAgIEkgdGhpbmsgYm90aCBvZiB0aGVzZSB0 ZXh0dWFsIGNoYW5nZXMgYXJlIGFwcHJvcHJpYXRlLCBhbmQgY2xhcmlmeSB0aGUgaW50ZW50IG9m IHRoZSBjaGFydGVyLCB3aXRob3V0IHVuZHVseSBjb25zdHJhaW5pbmcgdGhlIHRlY2huaWNhbCB3 b3JrIG9mIGEgZ3JvdXAuIEkgc3VwcG9ydCBwZXJmb3JtaW5nIGJvdGggb2YgdGhlc2UgY2hhbmdl cyENCg0KICAgIFRoYW5rcyBla3IgZm9yIHRoZSBzdWdnZXN0aW9ucy4NCg0KICAgIEJlc3QsDQog ICAgVG9tbXkNCg0KKzENCg0KSSBhbHNvIGRvbid0IGhhdmUgYW55IGhlYXJ0YnVybiB3aXRoIGVp dGhlciBvZiB0aGUgc3VnZ2VzdGVkIGNoYW5nZXMuIFRoZXkgY2xhcmlmeSB0aGUgbWlzc2lvbiB3 aGlsZSBrZWVwaW5nIHRoZSBjaGFydGVyIGNsZWFuIGVub3VnaCB0aGF0IGl0J3Mgc2ltcGxlIHRv IHJlYWQgYW5kIHVuZGVyc3RhbmQuDQoNCi1nbGVubg0KDQogICAgLS0NCiAgICBBZGQgbWFpbGlu ZyBsaXN0DQogICAgQWRkQGlldGYub3JnPG1haWx0bzpBZGRAaWV0Zi5vcmc+DQogICAgaHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGYWRkJmFtcDtkYXRhPTAyJTdD MDElN0NKZW5zZW4uVGhvbWFzJTQwbWljcm9zb2Z0LmNvbSU3QzQ0MjNlZDVlYmU1NzQ2NzE4MTg2 MDhkN2E5OWNiNjgyJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNzE2NDM2Mjg5NDA0Mzc4OCZhbXA7c2RhdGE9MERzTGlLJTJGZ09EdVZCT0JNdjE5NWhGbEd6 bDFBT2thd3ZRazNlUkwlMkZTQjAlM0QmYW1wO3Jlc2VydmVkPTANCg0KDQotLQ0KQWRkIG1haWxp bmcgbGlzdA0KQWRkQGlldGYub3JnPG1haWx0bzpBZGRAaWV0Zi5vcmc+DQpodHRwczovL25hbTA2 LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cu aWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZhZGQmYW1wO2RhdGE9MDIlN0MwMSU3Q0pl bnNlbi5UaG9tYXMlNDBtaWNyb3NvZnQuY29tJTdDNDQyM2VkNWViZTU3NDY3MTgxODYwOGQ3YTk5 Y2I2ODIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTY0 MzYyODk0MDQzNzg4JmFtcDtzZGF0YT0wRHNMaUslMkZnT0R1VkJPQk12MTk1aEZsR3psMUFPa2F3 dlFrM2VSTCUyRlNCMCUzRCZhbXA7cmVzZXJ2ZWQ9MA0K --_000_LO2P265MB05730676E4BBF2B65F658E2DC2030LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+QW5vdGhlciAmIzQzOzEg4oCTIGEgaGVscGZ1bCBjaGFuZ2UgaWYgdGhpcyBw cm92aWRlcyByZWFzc3VyYW5jZSB0aGF0IHRoZXJlIGlzIG5vIGludGVuZGVkIG1pc3Npb24gY3Jl ZXAgYW5kIHByb3ZpZGVzIHRoZSBiYXNpcyBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgY2hhcnRlcmlu ZyBwcm9jZXNzIHRvIG1vdmUgZm9yd2FyZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5BbmRyZXcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBUb21teSBK ZW5zZW4gJmx0O0plbnNlbi5UaG9tYXNAbWljcm9zb2Z0LmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6 PC9iPiAwNCBGZWJydWFyeSAyMDIwIDE4OjIxPGJyPg0KPGI+VG86PC9iPiBEZWVuLCBHbGVubiAo TkJDVW5pdmVyc2FsKSAmbHQ7R2xlbm4uRGVlbkBuYmN1bmkuY29tJmd0OzsgVG9tbXkgUGF1bHkg Jmx0O3RwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs7IEFkYW0gUm9hY2ggJmx0 O2FkYW1Abm9zdHJ1bS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBFcmljIFJlc2NvcmxhICZsdDtl a3JAcnRmbS5jb20mZ3Q7OyBhZGQtY2hhaXJzQGlldGYub3JnOyBQYXVsIEhvZmZtYW4gJmx0O3Bh dWwuaG9mZm1hbkBpY2Fubi5vcmcmZ3Q7OyBBREQgTWFpbGluZyBsaXN0ICZsdDthZGRAaWV0Zi5v cmcmZ3Q7OyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtBZGRdIFtFWFRFUk5BTF0gUmU6IFtFeHRdIEFkYW0gUm9hY2gncyBObyBPYmplY3Rp b24gb24gY2hhcnRlci1pZXRmLWFkZC0wMC0wMDogKHdpdGggQ09NTUVOVCk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxLCB0aGUgc3Bp cml0IG9mIHdoYXQgSSB3YW50IGZyb20gdGhlIGNoYXJ0ZXIgaXMgcHJlc2VydmVkLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIg c3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGln bj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiBBZGQgJmx0OzxhIGhyZWY9Im1haWx0bzphZGQtYm91 bmNlc0BpZXRmLm9yZyI+YWRkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg RGVlbiwgR2xlbm4gKE5CQ1VuaXZlcnNhbCkgJmx0OzxhIGhyZWY9Im1haWx0bzpHbGVubi5EZWVu QG5iY3VuaS5jb20iPkdsZW5uLkRlZW5AbmJjdW5pLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDQsIDIwMjAgMTA6MDQgQU08YnI+DQo8Yj5Ubzo8L2I+IFRv bW15IFBhdWx5ICZsdDs8YSBocmVmPSJtYWlsdG86dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmll dGYub3JnIj50cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzsgQWRhbSBS b2FjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPmFkYW1Abm9zdHJ1bS5j b208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDs7IERlZW4sIEdsZW5uIChOQkNV bml2ZXJzYWwpICZsdDs8YSBocmVmPSJtYWlsdG86R2xlbm4uRGVlbkBuYmN1bmkuY29tIj5HbGVu bi5EZWVuQG5iY3VuaS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzphZGQtY2hhaXJzQGll dGYub3JnIj5hZGQtY2hhaXJzQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkZC1j aGFpcnNAaWV0Zi5vcmciPmFkZC1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OzsgUGF1bCBIb2ZmbWFu ICZsdDs8YSBocmVmPSJtYWlsdG86cGF1bC5ob2ZmbWFuQGljYW5uLm9yZyI+cGF1bC5ob2ZmbWFu QGljYW5uLm9yZzwvYT4mZ3Q7OyBBREQgTWFpbGluZyBsaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86 YWRkQGlldGYub3JnIj5hZGRAaWV0Zi5vcmc8L2E+Jmd0OzsNCiBUaGUgSUVTRyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW0FkZF0gW0VYVEVSTkFMXSBSZTogW0V4dF0gQWRhbSBSb2FjaCdzIE5v IE9iamVjdGlvbiBvbiBjaGFydGVyLWlldGYtYWRkLTAwLTAwOiAod2l0aCBDT01NRU5UKTwvc3Bh bj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0K77u/T24gMi80LzIwLCA5OjU2IEFNLCAmcXVvdDtBZGQgb24g YmVoYWxmIG9mIFRvbW15IFBhdWx5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWRkLWJvdW5j ZXNAaWV0Zi5vcmclMjBvbiUyMGJlaGFsZiUyMG9mJTIwdHBhdWx5PTQwYXBwbGUuY29tQGRtYXJj LmlldGYub3JnIj5hZGQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgdHBhdWx5PTQwYXBw bGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBPbiBGZWIgNCwgMjAyMCwgYXQgODo0MSBBTSwgQWRhbSBSb2FjaCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPmFkYW1Abm9zdHJ1bS5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyBPbiAyLzQvMjAgMTA6MzcsIEVyaWMgUmVzY29ybGEgd3JvdGU6PGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7IEluIHRoZSBpbnRlcmVzdCBvZiB0cnlpbmcgdG8gbW92ZSBmb3J3 YXJkLi4uLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsgSSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBhIGJ1bmNoIG9mIHRyaWNr eSBuZXR3b3JrIHNjZW5hcmlvcyB0aGF0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 IG5lZWQgdG8gYmUgaGFuZGxlZCAoY2FwdGl2ZSBwb3J0YWxzLCBWUE5zLCBzcGxpdCBETlMsIGV0 Yy4pIGFuZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyB0aGF0IHByb3ZpZGluZyBz b21lIGd1aWRhbmNlIGhlcmUgd291bGQgYmUgdXNlZnVsLiBXaGF0IEknbSB0cnlpbmc8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgdG8gYXZvaWQgaXMgdGhhdCBibGVlZGluZyBpbnRv IGEgbG90IG9mIGRlYmF0aW5nIGFib3V0IHBvbGljeSBhbmQ8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsgaG93IHBhcnRpY3VsYXIgY2xpZW50cyBvdWdodCB0byBiZWhhdmUuIFdpdGgg dGhhdCBpbiBtaW5kLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBoZXJlIGlzIHdo YXQgSSBzdWdnZXN0Ojxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgMS4gUmV2aXNlIHRoYXQgYnVsbGV0IHRvIGJlIG1vcmUg Y2xlYXJseSB0ZWNobmljYWw6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IDxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAtIGRldmVsb3Ag YW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyBtZWNoYW5pc21zIGZvcjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBjbGllbnRz IHRvIGRldGVjdCBzcGVjaWZpYyBuZXR3b3JrIGVudmlyb25tZW50cyAoY2FwdGl2ZSBwb3J0YWws PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwbGl0 IGhvcml6b24sIGV0Yy4pIGFuZCB1c2UgdGhhdCB0byBpbmZvcm0gdGhlaXIgRE5TPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24u PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgMi4gQWRkIGEgc2Vu dGVuY2UgdG8gdGhlIGNoYXJ0ZXIgYWZ0ZXIgdGhlIHdvcmsgaXRlbXMgdGhhdCBzYXlzOjxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhpcyB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0 ZXJlZCBzb2xlbHkgdG8gZGV2ZWxvcCB0ZWNobmljYWw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbWVjaGFuaXNtcy4gTWFraW5nIGFueSByZWNvbW1l bmRhdGlvbnMgYWJvdXQgc3BlY2lmaWMgcG9saWNpZXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9yIGNsaWVudHMgYW5kIHNlcnZlcnMgaXMgb3V0 IG9mIHNjb3BlLiZxdW90Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7IEkgdGhpbmsgdGhpcyB3b3VsZCBnbyBhIGxvbmcgd2F5IHRvd2FyZHMgY29udGludWluZyB0 aGUgZm9ybXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgb2YgcHJvZHVjdGl2ZSBl bmdhZ2VtZW50IHdlIGhhdmUgYmVlbiBzZWVpbmcgKHdoaWNoIEkgYWdyZWU8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsgdGhlcmUgaGF2ZSBiZWVuKSB3aGlsZSBzY29waW5nIG91dCBj b250ZW50aW91cyBhbmQgdW5wcm9kdWN0aXZlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7IHBvbGljeSBkZWJhdGVzLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFRoYW5r cy4gVGhpcyBjcm9zc2VkIG9uIHRoZSB3aXJlIHdpdGggbXkgcHJldmlvdXMgbWVzc2FnZSwgYW5k IEkgdGhpbmsgaXQncyBhIGdvb2QgZXhhbXBsZSBvZiB0aGUga2luZHMgb2YgZ3VpZGVyYWlscyBJ IHdhcyBjYWxsaW5nIGZvci48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7ICYjNDM7MTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgSSB0aGluayBib3RoIG9mIHRoZXNlIHRleHR1YWwgY2hhbmdlcyBhcmUgYXBwcm9w cmlhdGUsIGFuZCBjbGFyaWZ5IHRoZSBpbnRlbnQgb2YgdGhlIGNoYXJ0ZXIsIHdpdGhvdXQgdW5k dWx5IGNvbnN0cmFpbmluZyB0aGUgdGVjaG5pY2FsIHdvcmsgb2YgYSBncm91cC4gSSBzdXBwb3J0 IHBlcmZvcm1pbmcgYm90aCBvZiB0aGVzZSBjaGFuZ2VzITxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzIGVrciBmb3IgdGhlIHN1Z2dlc3Rpb25z Ljxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgQmVzdCw8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgVG9tbXk8YnI+DQo8YnI+DQomIzQzOzE8YnI+DQo8YnI+ DQpJIGFsc28gZG9uJ3QgaGF2ZSBhbnkgaGVhcnRidXJuIHdpdGggZWl0aGVyIG9mIHRoZSBzdWdn ZXN0ZWQgY2hhbmdlcy4gVGhleSBjbGFyaWZ5IHRoZSBtaXNzaW9uIHdoaWxlIGtlZXBpbmcgdGhl IGNoYXJ0ZXIgY2xlYW4gZW5vdWdoIHRoYXQgaXQncyBzaW1wbGUgdG8gcmVhZCBhbmQgdW5kZXJz dGFuZC48YnI+DQo8YnI+DQotZ2xlbm48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgLS0g PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IEFkZCBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkFkZEBpZXRmLm9yZyI+QWRkQGlldGYub3JnPC9hPjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZhZGQmYW1wO2FtcDtkYXRhPTAyJTdDMDElN0NKZW5zZW4uVGhv bWFzJTQwbWljcm9zb2Z0LmNvbSU3QzQ0MjNlZDVlYmU1NzQ2NzE4MTg2MDhkN2E5OWNiNjgyJTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE2NDM2Mjg5NDA0 Mzc4OCZhbXA7YW1wO3NkYXRhPTBEc0xpSyUyRmdPRHVWQk9CTXYxOTVoRmxHemwxQU9rYXd2UWsz ZVJMJTJGU0IwJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MCI+DQpodHRwczovL25hbTA2LnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmcl MkZtYWlsbWFuJTJGbGlzdGluZm8lMkZhZGQmYW1wO2FtcDtkYXRhPTAyJTdDMDElN0NKZW5zZW4u VGhvbWFzJTQwbWljcm9zb2Z0LmNvbSU3QzQ0MjNlZDVlYmU1NzQ2NzE4MTg2MDhkN2E5OWNiNjgy JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE2NDM2Mjg5 NDA0Mzc4OCZhbXA7YW1wO3NkYXRhPTBEc0xpSyUyRmdPRHVWQk9CTXYxOTVoRmxHemwxQU9rYXd2 UWszZVJMJTJGU0IwJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDwvYT4NCjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyA8YnI+DQo8YnI+DQotLSA8YnI+DQpBZGQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOkFkZEBpZXRmLm9yZyI+QWRkQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmFkZCZhbXA7YW1wO2Rh dGE9MDIlN0MwMSU3Q0plbnNlbi5UaG9tYXMlNDBtaWNyb3NvZnQuY29tJTdDNDQyM2VkNWViZTU3 NDY3MTgxODYwOGQ3YTk5Y2I2ODIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 QzElN0MwJTdDNjM3MTY0MzYyODk0MDQzNzg4JmFtcDthbXA7c2RhdGE9MERzTGlLJTJGZ09EdVZC T0JNdjE5NWhGbEd6bDFBT2thd3ZRazNlUkwlMkZTQjAlM0QmYW1wO2FtcDtyZXNlcnZlZD0wIj5o dHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZhZGQmYW1wO2FtcDtk YXRhPTAyJTdDMDElN0NKZW5zZW4uVGhvbWFzJTQwbWljcm9zb2Z0LmNvbSU3QzQ0MjNlZDVlYmU1 NzQ2NzE4MTg2MDhkN2E5OWNiNjgyJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNzE2NDM2Mjg5NDA0Mzc4OCZhbXA7YW1wO3NkYXRhPTBEc0xpSyUyRmdPRHVW Qk9CTXYxOTVoRmxHemwxQU9rYXd2UWszZVJMJTJGU0IwJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_LO2P265MB05730676E4BBF2B65F658E2DC2030LO2P265MB0573GBRP_-- From nobody Tue Feb 4 10:53:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BCE12008D; Tue, 4 Feb 2020 10:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0-UOzA0hnz6; Tue, 4 Feb 2020 10:53:23 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2101.outbound.protection.outlook.com [40.107.22.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65740120152; Tue, 4 Feb 2020 10:53:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=magEC8dSoYYP1BZqQ7EpI4j77pY4ajcyHQppcE4Tmj4+p/XBtczkvpRUVnfJtTY0iJwKzY2HuUQtBmfV5IPDSa316dB7Z9hON42SezCt9waMmBhOlHCd9IjDl1Ca0lyxqxxK7uYNedDyFCHxyaIdr3aZeg8LYc5UX/fS/c8dPGLHnG+cZx9Fh6pRuspxy+6cmMo7C2xHijMzw1sQkcG1vKEqggQm/TMliWe5Na+xnl9KrrLkW8MEFT1w20tBTWtqZl8wW8jc/mPYWr96ZkQDMbXqVzmBO5ozEu7CCDte1fhIgi1sZZDdFGucTOMab+snrGfEZOpAR2a6ujXt2HfgYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7lK9MKfDEPPjaTQU9es5ecl5vZhWpQM/ZY2Y7x1Vbic=; b=FKLzXUPGFay91g4vsaIJYMpA6oEgAlaoOGdabdTDlEFhf4/uwz1xnLK21swzJ4B89qxfj+boZjutNPrzS4hC4xUASv/+1YV/mEL+FwO6lWc2JVp55DEwGCeyoo4Y1fxvTUz+YVZGd0zsvI6aF5XK+jJJ6cCh0MvSLxMrvncShccDX/vwQ0n6QiyOD7tNUZBps3UEBYfr78PNwM6b/a0jqwn7f9kgNAR2QvH2J2dlTQBGTL1WOXG/EPpKQfwbqpQjjKiKo0jdKMqtTrR1ZbWkQ+pGKSrv+QfGuVQx+F/8griGEPDSvn7ZgbBz4nk50/DeDt5vjVpi3St/DGKj/wWpXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7lK9MKfDEPPjaTQU9es5ecl5vZhWpQM/ZY2Y7x1Vbic=; b=B+APAFyRe1RDITZ+NF5bnkOvfdLYP/OEKBonNkzWfyDD1ZvO8ZVRgHT+9dSEvpmpxf9GnvmDOchu25RdpasKBRULEZjQQv+FUmTaE6y7G/OS5o2NoIlb6elL5zQBezLNSYcvZD2hiDA9zjgrUej/4TLVYXXLRXRnAQ38/WxoJ50= Received: from AM0PR06MB6435.eurprd06.prod.outlook.com (10.186.130.150) by AM0PR06MB5876.eurprd06.prod.outlook.com (20.178.112.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Tue, 4 Feb 2020 18:53:21 +0000 Received: from AM0PR06MB6435.eurprd06.prod.outlook.com ([fe80::7cfe:be7b:9e88:e034]) by AM0PR06MB6435.eurprd06.prod.outlook.com ([fe80::7cfe:be7b:9e88:e034%7]) with mapi id 15.20.2686.031; Tue, 4 Feb 2020 18:53:21 +0000 From: "Diego R. Lopez" To: ADD Mailing list , "add-chairs@ietf.org" CC: The IESG Thread-Topic: [Add] [EXTERNAL] Re: [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV24WX2V1EViddFEisQB/ANxALNagLWJaAgAABLgCAABLIgIAABeeA Date: Tue, 4 Feb 2020 18:53:21 +0000 Message-ID: <027BDD7C-3F90-49D2-8531-25C5F0F049F7@telefonica.com> References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> <9e1445a9-4030-706d-bee2-93905f470867@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.12.200112 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [85.62.29.134] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 304d8090-5650-4348-a0d7-08d7a9a38174 x-ms-traffictypediagnostic: AM0PR06MB5876: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(396003)(136003)(366004)(39860400002)(376002)(189003)(199004)(64756008)(66556008)(66476007)(966005)(478600001)(91956017)(45080400002)(33656002)(66946007)(76116006)(26005)(186003)(6506007)(2616005)(8676002)(81166006)(81156014)(8936002)(2906002)(66446008)(71200400001)(450100002)(4326008)(86362001)(66574012)(36756003)(5660300002)(786003)(6486002)(6512007)(316002)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR06MB5876; H:AM0PR06MB6435.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bNWyZ5K/qhteRYUkGsUJa1IAEjonK43j8+Ri5yQh/pbrn6rCMt/Urne8BX+WUAgcCny7Rw6mYqPGpPcxis2gEdx6wHfl7Fnei5V83ughzkyxGy5OOx0/af7cpfPrulNk6DJjnQ+EZhhUxAPJq0ca3IAvyg3U+LHoYjYJwcKtT8EdOQZJ+jWNY2KLiUds4paQigA5Hc7kfSxh6WHSq8UJw/zloeyP0ePEgKmNGxG0hma7hJydAhxkj4tKPmu6dTCWUVsAakVVw1nwxqPS1PrPNBHH7ar2LFMrRVthwXp7pwRYhcTiA9x8yNKF1RT+uPu4nwg/Xn8NbQRvr8d+sL10bf3wxmAR8btyTBVfSlLV1HS53kTixH4I0d7uYMTaCLRc/GesOPwZgh7zEaz7CFmhdCSSMp1ZhDO5r+cb2ffoj/dObnVH5TnMDyxKmbMp2hGSnlwAdkAoG2ver6J27iltQ2QePa3YfTGp/IFyYDXSdmgmgmFOA+ZHcw6rw7qLNRHIaj4dXekB9uTBNdAEqWP2NQ== x-ms-exchange-antispam-messagedata: 5TNgwsg/BrjRtpHaob6xMAflIeWr3ez3nF/OwCyl/9h6o2Nlvk+asSnbliAV4Ud+yMnbIfd+6h2iBIUbLk0GFLva2Wnbm7zWmrinKhiO0sf1/b3bfkHASAS3DdUXausVgqIc4+4Z+Z+yI4F0oOvHtA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_027BDD7C3F9049D2853125C5F0F049F7telefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 304d8090-5650-4348-a0d7-08d7a9a38174 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 18:53:21.1647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Vf1RVMrJG9OLPil/ql2KqoiFELGvWmI92rFl9DO3JsHdJ0qIPPyuuORvSgyfFg2GfGXyY1jqenMs2xxqvPdiwrRZoJbK36QxQCe+mpLOShU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB5876 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 18:53:27 -0000 --_000_027BDD7C3F9049D2853125C5F0F049F7telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIHlldCBhbm90aGVyICsxLCBpbiB0aGUgc2FtZSBzcGlyaXQgYXMgQW5kcmV34oCmDQoNCi0t DQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBS LiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9kcjJs b3Blei8NCg0KZS1tYWlsOiBkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tPG1haWx0bzpkaWVn by5yLmxvcGV6QHRlbGVmb25pY2EuY29tPg0KVGVsOiAgICAgICAgICszNCA5MTMgMTI5IDA0MQ0K TW9iaWxlOiAgKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCk9uIDA0LzAyLzIwMjAsIDE5OjI1LCAiQWRkIG9uIGJlaGFsZiBvZiBBbmRyZXcgQ2Ft cGxpbmciIDxhZGQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YWRkLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiBhbmRyZXcuY2FtcGxpbmdANDE5LmNvbnN1bHRpbmc8bWFpbHRvOmFuZHJl dy5jYW1wbGluZ0A0MTkuY29uc3VsdGluZz4+IHdyb3RlOg0KDQpBbm90aGVyICsxIOKAkyBhIGhl bHBmdWwgY2hhbmdlIGlmIHRoaXMgcHJvdmlkZXMgcmVhc3N1cmFuY2UgdGhhdCB0aGVyZSBpcyBu byBpbnRlbmRlZCBtaXNzaW9uIGNyZWVwIGFuZCBwcm92aWRlcyB0aGUgYmFzaXMgZm9yIHRoZSB3 b3JraW5nIGdyb3VwIGNoYXJ0ZXJpbmcgcHJvY2VzcyB0byBtb3ZlIGZvcndhcmQuDQoNCkFuZHJl dw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgeSBz dXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywg cHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5 IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5v LiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmlj YWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29w aWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBs YSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBl cnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3Ig ZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi4NCg0KVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBt ZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0 aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2Ug aW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuDQoNCkVzdGEgbWVu c2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0 aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZp ZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUg ZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNh ZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVs Z2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRh IGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5z YWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1l bnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvDQo= --_000_027BDD7C3F9049D2853125C5F0F049F7telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <96C7E5E8C7E057408F4362541FCA3ED1@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+QW5kIHlldCBhbm90aGVyICYjNDM7MSwgaW4gdGhlIHNhbWUg c3Bpcml0IGFzIEFuZHJld+KApjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+LS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JnF1b3Q7RXN0YSB2ZXog bm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5EciBEaWVnbyBSLiBMb3Blejwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5UZWxlZm9uaWNhIEkmIzQzO0Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cubGlua2VkaW4uY29tL2luL2RyMmxvcGV6LyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEi Pmh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9kcjJsb3Blei88L3NwYW4+PC9hPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ZS1tYWlsOiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxhIGhyZWY9 Im1haWx0bzpkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMwNTYzQzEiPmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb208L3NwYW4+ PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGVsOiZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzszNCA5MTMgMTI5IDA0MTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+TW9iaWxlOiAmbmJzcDsmIzQzOzM0IDY4MiAwNTEgMDkxPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMDQvMDIvMjAyMCwgMTk6MjUsICZxdW90O0FkZCBv biBiZWhhbGYgb2YgQW5kcmV3IENhbXBsaW5nJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWRk LWJvdW5jZXNAaWV0Zi5vcmciPmFkZC1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YN CjxhIGhyZWY9Im1haWx0bzphbmRyZXcuY2FtcGxpbmdANDE5LmNvbnN1bHRpbmciPmFuZHJldy5j YW1wbGluZ0A0MTkuY29uc3VsdGluZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPkFub3RoZXIgJiM0MzsxIOKAkyBhIGhlbHBmdWwgY2hhbmdlIGlmIHRoaXMgcHJvdmlk ZXMgcmVhc3N1cmFuY2UgdGhhdCB0aGVyZSBpcyBubyBpbnRlbmRlZCBtaXNzaW9uIGNyZWVwIGFu ZCBwcm92aWRlcyB0aGUgYmFzaXMgZm9yIHRoZSB3b3JraW5nIGdyb3VwIGNoYXJ0ZXJpbmcgcHJv Y2VzcyB0byBtb3ZlIGZvcndhcmQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+QW5kcmV3PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj48YnI+ DQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBh IHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFk YSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8g ZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGlj YWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYQ0KIGxlY3R1cmEsIHV0aWxpemFjacOzbiwg ZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9o aWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlk byBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVl IGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1 Y2Npw7NuLjxicj4NCjxicj4NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFu c21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVu ZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFi b3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwN CiBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4g ZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNl bmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBh bmQgdGhlbiBkZWxldGUgaXQuPGJyPg0KPGJyPg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9z IHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29u dGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1 c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOp IHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRv IGRlIHF1ZSBhDQogbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7Nw aWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxl Z2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJv Z2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNt YSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbzxicj4NCjwvZm9udD4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_027BDD7C3F9049D2853125C5F0F049F7telefonicacom_-- From nobody Tue Feb 4 11:45:49 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5BA120912; Tue, 4 Feb 2020 11:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHsdaNC1Waiq; Tue, 4 Feb 2020 11:45:44 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5621208F0; Tue, 4 Feb 2020 11:45:44 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 014JjRPD010457; Tue, 4 Feb 2020 14:45:43 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2xydeybjkj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Feb 2020 14:45:43 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 014JjeVB011332; Tue, 4 Feb 2020 14:45:41 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 014JjXnW011091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Feb 2020 14:45:33 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 702824005C1C; Tue, 4 Feb 2020 19:45:33 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30486.vci.att.com (Service) with ESMTPS id 5A9A54005C1B; Tue, 4 Feb 2020 19:45:33 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.85]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0468.000; Tue, 4 Feb 2020 14:45:33 -0500 From: "STARK, BARBARA H" To: "'Diego R. Lopez'" , "'ADD Mailing list'" , "'add-chairs@ietf.org'" CC: "'The IESG'" Thread-Topic: [Add] [EXTERNAL] Re: [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) Thread-Index: AQHV24WYU9+OO1RwQ0SvfTHvAPFj3qgLWJaAgAABLgCAABLIgIAABeeA///83dA= Date: Tue, 4 Feb 2020 19:45:32 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611537710FF@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> <9e1445a9-4030-706d-bee2-93905f470867@nostrum.com> <027BDD7C-3F90-49D2-8531-25C5F0F049F7@telefonica.com> In-Reply-To: <027BDD7C-3F90-49D2-8531-25C5F0F049F7@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.68.55] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611537710FFGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-04_07:2020-02-04, 2020-02-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxlogscore=999 spamscore=0 malwarescore=0 suspectscore=0 priorityscore=1501 adultscore=0 phishscore=0 bulkscore=0 mlxscore=0 lowpriorityscore=0 impostorscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2002040133 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 19:45:47 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611537710FFGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCkFuZCBzcGVjaWFsIHRoeCB0byBUb21teSBQIGZvciBnZXR0aW5nIHVzIHRvIHRoaXMgcG9p bnQuDQpCYXJiYXJhDQoNCkZyb206IEFkZCA8YWRkLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBEaWVnbyBSLiBMb3Bleg0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMjAgMTo1 MyBQTQ0KVG86IEFERCBNYWlsaW5nIGxpc3QgPGFkZEBpZXRmLm9yZz47IGFkZC1jaGFpcnNAaWV0 Zi5vcmcNCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQWRkXSBb RVhURVJOQUxdIFJlOiBbRXh0XSBBZGFtIFJvYWNoJ3MgTm8gT2JqZWN0aW9uIG9uIGNoYXJ0ZXIt aWV0Zi1hZGQtMDAtMDA6ICh3aXRoIENPTU1FTlQpDQoNCkFuZCB5ZXQgYW5vdGhlciArMSwgaW4g dGhlIHNhbWUgc3Bpcml0IGFzIEFuZHJld+KApg0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVt b3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStE DQpodHRwczovL3d3dy5saW5rZWRpbi5jb20vaW4vZHIybG9wZXovPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmxpbmtlZGluLmNvbV9pbl9k cjJsb3Blel8mZD1Ed01HYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhDLThzYzhT WThUcTR2cmZvZyZtPU82QlNLd2F4T3FZTnVSdlRrbmNoblBxeFl2VzV2ZV9kWThFYkIzT0VmZ2sm cz0yQ092Z3NSalJOd01QT1JUVHIwQllGRVpLYmdfakg3M2xGN1dOSW8yZG93JmU9Pg0KDQplLW1h aWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb208bWFpbHRvOmRpZWdvLnIubG9wZXpAdGVs ZWZvbmljYS5jb20+DQpUZWw6ICAgICAgICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICArMzQg NjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KT24gMDQv MDIvMjAyMCwgMTk6MjUsICJBZGQgb24gYmVoYWxmIG9mIEFuZHJldyBDYW1wbGluZyIgPGFkZC1i b3VuY2VzQGlldGYub3JnPG1haWx0bzphZGQtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IGFuZHJldy5jYW1wbGluZ0A0MTkuY29uc3VsdGluZzxtYWlsdG86YW5kcmV3LmNhbXBsaW5nQDQx OS5jb25zdWx0aW5nPj4gd3JvdGU6DQoNCkFub3RoZXIgKzEg4oCTIGEgaGVscGZ1bCBjaGFuZ2Ug aWYgdGhpcyBwcm92aWRlcyByZWFzc3VyYW5jZSB0aGF0IHRoZXJlIGlzIG5vIGludGVuZGVkIG1p c3Npb24gY3JlZXAgYW5kIHByb3ZpZGVzIHRoZSBiYXNpcyBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAg Y2hhcnRlcmluZyBwcm9jZXNzIHRvIG1vdmUgZm9yd2FyZC4NCg0KQW5kcmV3DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBz ZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5l ciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28g ZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVz dGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxh IGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3Jp emFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOz biB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dh bW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbD rWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNh dGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRy YW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSBy ZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0 aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNldXMg YW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBv ZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kg cGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBu w6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3Rp ZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3Ug Y8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBk YSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJv LCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEg bWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== --_000_2D09D61DDFA73D4C884805CC7865E611537710FFGAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFuZCBzcGVjaWFsIHRoeCB0byBUb21teSBQIGZvciBnZXR0aW5nIHVzIHRv IHRoaXMgcG9pbnQuIDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYXJi YXJhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEFkZCAmbHQ7YWRkLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpEaWVnbyBSLiBMb3Blejxi cj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAwNCwgMjAyMCAxOjUzIFBNPGJyPg0K PGI+VG86PC9iPiBBREQgTWFpbGluZyBsaXN0ICZsdDthZGRAaWV0Zi5vcmcmZ3Q7OyBhZGQtY2hh aXJzQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBZGRdIFtFWFRFUk5BTF0gUmU6IFtFeHRdIEFk YW0gUm9hY2gncyBObyBPYmplY3Rpb24gb24gY2hhcnRlci1pZXRmLWFkZC0wMC0wMDogKHdpdGgg Q09NTUVOVCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BbmQgeWV0IGFub3RoZXIgJiM0MzsxLCBpbiB0aGUgc2Ft ZSBzcGlyaXQgYXMgQW5kcmV34oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi0tPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZxdW90O0VzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3Rv ciBJbmZpZXJubyZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+RHIgRGllZ28gUi4gTG9wZXo8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGVsZWZvbmljYSBJJiM0MztEPC9zcGFuPjxzcGFuIGxh bmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmxpbmtlZGluLmNv bV9pbl9kcjJsb3Blel8mYW1wO2Q9RHdNR2FRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcm YW1wO3I9TG9HemhDLThzYzhTWThUcTR2cmZvZyZhbXA7bT1PNkJTS3dheE9xWU51UnZUa25jaG5Q cXhZdlc1dmVfZFk4RWJCM09FZmdrJmFtcDtzPTJDT3Znc1JqUk53TVBPUlRUcjBCWUZFWktiZ19q SDczbEY3V05JbzJkb3cmYW1wO2U9Ij48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6 Ly93d3cubGlua2VkaW4uY29tL2luL2RyMmxvcGV6Lzwvc3Bhbj48L2E+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5lLW1haWw6Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEgaHJl Zj0ibWFpbHRvOmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+ZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbTwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPlRlbDombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 MzQgOTEzIDEyOSAwNDE8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+TW9iaWxlOiAmbmJzcDsmIzQzOzM0IDY4MiAwNTEgMDkxPC9zcGFuPjxzcGFu IGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVTIj5PbiAwNC8wMi8yMDIwLCAx OToyNSwgJnF1b3Q7QWRkIG9uIGJlaGFsZiBvZiBBbmRyZXcgQ2FtcGxpbmcmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzphZGQtYm91bmNlc0BpZXRmLm9yZyI+YWRkLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmFuZHJldy5jYW1wbGluZ0A0MTkuY29u c3VsdGluZyI+YW5kcmV3LmNhbXBsaW5nQDQxOS5jb25zdWx0aW5nPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+QW5vdGhlciAmIzQzOzEg4oCTIGEgaGVscGZ1bCBjaGFuZ2UgaWYgdGhpcyBwcm92aWRlcyBy ZWFzc3VyYW5jZSB0aGF0IHRoZXJlIGlzIG5vIGludGVuZGVkIG1pc3Npb24gY3JlZXAgYW5kIHBy b3ZpZGVzIHRoZSBiYXNpcyBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgY2hhcnRlcmluZyBwcm9jZXNz IHRvIG1vdmUNCiBmb3J3YXJkLjwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxi PjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+QW5kcmV3PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBsYW5nPSJFUyI+DQo8aHIg c2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpncmF5Ij48YnI+ DQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBh IHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFk YSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8g ZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGlj YWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYQ0KIGxlY3R1cmEsIHV0aWxpemFjacOzbiwg ZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9o aWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlk byBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVl IGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1 Y2Npw7NuLjxicj4NCjxicj4NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFu c21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVu ZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFi b3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwN CiBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4g ZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNl bmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBh bmQgdGhlbiBkZWxldGUgaXQuPGJyPg0KPGJyPg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9z IHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29u dGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1 c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOp IHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRv IGRlIHF1ZSBhDQogbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7Nw aWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxl Z2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJv Z2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNt YSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbzwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_2D09D61DDFA73D4C884805CC7865E611537710FFGAALPA1MSGUSRBF_-- From nobody Tue Feb 4 11:59:24 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE77120130; Tue, 4 Feb 2020 11:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSK-2sBbUn-h; Tue, 4 Feb 2020 11:59:18 -0800 (PST) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455E312012E; Tue, 4 Feb 2020 11:59:18 -0800 (PST) Received: by mail-il1-f182.google.com with SMTP id l4so17025863ilj.1; Tue, 04 Feb 2020 11:59:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ChRdOO2Yb79YzJ/nIna08XsdWSEXLttpbyGkZdK+5aI=; b=jxXKOdy43lF1QjaFEC5WkkhMHmvoHZ/vqoCHUPE68Oz93rbXhQeRRPQDYIelPhdBxI Xf8ozWkCFP7myKlxrtXOl6LCfNKtM3p9CO8G2jApSzQMgliTiQ5wdIbeAUMSrnkOTl4r fY9xrDAtnMHw+eTKqWYKAdbttmDzC0WTszbfulPTFtJLKq7QyD+nZU9yq6iqf8m0ua2L nbVvbNlqF6Y+sXEKtx9gKKwV2PS9AVMPRVXvcgqYfGMTxOg8ov3G8B+L9b/q35mkBgxr 8F/q1uNXgxsmkjDCIYjjjS0yXsZ+xNdcmTiLI4l+HjPJVWkU0G08IG5aq6z4sL2YVJDT 5qIw== X-Gm-Message-State: APjAAAVqYFMYzijjNgk2WShDoQGu9Jm4pG9uJz7FYqQT42dON4SQXmdZ 1zEC+g2FX8EQ/S/mn2vQL9jVIAW6ohfm1aYFajo= X-Google-Smtp-Source: APXvYqzI1U9G3j3+4kf3PUtbgHXSaflFmCJn+jzypFjgJ6KRdnRUAW4Rh6OgjKLDQDEk2DSfT8sA339yT4oW7eU/3N0= X-Received: by 2002:a92:508:: with SMTP id q8mr21660625ile.187.1580846357310; Tue, 04 Feb 2020 11:59:17 -0800 (PST) MIME-Version: 1.0 References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> In-Reply-To: From: Barry Leiba Date: Tue, 4 Feb 2020 14:59:06 -0500 Message-ID: To: Eric Rescorla Cc: ADD Mailing list , The IESG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 19:59:20 -0000 Given the significant support for EKR's suggestion, I'm incorporating it into the charter proposal now. Barry On Tue, Feb 4, 2020 at 11:38 AM Eric Rescorla wrote: > > In the interest of trying to move forward.... > > I agree that there are a bunch of tricky network scenarios that > need to be handled (captive portals, VPNs, split DNS, etc.) and > that providing some guidance here would be useful. What I'm trying > to avoid is that bleeding into a lot of debating about policy and > how particular clients ought to behave. With that in mind, > here is what I suggest: > > 1. Revise that bullet to be more clearly technical: > > - develop an informational document that describes mechanisms for > clients to detect specific network environments (captive portal, > split horizon, etc.) and use that to inform their DNS > configuration. > > > 2. Add a sentence to the charter after the work items that says: > > "This working group is chartered solely to develop technical > mechanisms. Making any recommendations about specific policies > for clients and servers is out of scope." > > > I think this would go a long way towards continuing the forms > of productive engagement we have been seeing (which I agree > there have been) while scoping out contentious and unproductive > policy debates. > > -Ekr > > > > > On Tue, Feb 4, 2020 at 8:12 AM Adam Roach wrote: >> >> On 2/4/20 09:01, Deen, Glenn (NBCUniversal) wrote: >> >> >> >> >> >> On 2/4/20, 4:46 AM, "Add on behalf of Eric Rescorla" wrote: >> >> >> >> On Tue, Feb 4, 2020 at 4:37 AM Paul Hoffman wro= te: >> >> >> >> - 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 =C3=89ric that the described work is op= en-ended >> > enough to result in unproductive and likely toxic interactions. It wou= ld >> > 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 conversatio= ns >> > 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. >> >> 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 th= e evidence is that that's not a productive venue for them. >> >> >> While the ADD list and BoFs have certainly not been productive venues fo= r discussions that=E2=80=99s largely attributable to a variety of factors w= hich likely won=E2=80=99t be present in actual WG. The ADD list and BoFs = have been very broad and wide open, and lacked the focus of a charter, whic= h resulted in unproductive discussions that didn=E2=80=99t progress. The W= G conversely will have a specific charter to focus it and chairs to help ma= nage the activity. >> >> >> Thanks. I completely agree that there is useful work that a tightly-scop= ed charter can foster. I also agree with the implied converse, which is tha= t an insufficiently-tightly-scoped charter will make useful work difficult = or impossible. >> >> /a From nobody Tue Feb 4 14:00:13 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38682120130; Tue, 4 Feb 2020 14:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsLaT1nf6Sgu; Tue, 4 Feb 2020 14:00:09 -0800 (PST) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD7512003F; Tue, 4 Feb 2020 14:00:08 -0800 (PST) Received: by mail-ua1-x936.google.com with SMTP id y3so85111uae.3; Tue, 04 Feb 2020 14:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3gyEiC0o120YCYd+Svgvf2Ut6oCxekit902OBnxDWnI=; b=jEJqNzOD4cBgWIUdCimzno80STSTFcTtCsFuGPqwSda8ggFm4akgjvhhlL3aaou3eb gWYJprUWGaVMsR+NQ6uOhqq/bjN4N9qE1ymbWf9F2ezqjLD1i3bi9EeKx1XZe8cMfprn eRQ7yWf6udfsOJu1HRi1oJ/NE/cZNDoX/7/EJ7hGQAt6KNpn5iMkrg7DRzjAc98/pvOH eDlmSSuxwl0KGyHEIxm2cHIyPRb+vGLmO5PFC+7/gBeFxne6n20iLQQmbRaz5yt+b4fy LO++KhknMWA7DP+1SPmW7/CjS5rOzz1v8TC8AktAPFyHijIJdsyKtme1SC2eSFNr4C4/ hgzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3gyEiC0o120YCYd+Svgvf2Ut6oCxekit902OBnxDWnI=; b=B/T+gt2ygOkTDIhU+uTRKE59xsIHI6hAcCSsPGvslw2eW04QDPp0XMHNaIa9fpmxCX ZnUEJlzcaUHA/om7CgKDb1E8cmymJRQ5OeQQDSfU8SL8jpSg9+FjPvtjj+HiTgwYyMqn mRKxROxMTfg0kYfZXLMrYxIxNECPjDkEsPpVgYovQaxOC2Q0nMAmHZDF2HLx2Ut4a4PS UTnaA9Jxaz30H0ZRyiOqzBqmOxnRncAMet2oDV7dljZ8PM3SwdT3MfD6dcjtDCAAfeP1 Q8Y38HkZbqdoYT69qMKxwPCTf3+hzQiHt/eu69nBuvaCkZYerCbJiciNtR2l3jwesgjJ t6xw== X-Gm-Message-State: APjAAAVBClAzNi/ux4wImnAv/ckgQ44db0l1Ig393LgK0xaHqEHwATtw 7TBBBLefmPWcl5/pJtD/SwrP95tjnsENOoPB+cE= X-Google-Smtp-Source: APXvYqzcU/+Jxg6xm3bq/vIm8q2ZAid4gaJRA1coXUwETPqj2EQind1CoqV505E47vyd028mLFVDqWxEz2TtxbLs7Lk= X-Received: by 2002:ab0:4931:: with SMTP id z46mr18935457uac.119.1580853607766; Tue, 04 Feb 2020 14:00:07 -0800 (PST) MIME-Version: 1.0 References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> In-Reply-To: From: Daniel Migault Date: Tue, 4 Feb 2020 16:59:57 -0500 Message-ID: To: Eric Rescorla Cc: Adam Roach , Paul Hoffman , ADD Mailing list , "add-chairs@ietf.org" , The IESG , "Deen, Glenn (NBCUniversal)" Content-Type: multipart/alternative; boundary="000000000000bb9f91059dc729fe" Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 22:00:11 -0000 --000000000000bb9f91059dc729fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020 at 11:38 AM Eric Rescorla wrote: > In the interest of trying to move forward.... > > I agree that there are a bunch of tricky network scenarios that > need to be handled (captive portals, VPNs, split DNS, etc.) and > that providing some guidance here would be useful. What I'm trying > to avoid is that bleeding into a lot of debating about policy and > how particular clients ought to behave. With that in mind, > here is what I suggest: > > 1. Revise that bullet to be more clearly technical: > > - develop an informational document that describes mechanisms for > clients to detect specific network environments (captive portal, > split horizon, etc.) and use that to inform their DNS > configuration. > > > 2. Add a sentence to the charter after the work items that says: > > "This working group is chartered solely to develop technical > mechanisms. Making any recommendations about specific policies > for clients and servers is out of scope." > > > I think this would go a long way towards continuing the forms > of productive engagement we have been seeing (which I agree > there have been) while scoping out contentious and unproductive > policy debates. > > It is good to explicitly roll out policies. I would like to clarify whether informational document such as requirements or analysis could fit into the scope of technical mechanisms - as long as they remain out of the policy spectrum of course. I do not have a specific document in mind. as we have informational documents in the goals we may specify the the mechanism to be standard. > -Ekr > > > > > On Tue, Feb 4, 2020 at 8:12 AM Adam Roach wrote: > >> On 2/4/20 09:01, Deen, Glenn (NBCUniversal) wrote: >> >> >> >> >> >> On 2/4/20, 4:46 AM, "Add on behalf of Eric Rescorla" < >> add-bounces@ietf.org on behalf of ekr@rtfm.com> wrote: >> >> >> >> On Tue, Feb 4, 2020 at 4:37 AM Paul Hoffman >> wrote: >> >> >> >> - 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 =C3=89ric that the described work is >> open-ended >> > enough to result in unproductive and likely toxic interactions. It wou= ld >> > 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 conversatio= ns >> > 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. >> >> However, taking it fully off the plate will lead to the same discussions >> happening repeatedly due to current deployment strategies of major vendo= rs. >> >> >> >> Well, perhaps, but we don't need an IETF WG for those discussions and th= e >> evidence is that that's not a productive venue for them. >> >> >> While the ADD list and BoFs have certainly not been productive venues fo= r >> discussions that=E2=80=99s largely attributable to a variety of factors = which >> likely won=E2=80=99t be present in actual WG. The ADD list and BoFs ha= ve been >> very broad and wide open, and lacked the focus of a charter, which resul= ted >> in unproductive discussions that didn=E2=80=99t progress. The WG conver= sely will >> have a specific charter to focus it and chairs to help manage the activi= ty. >> >> >> Thanks. I completely agree that there is useful work that a >> tightly-scoped charter can foster. I also agree with the implied convers= e, >> which is that an insufficiently-tightly-scoped charter will make useful >> work difficult or impossible. >> >> /a >> > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --=20 Daniel Migault Ericsson --000000000000bb9f91059dc729fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 11:38 AM Eric = Rescorla <ekr@rtfm.com> wrote:
I= n the interest of trying to move forward....

I agree that there are = a bunch of tricky network scenarios that
need to be handled (captive por= tals, VPNs, split DNS, etc.) and
that providing some guidance here would= be useful. What I'm trying
to avoid is that bleeding into a lot of = debating about policy and
how particular clients ought to behave. With t= hat in mind,
here is what I suggest:

1. Revise that bullet to be = more clearly technical:

=C2=A0 =C2=A0- develop an informational docu= ment that describes mechanisms for
=C2=A0 =C2=A0clients to detect specif= ic network environments (captive portal,
=C2=A0 =C2=A0split horizon, etc= .) and use that to inform their DNS
=C2=A0 =C2=A0configuration.

<= br>2. Add a sentence to the charter after the work items that says:

= =C2=A0 =C2=A0"This working group is chartered solely to develop techni= cal
=C2=A0 =C2=A0mechanisms. Making any recommendations about specific p= olicies
=C2=A0 =C2=A0for clients and servers is out of scope."
<= br>
I think this would go a long way towards continuing the forms
of = productive engagement we have been seeing (which I agree
there have been= ) while scoping out contentious and unproductive
policy debates.

=

It is good to explicitly roll out po= licies. I would like to clarify whether informational document such as requ= irements or analysis could fit into the scope of technical mechanisms - as = long as they remain out of the policy spectrum of course. I do not have a s= pecific document in mind.

as we have informational= documents in the goals we may specify the the mechanism to be standard.=C2= =A0


=C2=A0=C2=A0
-Ekr


<= br>

On Tue, Feb 4, 2020 at 8:12 AM Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 2/4/20 09:01, Deen, Glenn (NBCUniversal) wrote:
=20 =20 =20

=C2=A0

=C2=A0

On 2/4/20, 4:46 AM, "Add on behalf of Eric Rescorla" <add-bounces@ietf.org on behalf of ekr@rtfm.co= m> wrote:

=C2=A0<= u>

On Tue, Feb 4, 2020 at 4:37 AM Paul Hoffman <paul.hoffman@icann.org> wrote:


>> - develop an informational document that describes how client
>>=C2=A0 applications and systems can manage selection = of DNS resolvers
>>=C2=A0 in various network environments and use cases.=
>=C2=A0
> Here I agree with both EKR and =C3=89ric 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.

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

=C2=A0

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.


While the ADD list and BoFs have certainly not been productive venues for discussions that=E2=80=99s largely attributable to a variety of factors which likely won=E2=80=99t be present in actua= l WG. =C2=A0=C2=A0The ADD list and BoFs have been very broad and wide o= pen, and lacked the focus of a charter, which resulted in unproductive discussions that didn=E2=80=99t progress.=C2=A0 The = WG conversely will have a specific charter to focus it and chairs to help manage the activity.


Thanks. I completely agree that there is useful work that a tightly-scoped charter can foster. I also agree with the implied converse, which is that an insufficiently-tightly-scoped charter will make useful work difficult or impossible.

/a

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add


--
Daniel Migault
Ericsson
--000000000000bb9f91059dc729fe-- From nobody Tue Feb 4 16:42:42 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A94F120072 for ; Tue, 4 Feb 2020 16:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9xLuAMtCIgn for ; Tue, 4 Feb 2020 16:42:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F34120152 for ; Tue, 4 Feb 2020 16:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1580863207; bh=ecObbfLK5Qb1ufn79OgwV4CJNV9xaTKC477YOAxvvFg=; h=X-UI-Sender-Class:From:To:Cc:References:In-Reply-To:Subject:Date; b=UwXKqpL2SwfS52v3KdvtT8/ecW1VprEqOaMeKa4lKUa4gO+2Ihs5qVGGGkNidpvg8 9rP03+MKazkBpDkM4as+KLc1N5Mi/O6B7ysVrAH73scEMYipMX7smEscL5pMr90kOW haD2j0naceF9Jo1JgmbHX7TD0FLWftZly4xEjbrc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from T1650 ([79.241.203.109]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MNKhs-1j9fFF39cQ-00Opx8; Wed, 05 Feb 2020 01:40:07 +0100 From: "Normen B. Kowalewski" To: "'Tommy Pauly'" Cc: "'ADD Mailing list'" , "'Barry Leiba'" , "'Jim Reid'" References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> In-Reply-To: Date: Wed, 5 Feb 2020 01:41:33 +0100 Message-ID: <732A39540B684E93A55BDFC920BABD51@T1650> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AdXbTuYAvJdPHQ3cROef6uABceUUEgAaSX0w X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.24158 X-Provags-ID: V03:K1:CK3yXK8++zxtq5q6i0ysa5aoNyfwuzWHJUQWE3D//W3ssvvY6Qz QH9OpLyZJJMRL73tzp8xtJB60895ykeCHvss8SuGr5r+DZOCRFhiUyMD5tECGEx1veUjHS5 +3P3mqvZwuAoS4dqTN7esUlFTXURYFIspWSo/8nbQuKLERLrM/JIZDbz6QgHIIE/31dsrEy tYyB7I9njdYF1VJH9OHEg== X-UI-Out-Filterresults: notjunk:1;V03:K0:uOfifAoAb5o=:/JsuDCckNzD0acKgBktQBI 9g+IxZEdMlw8PNs91KdF9uLnahVXd7cXZkryzCyImot40I3yFQdWBWLZDc62Eq4QeNR3eyAmz joVG0s9ISD0OzbHE9ZAZU6bUKQM8RAOSrzOfLzZ0vo/Lg/v/hUsovc1VN2TH29xj44JSfrnAq 9klD5QTsaII05DiMwo/7LZHRh/NArx5+nKI7di9pCux8rS6apG6iRwcjWfnpJUw7mjNzMvG9v OODztT0i9U0Ox7yoLrCzttw9NiZbyX6MWy8+BSY/+t6qPioZQd2e3gPLpY7KYw9UMZkUd4Xpc rYceKmQyX1bUQoFEEDR2ONEuTqJBUTxteoeDp9PnqaSz/2RXAnyU55JVbxB36W8ucwIgphrGT MD8TKlkkkTJKE3w3jH1lY2OOpIKXfe8kYQNJ0LyMaY9gG+g3Nnf/E17eNXMszdcw7jZMXf55r 9UsWRUcXkxDSilDf0raWqeSnEsmCsxYHUp6tzkwPpF7DmSp4pMvX22r6Riq0I+cqz1ALLUqyI exWdkdhf9hBuKtFcyOA+CB6k6tkB6Sw6Uz/WgQ2rPwWM1m3UikLy10E57BCRiRRtAt6C9SCC2 ynTuvGzU0TgBwpKyW6WfbocPZHHkpYpApv5Trsaw1d54vOs5uR4Bu/1pD4kiKjjQVZ1hujNq2 QNjoPuAy0kuuppksMCcjU8cu+CYnVhoZP+Gcm1RGeN9YHREeNEOdrR/DspF5+WDTeckvAjI3/ 1kybbbg6CDDroKdQfEtQkU3zFSFtJwhmTT/aqzokGMTG1PDt1RmHqIdhexVGwx/OBbqVylkih 0zpcOwd1YLd/7IymqnpLgRqCpLQhxLYf3v+/7M3tFOOj/v6vLfSAc7kf342OhXNzDovfS4Ftd mU26GZKlsovKNWlXwnTSoqP4AOBwbHXSTkLt2SQia+gOKF/SkMQTUtK9hqAmQ212HBcu8JkNs Vsbyz31iCC4LhYnDQE11ihB0mSIkaZfCUge+OjgmtXXvVeKfYOFkWzrNZEfmCN9FOcOw5/3au qUhZbpAWHRNw0TcqZO3UQCajg7DWLRk3Gj5RJYXrsDyI/FWVRpYIL3I4lzXPgHD3zRrm6Lzsk 8EIgGZYbkAFBj0fcGbCbXxIR6YLs5m+0Vr1DiBAG3jOlD+HtIOfl4zQy+uEhhyrfU7xCe/Cir yyXexZ3jzLZnVmLwT33by/U+30f8/IXN26dl5DtSZmuRJ3s9p05YMyhDBMPpZCx7k1rl6ZkVY MzDZJ5e3ey/iNLxEf Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 00:42:41 -0000 Dear Tommy, and all others, who took the time and effort to refine the charter to = this point, many thanks for your work. I support the charter, and also consider the tweak that Jim has proposed = as useful. With best regards, Normen Kowalewski =20 -----Urspr=FCngliche Nachricht----- Von: Add [mailto:add-bounces@ietf.org] Im Auftrag von Jim Reid Gesendet: Dienstag, 4. Februar 2020 12:33 An: Tommy Pauly Cc: ADD Mailing list; Barry Leiba Betreff: Re: [Add] Charter proposal for ADD With one minor tweak, I support the proposed charter and am willing to = work on the suggested deliverables. Thanks for putting this together Tommy. IMO "develop an informational document that describes how client applications and systems can manage selection of DNS resolvers in = various network environments and use cases=94 might be too ambitious for a = single document. It might be better to say =93develop a set of informational documents..=94 in case it turns out that precisely targeted documents = for specific use cases -- split DNS, enterprise networks, coffee shop = captive portals, home nets lurking behind NAT, etc -- are more digestible than = one document which tries to cover all possible scenarios. The recent comments about avoiding contentious issues in the new WG are = well intentioned. Though I think they=92re been over-stated. Given recent experiences, I very much doubt anyone will be stupid enough to come to = the new WG and propose working on topics that are likely to create trouble and/or fail to make progress. Besides, there would be plenty of = objections (and therefore no consensus) if they tried. Next, if it later transpired some work item did end up drifting into that territory, we should be = able to rely on the WG co-chairs and/or the overseeing AD to intervene and = ensure common sense prevails. It=92s not unknown for IETF WGs to have = contentious or unproductive discussions and charter wording hasn=92t made much = difference to that. -- Add mailing list Add@ietf.org https://www.ietf.org/mailman/listinfo/add From nobody Wed Feb 5 01:39:50 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F611207FC for ; Wed, 5 Feb 2020 01:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ofcom.org.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J22wlemGHICQ for ; Wed, 5 Feb 2020 01:39:46 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100123.outbound.protection.outlook.com [40.107.10.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AF21207FB for ; Wed, 5 Feb 2020 01:39:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NBH73mJvTT6p8KMh/+D5n26WqsK4ueJ6my+4FybEsUeF0pTKC0FpRVqTWZE/OhtbtuCxXtZYdJudVoWzGPymPKsClfnPJY+C6hYg+yfa2t7LwaTmjqfsAiYqsJj/UHzFNyT8VgfM755klqeCO2xHh8say4CyEPDXqQtvzh2TFiW8NuUlZy+pTWZFBiZufmIcMnxMrCg8SS8xh8seC2DaXXoAddXAqmPg9QIAcRQRMtV0y1J0uOU2Ag1zY+TBSRdpxD6ENExDUJq+ZO15XM/62dDk9ufEQzzfS9ZxKZBiF5/QfCGJ3jNPGkUQoCE58oXiDs/drx/ObZIYjPEwtLy86g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0AiSwVjZ2gFdaHpNlmUdTz4kG12JMvdLg5ArbVXlXQY=; b=AijsUGL/1z0/UBchN0RGnS063XswU9pBnl/1g+WnvYZEHSRMQMOkQmNwqYGSf9TOslvI9N5MLeURkNiLZkvqVANSxLhhUSCzOyeRgAyEvUYUbbjjCIxf4lttgWac16269B0eqOdr9i5lJX5ebyNIuEf1fPY1kVHNvSwqD2d+1uFC6XjWy90t/S0m9D00/jX8hrjKMCpVyYtQxqMbL7xVWPEnIhbLV2iHF2Oo11MumnnvteZ7rfZJPC0l1zyxfmfyIfIBdE+v1FHHGsS3VzUBzjTfJBcv1Y9Z8Bj2dlyLzt/T0xC+cwg6Aeyw4ups00zwZwYUhzYYmc6WaIuQoBKY3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ofcom.org.uk; dmarc=pass action=none header.from=ofcom.org.uk; dkim=pass header.d=ofcom.org.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Ofcom.org.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0AiSwVjZ2gFdaHpNlmUdTz4kG12JMvdLg5ArbVXlXQY=; b=McmOzUBb10peQsr/VDM3hLs68Ml66jdXPtu32KqGroWo3iMbMReVAAd8nVhuf0a/jP0h3B5pHzBEm7XApvQ/eUb9FlVei4Z2v2XYVF5X3qQVspTCh2ADxEX1O7zVjEXQUAqcwQMzunX7CEK5rsGwRo3ivsvqpJp1DZVkhcIkQrI= Received: from LNXP123MB1708.GBRP123.PROD.OUTLOOK.COM (20.179.131.76) by LNXP123MB2428.GBRP123.PROD.OUTLOOK.COM (20.176.159.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Wed, 5 Feb 2020 09:39:37 +0000 Received: from LNXP123MB1708.GBRP123.PROD.OUTLOOK.COM ([fe80::4c2f:9229:598c:84e9]) by LNXP123MB1708.GBRP123.PROD.OUTLOOK.COM ([fe80::4c2f:9229:598c:84e9%3]) with mapi id 15.20.2686.035; Wed, 5 Feb 2020 09:39:37 +0000 From: Patrick Tarpey To: "add@ietf.org" Thread-Topic: ADD Charter +1 Thread-Index: AdXcB9DglBi8KU8VQFWwwkhC5UHZjw== Date: Wed, 5 Feb 2020 09:39:37 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Enabled=True; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_SiteId=0af648de-310c-4068-8ae4-f9418bae24cc; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Owner=Patrick.Tarpey@ofcom.org.uk; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_SetDate=2020-02-05T09:37:11.1995074Z; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Name=Protected; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Application=Microsoft Azure Information Protection; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_ActionId=4bfe3af7-e650-4697-be20-6c7ef90f38a8; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Extended_MSFT_Method=Manual authentication-results: spf=none (sender IP is ) smtp.mailfrom=Patrick.Tarpey@ofcom.org.uk; x-originating-ip: [86.173.103.176] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14af8931-ed4a-4646-c86e-08d7aa1f50eb x-ms-traffictypediagnostic: LNXP123MB2428: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2150; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(376002)(396003)(136003)(39850400004)(366004)(199004)(189003)(316002)(71200400001)(8936002)(81156014)(15974865002)(81166006)(8676002)(33656002)(7696005)(52536014)(5660300002)(66446008)(66946007)(66476007)(66556008)(76116006)(64756008)(2906002)(6506007)(26005)(478600001)(9686003)(86362001)(186003)(55016002)(7116003)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:LNXP123MB2428; H:LNXP123MB1708.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ofcom.org.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: m5ONecLvQG64qXxSVNIdURflZ44p5UgYXUslIis9/yrdqLN6Tx8fRKzAs2r3i1/zda5wKaEXXa3/tyqkPuQgEdR83UDzqeQIh7ws8A34R71Ob9K/7L3SsfPawJmnN6rLf69KmZXURvRcVwdZd26y9W4fdKsjklVgZKCV+jPOKLpEm6pRoGrzJk9ONhZXCzhw7VTqEVGnQFvGWY6m9ox8DCbmTnk5FS8+RuMXaW9lODf6rGEraaC5gqgsGSsbGTHvZ43Xf/4uWsrZ+7XR9l2vhG9G1615fI13yep6c0ZXLjD9gEShCHGCHYH58WHD09h7+V0p6gxGuKbhCPWW39A8+l9wbK42Z1CVFtQFkN5+0GG9C0Sfi0F33zpamM2RyJzPX7PCROD5oCB6tRyET3QKqc/2ijyi+toxKCD5mep1eN1r60Ep9/FbwLTEfLx1Y2F1Esek1IGDt/B3p2Fq7pWnt17e7BjjZ/mwd+yKBlcTiPN38qm4xNldRHTyHrXCz2/JWA7C1rY16njBxGbpDML9Aw== x-ms-exchange-antispam-messagedata: 4OwblYyWLt+f5LOXw+uKbcZWb2N8ju5Gla8B7nOfWtw0HcRunUC6FFpBGYJOcJJzB0DPc1RtDJ9c3GhRKkZxFdXB7fdoXvYpFbNF85JvD33VSgADiQEiJFkTGCdcJLTZZTzXSH0RgONhfHbFRgDgNQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LNXP123MB1708D6891A6F94A1310062FAA5020LNXP123MB1708GBRP_" MIME-Version: 1.0 X-OriginatorOrg: Ofcom.org.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 14af8931-ed4a-4646-c86e-08d7aa1f50eb X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 09:39:37.3422 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0af648de-310c-4068-8ae4-f9418bae24cc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NqfAhtALzAFvwh93sr6th6kiOgyiGPsnHqakUFX8TKOYJfHpiiGq/duLMCFqUWhHr73bTSz0tkS8PKxYkG63Z/yjnmH1PqBOw1Pl+3oex04= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB2428 Archived-At: Subject: [Add] ADD Charter +1 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 09:39:48 -0000 --_000_LNXP123MB1708D6891A6F94A1310062FAA5020LNXP123MB1708GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are supportive of the ADD Working Group Charter. Pat :: Patrick Tarpey Technical Advisor 020 7981 3240 07834432016 patrick.tarpey@ofcom.org.uk :: Ofcom Riverside House 2a Southwark Bridge Road London SE1 9HA 020 7981 3000 www.ofcom.org.uk ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_LNXP123MB1708D6891A6F94A1310062FAA5020LNXP123MB1708GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are supportive of the ADD Working Group Charter.<= o:p>

 

Pat<= /o:p>

&nbs= p;

:: Patrick Tarpey 
Technical Advisor 
020 7981 3240 
07834432016=  
pa= trick.tarpey@ofcom.org.uk 
 <= /b> 
 <= /b> 
:: Ofcom 
Riverside House 
2a Southwark Bridge Road 
London SE1 9HA 
020 7981 3000 
www.of= com.org.uk

&nbs= p;

 



***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************
 --_000_LNXP123MB1708D6891A6F94A1310062FAA5020LNXP123MB1708GBRP_-- From nobody Wed Feb 5 04:19:58 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26B71200F7 for ; Wed, 5 Feb 2020 04:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kJGU4tUWfBC for ; Wed, 5 Feb 2020 04:19:54 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986B9120073 for ; Wed, 5 Feb 2020 04:19:53 -0800 (PST) Received: from [100.113.1.39] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta.az-a.eu-central-1.aws.symcld.net id 8C/F2-20890-1E2BA3E5; Wed, 05 Feb 2020 12:19:45 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJsWRWlGSWpSXmKPExsWi75kzV/fhJqs 4g5d9Uhb/T69jszjVv4rdgcnjxLIrrB5LlvxkCmCKYs3MS8qvSGDN+PL5FktBU1TFhp8H2RsY /wZ3MXJxCAlsY5TYvreHCcI5xChx+PFGdrhM4/t7rBDOBUaJhh3ToZwJTBIX765ihnDuMUrs+ fqHsYuRk4NNwF7i0roXrCC2iECixMKWv2BxYQFpibmNN9kh4jISv26vh7KNJHbsf8wGYrMIqE h0PO0F6+UViJFYdHYuC4gtJBAt0X75A5jNCRS/vvweWC+jgKzEl8bVzCA2s4C4xK0n85lAbAk BAYkle84zQ9iiEi8f/wO7mldgBafE7M2/GCGaoyR2PutggyhSkFhy6TyULStxaX43I4TtK/Hg 7k8gmwPI1pJY8t8YIpwtsWPtLKgSNYnt185D7ZWRaHlwBhyQEgL9LBJ3lp5hhXggRWLuxm3sE EVyEqt6H7LANDy4sZ1tAqPRLCQ/QNh5Em2df5hngcNCUOLkzCcsEHEdiQW7P7FB2NoSyxa+Zo axzxx4zIQsvoCRfRWjZVJRZnpGSW5iZo6uoYGBrqGhsS6QNLXQS6zSTdRLLdVNTs0rKUoEyuo llhfrFVfmJuek6OWllmxiBCawlEKGeTsYZ699r3eIUZKDSUmUl7vbKk6ILyk/pTIjsTgjvqg0 J7X4EKMMB4eSBK8mMCUKCRalpqdWpGXmAJMpTFqCg0dJhFceJM1bXJCYW5yZDpE6xejKMeHl3 EXMHO9+LgaSH1ctAZLfweTN90BSiCUvPy9VSpw3YiNQswBIc0ZpHtxoWCa4xCgrJczLyMDAIM RTkFqUm1mCKv+KUZyDUUmYlxdkCk9mXgncBa+AjmMCOk7a2wLkuJJEhJRUA1PbrAdOlw1EK2f enmWyq0ftHNfd7MAgjV8lc7Puvtig+S5SdpJPVt/S3q+NR2dmPy75vUCK4dd1ofuxM1737i8w f/3A6cu7ZwaRLz6wC3lwvdmaXrfD+b+z738J/Se3Cu8EuO+Oj9zqxfh6fYbYdtG9d3aujNV21 fLcebnmp8e05D8BP1KO/Sq4zOu8gafxxoktbkJhKybeLNp3OnTe5LoZlsJM638Ydcqv/LLXvV FUPNx1fth+l6kdLI3FBZUHsqpkVrb3z1Wwkyla+G5dipam8tWAo9m37hqlxj2smBNUcMR0Oy9 XbsCBbzOaJ2yJcDxy50Gq9L6jYS6mTK6HPRvznjWH/TNdw3AgrnJRdLMSS3FGoqEWc1FxIgBb yiaTfwQAAA== X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-31.tower-232.messagelabs.com!1580905182!1934374!8 X-Originating-IP: [47.73.108.157] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.44.25; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32294 invoked from network); 5 Feb 2020 12:19:45 -0000 Received: from vgdpm15vr.vodafone.com (HELO voxe02hw.internal.vodafone.com) (47.73.108.157) by server-31.tower-232.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 5 Feb 2020 12:19:45 -0000 Received: from VOEXH10W.internal.vodafone.com (47.73.211.214) by edge1.vodafone.com (195.232.244.47) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Feb 2020 13:19:44 +0100 Received: from voxe05hw.internal.vodafone.com (195.232.244.50) by VOEXH10W.internal.vodafone.com (47.73.211.208) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Feb 2020 13:19:43 +0100 Received: from VOEXH09W.internal.vodafone.com (47.73.211.213) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Feb 2020 13:19:41 +0100 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (172.17.213.40) by VOEXH09W.internal.vodafone.com (47.73.211.213) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Feb 2020 13:19:40 +0100 Received: from DB7PR05MB4313.eurprd05.prod.outlook.com (52.134.107.138) by DB7PR05MB4299.eurprd05.prod.outlook.com (52.134.108.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Wed, 5 Feb 2020 12:19:40 +0000 Received: from DB7PR05MB4313.eurprd05.prod.outlook.com ([fe80::a54b:81fe:4cc1:3627]) by DB7PR05MB4313.eurprd05.prod.outlook.com ([fe80::a54b:81fe:4cc1:3627%7]) with mapi id 15.20.2686.035; Wed, 5 Feb 2020 12:19:40 +0000 From: "Smith, Kevin, Vodafone Group" To: Patrick Tarpey , "add@ietf.org" Thread-Topic: ADD Charter +1 Thread-Index: AdXcB9DglBi8KU8VQFWwwkhC5UHZjwAFnqew Date: Wed, 5 Feb 2020 12:19:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Enabled=True; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Extended_MSFT_Method=Automatic; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Application=Microsoft Azure Information Protection; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Name=C2 General; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SetDate=2020-02-05T12:19:38.4194676Z; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Owner=Kevin.Smith@vodafone.com; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SiteId=68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Enabled=True; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_SiteId=0af648de-310c-4068-8ae4-f9418bae24cc; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Owner=Patrick.Tarpey@ofcom.org.uk; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_SetDate=2020-02-05T09:37:11.1995074Z; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Name=Protected; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Application=Microsoft Azure Information Protection; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Extended_MSFT_Method=Manual; Sensitivity=C2 General Protected x-originating-ip: [47.73.248.29] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a591f163-fcc7-4e63-36f6-08d7aa35ac9e x-ms-traffictypediagnostic: DB7PR05MB4299: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(39860400002)(376002)(396003)(136003)(189003)(199004)(7696005)(86362001)(66946007)(66556008)(8676002)(81166006)(66446008)(76116006)(64756008)(81156014)(26005)(6506007)(53546011)(66476007)(478600001)(52536014)(316002)(110136005)(2906002)(33656002)(8936002)(9686003)(55016002)(71200400001)(7116003)(5660300002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB4299; H:DB7PR05MB4313.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: vodafone.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HpaGkkUmIyCSUd2fbRV7bVjXVAUHBL5NUl1clCFaOBa1U7saopqtOmw3utxtMbpjK8hab5uc2OsJD/nSFO/JeOuIdE7McDGZQUPoYl9ZglYdildN8KZ1O9exnDImZq0j7DLS01cWYMFCICYAo/0EtUjmjzChJIGf71Qs86iXywlANkW+1JCbkkdYXfQVzHx+wV+bQW5f72Jf53hbApMn9a/tuJgBArgs8ypjzHYtf3pZEc3RGPgpnryCuaD2V6Wz08Z5HZufQ1Rf4DhIrAXOK1imewQV+DsTgPtlOyPAWzHz5zWPbfLuQZm46qhdhQSiRYAY8tBhOo2ljLVWCEAaaENUGNde1VuIFWtQ9XzPlWbCSt2cZt1yMCT8KqYYQtUfm1V/Jg/C636+ymqsm7QlLk/MeOg6qtu/bWIAvEozfLia8rFwBgq9qWhB8CnC1e8oF90THpbD2vnsGwLzm8/4CHcWGMtZKGLiQqCYtaAQv6K0Yi7TtyhGkurQDAO/RwrNNDZCm6pTeKpXe/SFiIshsw== x-ms-exchange-antispam-messagedata: IFFQqhSQFBXgZAdWF4c8MTOs379YYQCzxzytY49avnZFHLanVzQMg0AafU9FQFlc71Ggs150zx1LKz3cXzyc92EGRzpAzv+wOpMuUsKKkgRpzOX8udW7uaHdiTYECJeRvL0wjwkE3abXFBR6wJsDBw== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=im9fkpTq+SMN6aOuvtKkxydlAYQgvfrLeNwsY4Ruy6DcwmVfm5eDekahvAz/WBi02z0q1KbD2aTw6vHIJyOElTfHCwWXBI6POS/z0IWZChevnumdSY/j56vUOyGo4+8AHgsBgoBJIiZjssM9kiDYFhoGdR/UxfRsjc09eXC9YsfskYA2L7BnQzldH1fGfP9j5U7GpEetuaxDDVK3bEujnyv1RygzpveuMvRQPo90dD7lZ02+h34GTWVmHZt7lcxXxOcm1nVWGIPfux9id2j0WfsaeFZ/nBZKNbNg5s7y33zLr3ahLxizEZmohdk58CrjaTLgk7X5ZFM9u8bjICB+FA== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/hTVw6eKKMzjRjji9Sz93+R2812IT17gbZR7UAd63zk=; b=asUR7cfB1FS2AHkk2Oxg6gQ6Aj485CF7XI0uLxs5kOR8I8JP4b6vK429dMxbdu1wwMedJvBtF9AtsTjbBrXwlezy+fFR/y4f2xDk5mNwVgyB/BgaOzYTEWXSSUDqhv/aHOz4GnlXqA4JsIedXCrwsRFx1/DxKePPzDwAFs4Px29bb7V3XejIN8b7nNY1nR5oSiKJZAgw2Mmh+zWR6jErJ8dVS6ePu/Ldv94C+iDkp+xAlc4EwHX42DBPXllfZlINNnNfNp7BtSvtLav043Zz5anyHy7aDtiE9g1rq5F9zJghnQgAimy0A0/my63wT4ptOVc03rEWfr1xy2A1ToTznQ== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vodafone.com; dmarc=pass action=none header.from=vodafone.com; dkim=pass header.d=vodafone.com; arc=none x-ms-exchange-crosstenant-network-message-id: a591f163-fcc7-4e63-36f6-08d7aa35ac9e x-ms-exchange-crosstenant-originalarrivaltime: 05 Feb 2020 12:19:40.1223 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: n6znKkAj/RQoAjZB1qya4Nci+jgXK9UBwd42qU0b9frG2iM8TuhD/ivftjniLhQWagNBORnLASo6GQeXQ5pgLr2SZEMJy4JItpHoWRC+OnU= x-ms-exchange-transport-crosstenantheadersstamped: DB7PR05MB4299 Content-Type: multipart/alternative; boundary="_000_DB7PR05MB4313C2F37D271F19DAA87F6891020DB7PR05MB4313eurp_" MIME-Version: 1.0 X-OriginatorOrg: vodafone.com X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Add] ADD Charter +1 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 12:19:56 -0000 --_000_DB7PR05MB4313C2F37D271F19DAA87F6891020DB7PR05MB4313eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And a +1 from me to the charter text incorporating EKR's comments (subseque= ntly accepted by Tommy) Kevin C2 General From: Add On Behalf Of Patrick Tarpey Sent: 05 February 2020 09:40 To: add@ietf.org Subject: [Add] ADD Charter +1 We are supportive of the ADD Working Group Charter. Pat :: Patrick Tarpey Technical Advisor 020 7981 3240 07834432016 patrick.tarpey@ofcom.org.uk :: Ofcom Riverside House 2a Southwark Bridge Road London SE1 9HA 020 7981 3000 www.ofcom.org.uk ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_DB7PR05MB4313C2F37D271F19DAA87F6891020DB7PR05MB4313eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And a +1 from me t= o the charter text incorporating EKR’s comments (subsequently accepte= d by Tommy)

 

Kevin

 

 

= C2 General

From: Add <add-bounces@ietf.org> On Behalf Of Patrick Tarpey
Sent: 05 February 2020 09:40
To: add@ietf.org
Subject: [Add] ADD Charter +1

 

We are supportive of the ADD Working Group Charter.<= o:p>

 

Pat<= /o:p>

&nbs= p;

:: Patrick Tarpey 
Technical Advisor 
020 7981 3240 
07834432016=  
pa= trick.tarpey@ofcom.org.uk 
 <= /b> 
 <= /b> 
:: Ofcom 
Riverside House 
2a Southwark Bridge Road 
London SE1 9HA 
020 7981 3000 
www.of= com.org.uk

&nbs= p;

 

 


***************************************************************************= ***************************************
For more information visit www.ofcom.or= g.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= *************************************** X-Mailman-Approved-At: Wed, 05 Feb 2020 05:31:59 -0800 Subject: Re: [Add] [EXTERNAL] Re: [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 08:58:39 -0000 --_000_LO2P123MB2573ACF823EE39248D696794FE020LO2P123MB2573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgb24gdGhlIHByb3Bvc2VkIGFtZW5kbWVudCBiZWxvdw0KDQpJIGFsc28gZmVlbCBKaW0gUmVp ZOKAmXMgc3VnZ2VzdGlvbiBvZiBtYWtpbmcgdGhlIGZpcnN0IHBhcmFncmFwaCByZWFkIOKAnGRl dmVsb3AgYSBzZXQgb2YgaW5mb3JtYXRpb25hbCBkb2N1bWVudHMuLuKAnSBhZGRzIHZhbHVlIHRv bw0KDQpSZWdhcmRzDQoNCkJvYg0KDQpGcm9tOiBBZGQgPGFkZC1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgQW5kcmV3IENhbXBsaW5nDQpTZW50OiAwNCBGZWJydWFyeSAyMDIwIDE4OjI1 DQpUbzogVG9tbXkgSmVuc2VuIDxKZW5zZW4uVGhvbWFzQG1pY3Jvc29mdC5jb20+OyBEZWVuLCBH bGVubiAoTkJDVW5pdmVyc2FsKSA8R2xlbm4uRGVlbkBuYmN1bmkuY29tPjsgVG9tbXkgUGF1bHkg PHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZz47IEFkYW0gUm9hY2ggPGFkYW1Abm9z dHJ1bS5jb20+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBFcmljIFJlc2NvcmxhIDxl a3JAcnRmbS5jb20+OyBBREQgTWFpbGluZyBsaXN0IDxhZGRAaWV0Zi5vcmc+OyBQYXVsIEhvZmZt YW4gPHBhdWwuaG9mZm1hbkBpY2Fubi5vcmc+OyBhZGQtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW0FkZF0gW0VYVEVSTkFMXSBSZTogW0V4dF0gQWRhbSBSb2FjaCdzIE5vIE9iamVjdGlv biBvbiBjaGFydGVyLWlldGYtYWRkLTAwLTAwOiAod2l0aCBDT01NRU5UKQ0KDQpBbm90aGVyICsx IOKAkyBhIGhlbHBmdWwgY2hhbmdlIGlmIHRoaXMgcHJvdmlkZXMgcmVhc3N1cmFuY2UgdGhhdCB0 aGVyZSBpcyBubyBpbnRlbmRlZCBtaXNzaW9uIGNyZWVwIGFuZCBwcm92aWRlcyB0aGUgYmFzaXMg Zm9yIHRoZSB3b3JraW5nIGdyb3VwIGNoYXJ0ZXJpbmcgcHJvY2VzcyB0byBtb3ZlIGZvcndhcmQu DQoNCkFuZHJldw0KDQpGcm9tOiBUb21teSBKZW5zZW4gPEplbnNlbi5UaG9tYXNAbWljcm9zb2Z0 LmNvbTxtYWlsdG86SmVuc2VuLlRob21hc0BtaWNyb3NvZnQuY29tPj4NClNlbnQ6IDA0IEZlYnJ1 YXJ5IDIwMjAgMTg6MjENClRvOiBEZWVuLCBHbGVubiAoTkJDVW5pdmVyc2FsKSA8R2xlbm4uRGVl bkBuYmN1bmkuY29tPG1haWx0bzpHbGVubi5EZWVuQG5iY3VuaS5jb20+PjsgVG9tbXkgUGF1bHkg PHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86dHBhdWx5PTQwYXBwbGUu Y29tQGRtYXJjLmlldGYub3JnPj47IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb208bWFpbHRv OmFkYW1Abm9zdHJ1bS5jb20+Pg0KQ2M6IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWls dG86ZWtyQHJ0Zm0uY29tPj47IGFkZC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmFkZC1jaGFpcnNA aWV0Zi5vcmc+OyBQYXVsIEhvZmZtYW4gPHBhdWwuaG9mZm1hbkBpY2Fubi5vcmc8bWFpbHRvOnBh dWwuaG9mZm1hbkBpY2Fubi5vcmc+PjsgQUREIE1haWxpbmcgbGlzdCA8YWRkQGlldGYub3JnPG1h aWx0bzphZGRAaWV0Zi5vcmc+PjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dA aWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtBZGRdIFtFWFRFUk5BTF0gUmU6IFtFeHRdIEFkYW0g Um9hY2gncyBObyBPYmplY3Rpb24gb24gY2hhcnRlci1pZXRmLWFkZC0wMC0wMDogKHdpdGggQ09N TUVOVCkNCg0KKzEsIHRoZSBzcGlyaXQgb2Ygd2hhdCBJIHdhbnQgZnJvbSB0aGUgY2hhcnRlciBp cyBwcmVzZXJ2ZWQuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBB ZGQgPGFkZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphZGQtYm91bmNlc0BpZXRmLm9yZz4+IG9u IGJlaGFsZiBvZiBEZWVuLCBHbGVubiAoTkJDVW5pdmVyc2FsKSA8R2xlbm4uRGVlbkBuYmN1bmku Y29tPG1haWx0bzpHbGVubi5EZWVuQG5iY3VuaS5jb20+Pg0KU2VudDogVHVlc2RheSwgRmVicnVh cnkgNCwgMjAyMCAxMDowNCBBTQ0KVG86IFRvbW15IFBhdWx5IDx0cGF1bHk9NDBhcHBsZS5jb21A ZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZz4+ OyBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0uY29tPj4N CkNjOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+OyBE ZWVuLCBHbGVubiAoTkJDVW5pdmVyc2FsKSA8R2xlbm4uRGVlbkBuYmN1bmkuY29tPG1haWx0bzpH bGVubi5EZWVuQG5iY3VuaS5jb20+PjsgYWRkLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86YWRkLWNo YWlyc0BpZXRmLm9yZz4gPGFkZC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmFkZC1jaGFpcnNAaWV0 Zi5vcmc+PjsgUGF1bCBIb2ZmbWFuIDxwYXVsLmhvZmZtYW5AaWNhbm4ub3JnPG1haWx0bzpwYXVs LmhvZmZtYW5AaWNhbm4ub3JnPj47IEFERCBNYWlsaW5nIGxpc3QgPGFkZEBpZXRmLm9yZzxtYWls dG86YWRkQGlldGYub3JnPj47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGll dGYub3JnPj4NClN1YmplY3Q6IFJlOiBbQWRkXSBbRVhURVJOQUxdIFJlOiBbRXh0XSBBZGFtIFJv YWNoJ3MgTm8gT2JqZWN0aW9uIG9uIGNoYXJ0ZXItaWV0Zi1hZGQtMDAtMDA6ICh3aXRoIENPTU1F TlQpDQoNCg0KDQrvu79PbiAyLzQvMjAsIDk6NTYgQU0sICJBZGQgb24gYmVoYWxmIG9mIFRvbW15 IFBhdWx5IiA8YWRkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRwYXVseT00MGFwcGxl LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86YWRkLWJvdW5jZXNAaWV0Zi5vcmclMjBvbiUyMGJl aGFsZiUyMG9mJTIwdHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoN Cg0KDQogICAgPiBPbiBGZWIgNCwgMjAyMCwgYXQgODo0MSBBTSwgQWRhbSBSb2FjaCA8YWRhbUBu b3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+IHdyb3RlOg0KICAgID4NCiAgICA+ IE9uIDIvNC8yMCAxMDozNywgRXJpYyBSZXNjb3JsYSB3cm90ZToNCiAgICA+PiBJbiB0aGUgaW50 ZXJlc3Qgb2YgdHJ5aW5nIHRvIG1vdmUgZm9yd2FyZC4uLi4NCiAgICA+Pg0KICAgID4+IEkgYWdy ZWUgdGhhdCB0aGVyZSBhcmUgYSBidW5jaCBvZiB0cmlja3kgbmV0d29yayBzY2VuYXJpb3MgdGhh dA0KICAgID4+IG5lZWQgdG8gYmUgaGFuZGxlZCAoY2FwdGl2ZSBwb3J0YWxzLCBWUE5zLCBzcGxp dCBETlMsIGV0Yy4pIGFuZA0KICAgID4+IHRoYXQgcHJvdmlkaW5nIHNvbWUgZ3VpZGFuY2UgaGVy ZSB3b3VsZCBiZSB1c2VmdWwuIFdoYXQgSSdtIHRyeWluZw0KICAgID4+IHRvIGF2b2lkIGlzIHRo YXQgYmxlZWRpbmcgaW50byBhIGxvdCBvZiBkZWJhdGluZyBhYm91dCBwb2xpY3kgYW5kDQogICAg Pj4gaG93IHBhcnRpY3VsYXIgY2xpZW50cyBvdWdodCB0byBiZWhhdmUuIFdpdGggdGhhdCBpbiBt aW5kLA0KICAgID4+IGhlcmUgaXMgd2hhdCBJIHN1Z2dlc3Q6DQogICAgPj4NCiAgICA+PiAxLiBS ZXZpc2UgdGhhdCBidWxsZXQgdG8gYmUgbW9yZSBjbGVhcmx5IHRlY2huaWNhbDoNCiAgICA+Pg0K ICAgID4+ICAgIC0gZGV2ZWxvcCBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRoYXQgZGVzY3Jp YmVzIG1lY2hhbmlzbXMgZm9yDQogICAgPj4gICAgY2xpZW50cyB0byBkZXRlY3Qgc3BlY2lmaWMg bmV0d29yayBlbnZpcm9ubWVudHMgKGNhcHRpdmUgcG9ydGFsLA0KICAgID4+ICAgIHNwbGl0IGhv cml6b24sIGV0Yy4pIGFuZCB1c2UgdGhhdCB0byBpbmZvcm0gdGhlaXIgRE5TDQogICAgPj4gICAg Y29uZmlndXJhdGlvbi4NCiAgICA+Pg0KICAgID4+DQogICAgPj4gMi4gQWRkIGEgc2VudGVuY2Ug dG8gdGhlIGNoYXJ0ZXIgYWZ0ZXIgdGhlIHdvcmsgaXRlbXMgdGhhdCBzYXlzOg0KICAgID4+DQog ICAgPj4gICAgIlRoaXMgd29ya2luZyBncm91cCBpcyBjaGFydGVyZWQgc29sZWx5IHRvIGRldmVs b3AgdGVjaG5pY2FsDQogICAgPj4gICAgbWVjaGFuaXNtcy4gTWFraW5nIGFueSByZWNvbW1lbmRh dGlvbnMgYWJvdXQgc3BlY2lmaWMgcG9saWNpZXMNCiAgICA+PiAgICBmb3IgY2xpZW50cyBhbmQg c2VydmVycyBpcyBvdXQgb2Ygc2NvcGUuIg0KICAgID4+DQogICAgPj4NCiAgICA+PiBJIHRoaW5r IHRoaXMgd291bGQgZ28gYSBsb25nIHdheSB0b3dhcmRzIGNvbnRpbnVpbmcgdGhlIGZvcm1zDQog ICAgPj4gb2YgcHJvZHVjdGl2ZSBlbmdhZ2VtZW50IHdlIGhhdmUgYmVlbiBzZWVpbmcgKHdoaWNo IEkgYWdyZWUNCiAgICA+PiB0aGVyZSBoYXZlIGJlZW4pIHdoaWxlIHNjb3Bpbmcgb3V0IGNvbnRl bnRpb3VzIGFuZCB1bnByb2R1Y3RpdmUNCiAgICA+PiBwb2xpY3kgZGViYXRlcy4NCiAgICA+DQog ICAgPg0KICAgID4gVGhhbmtzLiBUaGlzIGNyb3NzZWQgb24gdGhlIHdpcmUgd2l0aCBteSBwcmV2 aW91cyBtZXNzYWdlLCBhbmQgSSB0aGluayBpdCdzIGEgZ29vZCBleGFtcGxlIG9mIHRoZSBraW5k cyBvZiBndWlkZXJhaWxzIEkgd2FzIGNhbGxpbmcgZm9yLg0KDQogICAgKzENCg0KICAgIEkgdGhp bmsgYm90aCBvZiB0aGVzZSB0ZXh0dWFsIGNoYW5nZXMgYXJlIGFwcHJvcHJpYXRlLCBhbmQgY2xh cmlmeSB0aGUgaW50ZW50IG9mIHRoZSBjaGFydGVyLCB3aXRob3V0IHVuZHVseSBjb25zdHJhaW5p bmcgdGhlIHRlY2huaWNhbCB3b3JrIG9mIGEgZ3JvdXAuIEkgc3VwcG9ydCBwZXJmb3JtaW5nIGJv dGggb2YgdGhlc2UgY2hhbmdlcyENCg0KICAgIFRoYW5rcyBla3IgZm9yIHRoZSBzdWdnZXN0aW9u cy4NCg0KICAgIEJlc3QsDQogICAgVG9tbXkNCg0KKzENCg0KSSBhbHNvIGRvbid0IGhhdmUgYW55 IGhlYXJ0YnVybiB3aXRoIGVpdGhlciBvZiB0aGUgc3VnZ2VzdGVkIGNoYW5nZXMuIFRoZXkgY2xh cmlmeSB0aGUgbWlzc2lvbiB3aGlsZSBrZWVwaW5nIHRoZSBjaGFydGVyIGNsZWFuIGVub3VnaCB0 aGF0IGl0J3Mgc2ltcGxlIHRvIHJlYWQgYW5kIHVuZGVyc3RhbmQuDQoNCi1nbGVubg0KDQogICAg LS0NCiAgICBBZGQgbWFpbGluZyBsaXN0DQogICAgQWRkQGlldGYub3JnPG1haWx0bzpBZGRAaWV0 Zi5vcmc+DQogICAgaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG YWRkJmFtcDtkYXRhPTAyJTdDMDElN0NKZW5zZW4uVGhvbWFzJTQwbWljcm9zb2Z0LmNvbSU3QzQ0 MjNlZDVlYmU1NzQ2NzE4MTg2MDhkN2E5OWNiNjgyJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE2NDM2Mjg5NDA0Mzc4OCZhbXA7c2RhdGE9MERzTGlLJTJG Z09EdVZCT0JNdjE5NWhGbEd6bDFBT2thd3ZRazNlUkwlMkZTQjAlM0QmYW1wO3Jlc2VydmVkPTAN Cg0KDQotLQ0KQWRkIG1haWxpbmcgbGlzdA0KQWRkQGlldGYub3JnPG1haWx0bzpBZGRAaWV0Zi5v cmc+DQpodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZhZGQmYW1w O2RhdGE9MDIlN0MwMSU3Q0plbnNlbi5UaG9tYXMlNDBtaWNyb3NvZnQuY29tJTdDNDQyM2VkNWVi ZTU3NDY3MTgxODYwOGQ3YTk5Y2I2ODIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM3MTY0MzYyODk0MDQzNzg4JmFtcDtzZGF0YT0wRHNMaUslMkZnT0R1VkJP Qk12MTk1aEZsR3psMUFPa2F3dlFrM2VSTCUyRlNCMCUzRCZhbXA7cmVzZXJ2ZWQ9MA0K --_000_LO2P123MB2573ACF823EE39248D696794FE020LO2P123MB2573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiYjNDM7 MSBvbiB0aGUgcHJvcG9zZWQgYW1lbmRtZW50IGJlbG93PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgYWxzbyBmZWVsIEppbSBS ZWlk4oCZcyBzdWdnZXN0aW9uIG9mIG1ha2luZyB0aGUgZmlyc3QgcGFyYWdyYXBoIHJlYWQNCjwv c3Bhbj7igJxkZXZlbG9wIGEgc2V0IG9mIGluZm9ybWF0aW9uYWwgZG9jdW1lbnRzLi48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPuKAnSBhZGRzIHZhbHVlIHRvbzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Qm9iPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBBZGQgJmx0O2FkZC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwv Yj5BbmRyZXcgQ2FtcGxpbmc8YnI+DQo8Yj5TZW50OjwvYj4gMDQgRmVicnVhcnkgMjAyMCAxODoy NTxicj4NCjxiPlRvOjwvYj4gVG9tbXkgSmVuc2VuICZsdDtKZW5zZW4uVGhvbWFzQG1pY3Jvc29m dC5jb20mZ3Q7OyBEZWVuLCBHbGVubiAoTkJDVW5pdmVyc2FsKSAmbHQ7R2xlbm4uRGVlbkBuYmN1 bmkuY29tJmd0OzsgVG9tbXkgUGF1bHkgJmx0O3RwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRm Lm9yZyZndDs7IEFkYW0gUm9hY2ggJmx0O2FkYW1Abm9zdHJ1bS5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7IEVyaWMgUmVzY29ybGEgJmx0O2Vr ckBydGZtLmNvbSZndDs7IEFERCBNYWlsaW5nIGxpc3QgJmx0O2FkZEBpZXRmLm9yZyZndDs7IFBh dWwgSG9mZm1hbiAmbHQ7cGF1bC5ob2ZmbWFuQGljYW5uLm9yZyZndDs7IGFkZC1jaGFpcnNAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBZGRdIFtFWFRFUk5BTF0gUmU6IFtFeHRd IEFkYW0gUm9hY2gncyBObyBPYmplY3Rpb24gb24gY2hhcnRlci1pZXRmLWFkZC0wMC0wMDogKHdp dGggQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+QW5vdGhlciAmIzQzOzEg4oCTIGEgaGVscGZ1bCBjaGFuZ2UgaWYgdGhpcyBwcm92aWRlcyBy ZWFzc3VyYW5jZSB0aGF0IHRoZXJlIGlzIG5vIGludGVuZGVkIG1pc3Npb24gY3JlZXAgYW5kIHBy b3ZpZGVzIHRoZSBiYXNpcyBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgY2hhcnRlcmluZyBwcm9jZXNz IHRvIG1vdmUgZm9yd2FyZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5BbmRyZXcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBUb21teSBKZW5zZW4gJmx0 Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86SmVuc2VuLlRob21hc0BtaWNyb3NvZnQuY29tIj48c3Bh biBsYW5nPSJFTi1VUyI+SmVuc2VuLlRob21hc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDA0IEZlYnJ1YXJ5IDIwMjAg MTg6MjE8YnI+DQo8Yj5Ubzo8L2I+IERlZW4sIEdsZW5uIChOQkNVbml2ZXJzYWwpICZsdDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOkdsZW5uLkRlZW5AbmJjdW5pLmNvbSI+PHNwYW4gbGFuZz0iRU4t VVMiPkdsZW5uLkRlZW5AbmJjdW5pLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDs7IFRvbW15IFBhdWx5ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRwYXVseT00MGFwcGxl LmNvbUBkbWFyYy5pZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPnRwYXVseT00MGFwcGxlLmNv bUBkbWFyYy5pZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs7DQogQWRh bSBSb2FjaCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIj48c3Bh biBsYW5nPSJFTi1VUyI+YWRhbUBub3N0cnVtLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4t VVMiPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0Ozwvc3Bhbj48YSBocmVm PSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj48c3BhbiBsYW5nPSJFTi1VUyI+ZWtyQHJ0Zm0uY29tPC9z cGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OzsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 YWRkLWNoYWlyc0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPmFkZC1jaGFpcnNAaWV0Zi5v cmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj47IFBhdWwgSG9mZm1hbiAmbHQ7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpwYXVsLmhvZmZtYW5AaWNhbm4ub3JnIj48c3BhbiBsYW5nPSJFTi1V UyI+cGF1bC5ob2ZmbWFuQGljYW5uLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDs7IEFERCBNYWlsaW5nDQogbGlzdCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzphZGRAaWV0 Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIj5hZGRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7OyBUaGUgSUVTRyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZXNn QGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+aWVzZ0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBZGRdIFtFWFRF Uk5BTF0gUmU6IFtFeHRdIEFkYW0gUm9hY2gncyBObyBPYmplY3Rpb24gb24gY2hhcnRlci1pZXRm LWFkZC0wMC0wMDogKHdpdGggQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxLCB0aGUgc3Bpcml0IG9mIHdoYXQgSSB3YW50 IGZyb20gdGhlIGNoYXJ0ZXIgaXMgcHJlc2VydmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246 Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2 Pg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiBBZGQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86YWRkLWJvdW5jZXNAaWV0Zi5v cmciPmFkZC1ib3VuY2VzQGlldGYub3JnPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 OyBvbiBiZWhhbGYgb2YgRGVlbiwgR2xlbm4gKE5CQ1VuaXZlcnNhbCkgJmx0Ozwvc3Bhbj48YSBo cmVmPSJtYWlsdG86R2xlbm4uRGVlbkBuYmN1bmkuY29tIj5HbGVubi5EZWVuQG5iY3VuaS5jb208 L2E+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk YXksIEZlYnJ1YXJ5IDQsIDIwMjAgMTA6MDQgQU08YnI+DQo8Yj5Ubzo8L2I+IFRvbW15IFBhdWx5 ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRm Lm9yZyI+dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jmd0OzsgQWRhbSBSb2FjaCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzph ZGFtQG5vc3RydW0uY29tIj5hZGFtQG5vc3RydW0uY29tPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gRXJpYyBSZXNjb3JsYSAmbHQ7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNvbTwvYT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZndDs7IERlZW4sIEdsZW5uIChOQkNVbml2ZXJzYWwpICZsdDs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOkdsZW5uLkRlZW5AbmJjdW5pLmNvbSI+R2xlbm4uRGVlbkBuYmN1bmkuY29t PC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OzsNCjwvc3Bhbj48YSBocmVmPSJtYWls dG86YWRkLWNoYWlyc0BpZXRmLm9yZyI+YWRkLWNoYWlyc0BpZXRmLm9yZzwvYT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzphZGQtY2hhaXJzQGll dGYub3JnIj5hZGQtY2hhaXJzQGlldGYub3JnPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0OzsgUGF1bCBIb2ZmbWFuICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBhdWwuaG9mZm1h bkBpY2Fubi5vcmciPnBhdWwuaG9mZm1hbkBpY2Fubi5vcmc8L2E+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mZ3Q7Ow0KIEFERCBNYWlsaW5nIGxpc3QgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86YWRkQGlldGYub3JnIj5hZGRAaWV0Zi5vcmc8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mZ3Q7OyBUaGUgSUVTRyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3Jn Ij5pZXNnQGlldGYub3JnPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW0FkZF0gW0VYVEVSTkFMXSBSZTogW0V4dF0gQWRhbSBSb2FjaCdz IE5vIE9iamVjdGlvbiBvbiBjaGFydGVyLWlldGYtYWRkLTAwLTAwOiAod2l0aCBDT01NRU5UKTwv c3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K77u/T24gMi80LzIwLCA5OjU2IEFNLCAmcXVvdDtBZGQg b24gYmVoYWxmIG9mIFRvbW15IFBhdWx5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWRkLWJv dW5jZXNAaWV0Zi5vcmclMjBvbiUyMGJlaGFsZiUyMG9mJTIwdHBhdWx5PTQwYXBwbGUuY29tQGRt YXJjLmlldGYub3JnIj5hZGQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgdHBhdWx5PTQw YXBwbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgJmd0OyBPbiBGZWIgNCwgMjAyMCwgYXQgODo0MSBBTSwgQWRhbSBSb2FjaCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPmFkYW1Abm9zdHJ1bS5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBPbiAyLzQvMjAgMTA6MzcsIEVyaWMgUmVzY29ybGEgd3JvdGU6PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IEluIHRoZSBpbnRlcmVzdCBvZiB0cnlpbmcgdG8gbW92ZSBm b3J3YXJkLi4uLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsgSSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBhIGJ1bmNoIG9mIHRy aWNreSBuZXR3b3JrIHNjZW5hcmlvcyB0aGF0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7IG5lZWQgdG8gYmUgaGFuZGxlZCAoY2FwdGl2ZSBwb3J0YWxzLCBWUE5zLCBzcGxpdCBETlMs IGV0Yy4pIGFuZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyB0aGF0IHByb3ZpZGlu ZyBzb21lIGd1aWRhbmNlIGhlcmUgd291bGQgYmUgdXNlZnVsLiBXaGF0IEknbSB0cnlpbmc8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgdG8gYXZvaWQgaXMgdGhhdCBibGVlZGluZyBp bnRvIGEgbG90IG9mIGRlYmF0aW5nIGFib3V0IHBvbGljeSBhbmQ8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsgaG93IHBhcnRpY3VsYXIgY2xpZW50cyBvdWdodCB0byBiZWhhdmUuIFdp dGggdGhhdCBpbiBtaW5kLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBoZXJlIGlz IHdoYXQgSSBzdWdnZXN0Ojxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgMS4gUmV2aXNlIHRoYXQgYnVsbGV0IHRvIGJlIG1v cmUgY2xlYXJseSB0ZWNobmljYWw6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IDxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAtIGRldmVs b3AgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyBtZWNoYW5pc21zIGZv cjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBjbGll bnRzIHRvIGRldGVjdCBzcGVjaWZpYyBuZXR3b3JrIGVudmlyb25tZW50cyAoY2FwdGl2ZSBwb3J0 YWwsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNw bGl0IGhvcml6b24sIGV0Yy4pIGFuZCB1c2UgdGhhdCB0byBpbmZvcm0gdGhlaXIgRE5TPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRp b24uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgMi4gQWRkIGEg c2VudGVuY2UgdG8gdGhlIGNoYXJ0ZXIgYWZ0ZXIgdGhlIHdvcmsgaXRlbXMgdGhhdCBzYXlzOjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhpcyB3b3JraW5nIGdyb3VwIGlzIGNo YXJ0ZXJlZCBzb2xlbHkgdG8gZGV2ZWxvcCB0ZWNobmljYWw8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbWVjaGFuaXNtcy4gTWFraW5nIGFueSByZWNv bW1lbmRhdGlvbnMgYWJvdXQgc3BlY2lmaWMgcG9saWNpZXM8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9yIGNsaWVudHMgYW5kIHNlcnZlcnMgaXMg b3V0IG9mIHNjb3BlLiZxdW90Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7IEkgdGhpbmsgdGhpcyB3b3VsZCBnbyBhIGxvbmcgd2F5IHRvd2FyZHMgY29udGludWlu ZyB0aGUgZm9ybXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgb2YgcHJvZHVjdGl2 ZSBlbmdhZ2VtZW50IHdlIGhhdmUgYmVlbiBzZWVpbmcgKHdoaWNoIEkgYWdyZWU8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgdGhlcmUgaGF2ZSBiZWVuKSB3aGlsZSBzY29waW5nIG91 dCBjb250ZW50aW91cyBhbmQgdW5wcm9kdWN0aXZlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7IHBvbGljeSBkZWJhdGVzLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFRo YW5rcy4gVGhpcyBjcm9zc2VkIG9uIHRoZSB3aXJlIHdpdGggbXkgcHJldmlvdXMgbWVzc2FnZSwg YW5kIEkgdGhpbmsgaXQncyBhIGdvb2QgZXhhbXBsZSBvZiB0aGUga2luZHMgb2YgZ3VpZGVyYWls cyBJIHdhcyBjYWxsaW5nIGZvci48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7MTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgSSB0aGluayBib3RoIG9mIHRoZXNlIHRleHR1YWwgY2hhbmdlcyBhcmUgYXBw cm9wcmlhdGUsIGFuZCBjbGFyaWZ5IHRoZSBpbnRlbnQgb2YgdGhlIGNoYXJ0ZXIsIHdpdGhvdXQg dW5kdWx5IGNvbnN0cmFpbmluZyB0aGUgdGVjaG5pY2FsIHdvcmsgb2YgYSBncm91cC4gSSBzdXBw b3J0IHBlcmZvcm1pbmcgYm90aCBvZiB0aGVzZSBjaGFuZ2VzITxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzIGVrciBmb3IgdGhlIHN1Z2dlc3Rp b25zLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgQmVz dCw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgVG9tbXk8YnI+DQo8YnI+DQomIzQzOzE8YnI+DQo8 YnI+DQpJIGFsc28gZG9uJ3QgaGF2ZSBhbnkgaGVhcnRidXJuIHdpdGggZWl0aGVyIG9mIHRoZSBz dWdnZXN0ZWQgY2hhbmdlcy4gVGhleSBjbGFyaWZ5IHRoZSBtaXNzaW9uIHdoaWxlIGtlZXBpbmcg dGhlIGNoYXJ0ZXIgY2xlYW4gZW5vdWdoIHRoYXQgaXQncyBzaW1wbGUgdG8gcmVhZCBhbmQgdW5k ZXJzdGFuZC48YnI+DQo8YnI+DQotZ2xlbm48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg LS0gPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IEFkZCBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkFkZEBpZXRmLm9yZyI+QWRkQGlldGYub3JnPC9h Pjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmcl MkZtYWlsbWFuJTJGbGlzdGluZm8lMkZhZGQmYW1wO2FtcDtkYXRhPTAyJTdDMDElN0NKZW5zZW4u VGhvbWFzJTQwbWljcm9zb2Z0LmNvbSU3QzQ0MjNlZDVlYmU1NzQ2NzE4MTg2MDhkN2E5OWNiNjgy JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE2NDM2Mjg5 NDA0Mzc4OCZhbXA7YW1wO3NkYXRhPTBEc0xpSyUyRmdPRHVWQk9CTXYxOTVoRmxHemwxQU9rYXd2 UWszZVJMJTJGU0IwJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MCI+DQpodHRwczovL25hbTA2LnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5v cmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZhZGQmYW1wO2FtcDtkYXRhPTAyJTdDMDElN0NKZW5z ZW4uVGhvbWFzJTQwbWljcm9zb2Z0LmNvbSU3QzQ0MjNlZDVlYmU1NzQ2NzE4MTg2MDhkN2E5OWNi NjgyJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE2NDM2 Mjg5NDA0Mzc4OCZhbXA7YW1wO3NkYXRhPTBEc0xpSyUyRmdPRHVWQk9CTXYxOTVoRmxHemwxQU9r YXd2UWszZVJMJTJGU0IwJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDwvYT4NCjxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyA8YnI+DQo8YnI+DQotLSA8YnI+DQpBZGQgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOkFkZEBpZXRmLm9yZyI+QWRkQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmFkZCZhbXA7YW1w O2RhdGE9MDIlN0MwMSU3Q0plbnNlbi5UaG9tYXMlNDBtaWNyb3NvZnQuY29tJTdDNDQyM2VkNWVi ZTU3NDY3MTgxODYwOGQ3YTk5Y2I2ODIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM3MTY0MzYyODk0MDQzNzg4JmFtcDthbXA7c2RhdGE9MERzTGlLJTJGZ09E dVZCT0JNdjE5NWhGbEd6bDFBT2thd3ZRazNlUkwlMkZTQjAlM0QmYW1wO2FtcDtyZXNlcnZlZD0w Ij5odHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZhZGQmYW1wO2Ft cDtkYXRhPTAyJTdDMDElN0NKZW5zZW4uVGhvbWFzJTQwbWljcm9zb2Z0LmNvbSU3QzQ0MjNlZDVl YmU1NzQ2NzE4MTg2MDhkN2E5OWNiNjgyJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN0MxJTdDMCU3QzYzNzE2NDM2Mjg5NDA0Mzc4OCZhbXA7YW1wO3NkYXRhPTBEc0xpSyUyRmdP RHVWQk9CTXYxOTVoRmxHemwxQU9rYXd2UWszZVJMJTJGU0IwJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9 MDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_LO2P123MB2573ACF823EE39248D696794FE020LO2P123MB2573GBRP_-- From nobody Wed Feb 5 09:19:08 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED4712080B for ; Wed, 5 Feb 2020 09:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjLez0dmwwTs for ; Wed, 5 Feb 2020 09:19:03 -0800 (PST) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C6312021D for ; Wed, 5 Feb 2020 09:19:02 -0800 (PST) Received: from [100.112.197.112] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-b.eu-west-1.aws.symcld.net id 21/CA-20875-CF8FA3E5; Wed, 05 Feb 2020 17:18:52 +0000 Authentication-Results: mx.messagelabs.com; dkim=none (message not signed); dmarc=fail (p=none sp=none adkim=r aspf=r) header.from=vodafone.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WTe0xTZxjG+U5vB+XosVR4RZiuGS5TWumcS2G XbpkakblM3MXoZLa2ayulbXraWXTJ0Mxk3JRd6Apry9WijbDo5KKwKWUEuTguA5Vp2AgsTm7G LZZVCe4cT2Fb9s+X3/c+z/u+z0m+g3OEtYIYXGO3aixGpUHMX8Rdn2LIkTz8Kzk90XEuXv6oq 5Yv7zzhE7yCbb3iHeBtraoKYm9iu3l6o8pk38fTXSs9jplbqpH99oV12ei4B+WiRbiQrEdQf+ Yal734ETivD2ILylDvFJ+99CJouD0UuhRg4Lk6HLINIzj5p48eEI7zyd2Qm32Xwwgi0oXA5fE LGCGSXAnuI0OPWUTGwoOb34Q4GU6edvEY5pJPgcfno6fiOEG+B+1HP2YX1CDw5vRzmHo4uRf8 U7GMHZFxUNhUgRjmkNHw81gpxjCQIhjp6+KzvBzujM7xmDkEeSocvv72AWKbtTBa18tlTasg3 zkdaoiD/tI8xPJ2uHrMw2N5LRSUNTzOAHTOOX8WW86AG4WO0Jg1cGPyUw7LsfDJr92hPMVc6H emMSwk1eA+Wy9g60+Ar2CEW4hkJf/6hBI6KofMQRB0DHAZgSCXQUfxGM04LRihvSyF9SdAWdM ffJbXgbd8gjPP3ZdHsf/XE+BhIDfkfxJuDhbx2F2VCH7P/3HBVBy8yJs3fZk3IihDhA/JVRa9 VmfNVOoNElliokQme1YiS0qSyJ7bKFUekqikGpvkoIaySmRS5UFKSmVl7jeopUaN9RyiH6ra3 P5ZIzpTc1fqRytwTLycWJyXnC5cojKps3RKSve+xWbQUH4Ui+NiIC4EaG2ZRaPV2D/QG+jnPi 8DHiEWEZH0gxcSlFmZSem1rNSJFHjhHXcFB58OVtLnPV8Vfc4wp5BrNBk1MdHEXqaNZNp0NuP C0PnfqB/FxUQSKCwsTBhh1lgy9db/6uMoGkfiSKJhhp4SoTdaF3aP07EwOtbKVDkTy6r8R4rJ xir2nX/mq/02p//yYcq104Y2u3tOb5ssbAxP+XxAsbOAajkhKTcHutNVksjJo77Un7Srh11Rb SuOfL/6kqJjIqOGrNpierrE/KixenRHev5Zzwva54uWYI3jLW35F/verjSlOZr31LS0qjvR67 I3ystFr3p7Zuo3RJBd1I5Lm2vao4ocjU0pwaqu7Kh4XvQPc7fUt15cpdhTJ9yWkVU8e6rHPdv W+5qvrnlgOKnDPPryYNeEvPW7vtp4W6pve/XA/fVTwXtrnF+UHTrgTdhkfkc/m8MPvGXfcP8X x4FAtWXpu4dnml/Kmv7oyod219gc/tuuXRvPH4PhVNHiPENr7ya3Iu26mEvplLK1HAul/BsE3 csJwQQAAA== X-Env-Sender: Gianpaolo-Angelo.Scalone@vodafone.com X-Msg-Ref: server-3.tower-291.messagelabs.com!1580923125!633673!19 X-Originating-IP: [47.73.108.137] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.44.25; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3979 invoked from network); 5 Feb 2020 17:18:51 -0000 Received: from vgdpm11vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.137) by server-3.tower-291.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 5 Feb 2020 17:18:51 -0000 Received: from VOEXH10W.internal.vodafone.com (47.73.211.214) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Feb 2020 18:18:48 +0100 Received: from voxe04hw.internal.vodafone.com (195.232.244.49) by VOEXH10W.internal.vodafone.com (47.73.211.214) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Feb 2020 18:18:48 +0100 Received: from VOEXH11W.internal.vodafone.com (47.73.211.209) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Feb 2020 18:18:48 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (172.17.213.40) by VOEXH11W.internal.vodafone.com (47.73.211.215) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Feb 2020 18:18:47 +0100 Received: from DB8PR05MB5930.eurprd05.prod.outlook.com (20.179.12.27) by DB8PR05MB6028.eurprd05.prod.outlook.com (20.179.11.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Wed, 5 Feb 2020 17:18:47 +0000 Received: from DB8PR05MB5930.eurprd05.prod.outlook.com ([fe80::7066:11f8:9e5f:c3f1]) by DB8PR05MB5930.eurprd05.prod.outlook.com ([fe80::7066:11f8:9e5f:c3f1%5]) with mapi id 15.20.2686.031; Wed, 5 Feb 2020 17:18:47 +0000 From: "Scalone, Gianpaolo Angelo, Vodafone Italy" To: "Smith, Kevin, Vodafone Group" , Patrick Tarpey , "add@ietf.org" Thread-Topic: ADD Charter +1 Thread-Index: AdXcB9DglBi8KU8VQFWwwkhC5UHZjwAFnqewAApzklA= Date: Wed, 5 Feb 2020 17:18:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Enabled=True; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Extended_MSFT_Method=Automatic; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Application=Microsoft Azure Information Protection; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Name=C2 General; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SetDate=2020-02-05T12:19:38.4194676Z; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Owner=Kevin.Smith@vodafone.com; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SiteId=68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Enabled=True; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_SiteId=0af648de-310c-4068-8ae4-f9418bae24cc; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Owner=Patrick.Tarpey@ofcom.org.uk; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_SetDate=2020-02-05T09:37:11.1995074Z; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Name=Protected; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Application=Microsoft Azure Information Protection; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Extended_MSFT_Method=Manual; Sensitivity=C2 General Protected x-originating-ip: [5.94.129.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fbf06c10-a32e-4d11-28a1-08d7aa5f75e9 x-ms-traffictypediagnostic: DB8PR05MB6028: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(396003)(136003)(366004)(346002)(189003)(199004)(81166006)(81156014)(53546011)(6506007)(478600001)(8676002)(8936002)(186003)(7116003)(26005)(71200400001)(7696005)(316002)(110136005)(2906002)(33656002)(76116006)(66946007)(66476007)(5660300002)(55016002)(9686003)(66616009)(86362001)(66446008)(64756008)(66556008)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:DB8PR05MB6028; H:DB8PR05MB5930.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: vodafone.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XXn0B3loJBLv1Y1aQz97xHEEmgS1UW5Q51IFZSDy/t+ixtfnEhNa0tWDpLHaeguNL872Q7xDtRzR1DkHULIEd3zlQLjXcp+i6dSZ4uCFAPdkgx4fBvmhjutADnSPNqmCktSCicIeVYkWMZ4mp10Xgv8oWc3W4T0v7Y2kM+HvDhXEVhTooqsHBnYHxqCcmVfv1OfyPiawjL7o4h6m9xq5NUeyJyXhUWP0ZR85oKBn3cCkWWpRs3UvLo6eJFBYA4pyxFfAbJU6QvmuZIRDT+pQwa7KQSdPP3avD/Dt22SJ9HWgc4CB1n+YDEE35Lvu4WtT9p0ebS0ZoK+fYfJ0dmP6kvny1j9PyhJJJZWxxn3MI8IyijiNDxfAptKs2OAcZz7kXbda0j4TyAtAD6KcBy6Gh7gXW1qhFyojWqs8wTmSeVYWLntSmthZq6aqwWixN+MzndPxoV4GrUdUUO/X4phMX8gvX+bH/q6SOUgo60E/SA2M/aiHX8HN18OFA0wrcBTTJjB30pVZFdzOhXnsvzxFmg== x-ms-exchange-antispam-messagedata: CXzc/lNR5SQ0tR0sW7mtF7+xyPQk9wyNK0c3d4kq+O7Z1s66FQoW+K9ONTVauQJFBX6acaK1MzZxm1L6GKFCrrosd6pXzW1aGeTnp74tXTJDKOnVqqPRPV7tScN1v+J/OvJkfx14sgVcAW24/zhxKw== arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E4n3Nc7EFCGtjBWXfhNQeHlU4002NliW90tq1Y0/akJLT8hvZ672SpUfmldZn2v0rmPm3XhOzhhGQw8kUAi2PlbcO4Eug/hk8jjaYU+YM1b8KurcbLd7U7C1mZrf19qF2z6+6c6HgHwJSBYOV/abdmUcr1kKCQ9ukZJZsyYolfm4BS5urFPeYygvEi0jyC5kbwYBq+QrKsNyNUWCYJixYjwraE82z9dtVURcpPa89EcVUEN79oNDBlSi6Ua30nXWyQho+Dltv9fwDz/queL1K4EiWIaMhO9oeTy2c1zga8o9zqfgTbXx7ro/BZjlC7XiPpVYYXEpaH9mlYMnMGVYwA== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dEZqPVq12YSV85Kh+8++4f46YsX2DrpMqnVtFBsLvGI=; b=g1tnjK3JGZkI0jOQqR56k+E4Ne0YaIDf+YDoamIiv9JREPgCdMieNp0Urxxw561zJqvTzXnDGFcW57M5UP21JAodZQnL3kX4TH0NXgNMuuapx9FF8rw2caNO40zEhpPhUeTEcmXzJnWu0SufZpJFt6D/8Vv+ddlsUY3cCNrHNQagCCme8MnyUomOKuPB9liEXc5bdGihy/UybcF2qO2s7f++G5bRZur3aMDtytFANDmHm3A0ZgoCWvAwchSDQeKM2kHWKXa7hRiEYCNP7A44LVNA5lO9wNG2+QG8PcnKDoMxlzKJ7iZwLRuNRYWyBPZPUjZmuEjxYieWOTjNJcNi8w== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vodafone.com; dmarc=pass action=none header.from=vodafone.com; dkim=pass header.d=vodafone.com; arc=none x-ms-exchange-crosstenant-network-message-id: fbf06c10-a32e-4d11-28a1-08d7aa5f75e9 x-ms-exchange-crosstenant-originalarrivaltime: 05 Feb 2020 17:18:47.2014 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: NYVcCP79pHtiSW/J20w45GycalplfqsBeZFFADNbI8gmJVFdFdaUKY/DvkPZoZI5S2RQ8Q2/EyM16N+M8LIJHZn8SHleVrEcAPuZHTdEkz/dIEydLo9xhWcZzz2N+XKd x-ms-exchange-transport-crosstenantheadersstamped: DB8PR05MB6028 Content-Type: multipart/related; boundary="_004_DB8PR05MB59308CF470D039BB70CF0D78A3020DB8PR05MB5930eurp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: vodafone.com Archived-At: Subject: Re: [Add] ADD Charter +1 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 17:19:07 -0000 --_004_DB8PR05MB59308CF470D039BB70CF0D78A3020DB8PR05MB5930eurp_ Content-Type: multipart/alternative; boundary="_000_DB8PR05MB59308CF470D039BB70CF0D78A3020DB8PR05MB5930eurp_" --_000_DB8PR05MB59308CF470D039BB70CF0D78A3020DB8PR05MB5930eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A +1 also for me as I'm also supportive of the ADD Working Group Charter Gianpaolo [Vodafone] Gianpaolo Scalone Senior Engineer Service Applications Centre of Excellence Group Technology, Networks Mobile: +39 348 0001806 Email: gianpaolo-angelo.scalone@vodafone.com Address: Via Bisceglie 73 20147 Milano C2 General From: Add On Behalf Of Smith, Kevin, Vodafone Group Sent: Wednesday, February 5, 2020 1:20 PM To: Patrick Tarpey ; add@ie= tf.org Subject: Re: [Add] ADD Charter +1 And a +1 from me to the charter text incorporating EKR's comments (subseque= ntly accepted by Tommy) Kevin C2 General From: Add > On Behalf Of = Patrick Tarpey Sent: 05 February 2020 09:40 To: add@ietf.org Subject: [Add] ADD Charter +1 We are supportive of the ADD Working Group Charter. Pat :: Patrick Tarpey Technical Advisor 020 7981 3240 07834432016 patrick.tarpey@ofcom.org.uk :: Ofcom Riverside House 2a Southwark Bridge Road London SE1 9HA 020 7981 3000 www.ofcom.org.uk ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_DB8PR05MB59308CF470D039BB70CF0D78A3020DB8PR05MB5930eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A +1 also for me a= s I’m also supportive of the ADD Working Group Charter

 

Gianpaolo

 

3D"Voda==

Gianpaolo= Scalone
Senior  Engineer

Service Appli= cations Centre of Excellence

Group Technol= ogy, Networks

Mobile: += 39 348 0001806

Email: gianpaolo-angelo.scalone@vodafone.com

Address: Via Bisceglie 73 20147 Milano = =

 

 

 

= C2 General

From: Add <add-bounces@ietf.org> On = Behalf Of Smith, Kevin, Vodafone Group
Sent: Wednesday, February 5, 2020 1:20 PM
To: Patrick Tarpey <Patrick.Tarpey=3D40ofcom.org.uk@dmarc.ietf.or= g>; add@ietf.org
Subject: Re: [Add] ADD Charter +1

 

And a &= #43;1 from me to the charter text incorporating EKR’s comments (subse= quently accepted by Tommy)

&n= bsp;

Kevin

&n= bsp;

&= nbsp;

= C2 General

From:<= /span> Add <add-bounces@ietf.org> On Behalf Of Patrick Tarpey
Sent: 05 February 2020 09:40
To: add@ietf.org
Subject: [Add] ADD Charter +1

 

We are supportive of the ADD Wo= rking Group Charter.

 

Pat

 

:: Patrick Tarpey 
Technical Advis= or 
020 7981 3240 
07834432016=  
pa= trick.tarpey@ofcom.org.uk 
 <= /b> 
 <= /b> 
:: Ofcom 
Riverside House=  
2a Southwark Br= idge Road 
London SE1 9HA 
020 7981 3000 
www.of= com.org.uk=

 

 

&= nbsp;

=
***************************************************************************= ***************************************
For more information visit www.ofcom.or= g.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************

--_000_DB8PR05MB59308CF470D039BB70CF0D78A3020DB8PR05MB5930eurp_-- --_004_DB8PR05MB59308CF470D039BB70CF0D78A3020DB8PR05MB5930eurp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3053; creation-date="Wed, 05 Feb 2020 17:18:46 GMT"; modification-date="Wed, 05 Feb 2020 17:18:46 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAC4AAAAuCAYAAABXuSs3AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAS dAAAEnQB3mYfeAAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAttSURBVGhD tZlLbFTXHcb/d+bOjI15mIcJBGzMyxCaIDk8CkREiggoCYimoLQssqu66CJSVl12NF1220UVdRsp EW2UBRQolCpSEhwRwkOhGPOKwTwCNg8TgseeV3/f8dzJ9fiObYg54nCv75x7zne+839fP5PJ2NO2 36fTs3j3haJZW8xsKffNXOcV6NzP8PivZPaQ/n25X2fsZcZ0/WDW+c9M5u7Tru0/6YvvptMzEmbL WHwZIFbEzVoB2ERvZK7pAJzKdSq/pQScXk+f6k2dOs9fsGBJrKVltd/S0ju1oaH7vQsXuvLnz1/6 4cqVSx++//6DJ8EyYeDvpdMNWbOFebO1AN8ImHZALqfPZhP8c+xWesz3LdbQYLHGRovNn2/xlhbz lyyxOPelUqlY6Om5n+/tvejduXMq1d/fwemdqDPr+Wsm82giG5gQcFiex2wbYXcLL2wAZTMgG7lP 8sw1xMNg2QE3APsrV5r/0kuWpCeWLze/tZU3OJSBASt1dMQeHz8+e+jatemlu3eXesXiBt776rHZ f9nAsb9nMjfHAz8m8D+l07EeZBig29TFctLsORi3IXqufHVgJRbTplmirc0Sa9dact0681essHiZ ZfM8K/X32+CXX9rA4cOWP3HC4rduJRLZbBObb2K+hdKTQbPFf0inD31mdq4zkxEfka0m8D3pdPKW 2UsA3Q2wt3l7JRN7iIoDLLAVhhEL//nnLQHY1Natlnr1VQfYS6Uqi5YePbLsJ5/Yow8+sKEzZ9j5 kMVKJTeXdEHgmXMrpLSCtmmD2T/eSafP/DmTEUejWiRwMQ3olxm9h8l+xWSLmNjTIqIgLMtePG4J xCH11lsOdOKFFyw2d+6IhUqIx+DRozbw6ac2dOqUlXI5pxTB5gVcQFjHY/42kP6W9aaA4SOwdABe HI1oo4CXmf6FQDPRLrrk2QZCrwXAPWQ5iVjU79plqW3bnFxHNRTRBg8csMGOjgpogQ2a5hMp6iio 1Zu1cLJvi2rAZ8F09uNMBin6qY0Ank6nvfcwc1iPd5h4Jz82azKJR3XzkklLrV9v9e++a/U7dphX xXJlfDZrmDzLwXTx7l3HdBh09bxCJ1D0Bay7A6ofz0SwYP4szAfq5MZU2r1hJXmdB7therF+EGid U7CYuwd0sr3dpuzZY6mxQDO2cOeO5c+ds/ytW040nN0co2l+rSlrhX4tAs8u+m2Y7+MRl+FWAc6O 6m5g8ph4Oy+16QfMk2sB6GC7ssf1u3c7ua6W52pMpYcPHdOlwcGKbgRjopgve1snmg3DG1iK3G/n thtfchA772A54ID2epErBr3Bn2v0crUqB3IthyKrkdq+3WILF47DH5tGD+R8pLSGUsqOF7EoHhZl rBbGAJntjH0TEe4Ea6dExgHnQSNHJCuyHuWYLdDVaqxlvFjMki+/bHVYj/iyZeOC1gCdSGrLFos9 95zlz561XGen5b791gqXLlmxMGymy6HBqPn0q0QLZW2E5nWMWwPW2zy664AT8LQCbDNgWyVbAbvB TAE38aYmS732miU2bHByPpEmxv1Vq8xno4WNGy2HvOdOnrQhHJGuhbLsR4lN5ZSHF2qhb75vdr4C HIZXAngtL8+QVlcfomMboAkAyCvGcDZP3Hg/3tzsmNepqQ/s22eD9Dzmkvgl0tpobUkA2KZzWQO5 n2P9TvjEBnN4uEIBExzGA69YzXZszhzzsSTxxRgbROZpmwjwOLkkeuLNnGkxHNjA/v2Wv3KlIjbh uQVcVgYfHINURaVtl83m4qxtObK0iN8aJSaR/pXncbn01atNG5iM5tXXWxI/4KwIFmdg714r3EcQ htkd0UJmVKwvwlSv9AGqIErxtBclIsFEcZRM8UdsxozJwF2ZI8Ep1r35puVR2uJXX1lJFidiBSeu w2LcBN5VfjlzaQzihup33G7r6iw2b57rpjOazJZImM9JJjdtstx335nCgwBkeJkgoOO3mUpihGIh O5lWbUnCLylclUWZbLaDNSR+Unr/iy8c8KgWkgaJS7PPgwXcTNPgUSFYeQaZNG/6dJNcPotGWleJ 22OK27Ew1awH2JQGgmG+z40SW/0xygw6kEzkcZwutp5sMQlYYI347NkmPfKmTLHijz9GKmh5+BSu TWJc2biL+Gs64SL7lZcbx03/rNNAj9ypwr4BPErXHI+E7eBsGF/TdGwKkJQrSuNh5Jk0nSYna9j1 iTRZlX524BgPIrNRu1WEh40tiQklvM+i6UQVhOWjov+fsIFVPvJHHyG4DWBFkLLlo5rbDPli4fvv rdjX5xyR5H6ym0gpPXhgxcdBMD1yhVBoPcB9nxi/wV7nyomrh9Pq4ASKyHjh5k0rXL1q/tKlw3I4 mY35i729Vrh924lkVLQYwkZMaDelnDcYqPLZmClV4fp1y5Gdy9PFJxm42M4T5hZu3LASIlPr5Mtc PeTaI8YvIS6rNTgqdKqwTgqWwyXnX3nF4gsw/T8j0Ko+LEcKdZY8p1qrhXLVB6o/CngnN73hvLL6 ZYGX7OVOn7ahY8ecuMQXKS6bhAbDSqaHqAAUEZVaSUXoFPqE2UeHLyAuV/mhH/BBhXU0IsyiEt7s wYNOQZVzepMQcCkrGjxyxCUYtQIsR5yMhJnqilfJ0jp96nR9v0unu9jFRSLFdqxpXAYp7IwqGq3K E1lLVl6OhCCxebPFcBpP1WC6cO2aKxJlKRYVMblRbOuZnA2xuNzfZf7umokldA4I0F08/IbbJSQT s4JqVRhQAL5InWSQYMjDYdSxmMsna9VUxthRTkyTQAi4kgglz7WUUkkipPaD8xuMeFclWSZ8755N SsRx/JI+K9h5dQgQKLCcUZbjLWLfiyitQlLJvEsyxlDaEpsu4g/yXV1OPLKHDjn5VjhRC3TIKfaA 53OYJgEqlydWmd2j0nKSv49Tz1jEjzPleCMrWGUWBXrws8+s0N3tzGSSRNh/8UXzKVk42Q8CMh0w gAvUVtxYrMcQJ6YaoopFlJhrFokC5w+mh7B9gpm+nk+GXwEu6im2dHMchxAT2fQtOp6gkhplZfRM xcvcxYtWwOPJ4qgGHldH/p2TUohKfFOUR8TU5ZHpAslCXva6HAHW8sE67QADUnCaTfybuKQ7KMNV giwqRAMU8Dvw/a0AVpliqaJvZf1RpjLkgp3XG6LnYdGbNctiJMGK4SvA0QVDvGRSA/GrZfZcxkVX 8CRdA0s3z/4Fhi/AWAkbR0SHS9BWKlr/YeA8XvgNL7dqQLWVCU6gWhdc+nfv3nDSG8QzEpWQ4tUC HMwp0FpT4yDtGpdPeXYYERnhnUYA1zFQ0r1AOrSXF6YA+NeqmkrWqCDVbGH2nTKVwYY3qPtaYhGe WOIh8Kx9iy0f4PZjZPx8uFKr8aPicdWhqc+dQlnrkHmPvhPmmyU24cJ+1C4CYBMBGH5f40WOPtFI PAB6nct++kcw/Q2gR31SiUwk9AUA8F8DfohdDwB4Jwy0BeYwSKxrZkxjnE414PAmVdORk0Ge98H8 xwjcaRxk5HegmhmQvr0A/iQyn2XCO7CxlQnbYX+O2Am+IDwteAEWwwHLyPM9np1mjSOIyqEms7N/ y2Sis4ooUQkzUj6ibynT3WPb3fz2OrK+nolVX25kUV+bkNUJ1T1GFE0DZQyu4bgfVHnmfcBVinec uY4Sh8h6SFTGbOPnnLzOcd1QUR3Q5/hzLX0TTLdzEsu4qkBTM9GO8r7lUsMDhdT002zqGHJ9ghik G9BKFMZtEwKuWcpffP/3x3T6JrLXyaPlLLiCq0rUKpw2ch98Em/gb0mBNiSpUj72iGdKAu4Dto/n 1+hdALgA45c+fMLv+hMGHlDwl0wG3HZcnU3M5Y9VMKgyNW7AmukYAvfNMsjvFIr2AVrfb3oQjSsA Pw+755hLRfqnav8HgNV2pZx782UAAAAASUVORK5CYII= --_004_DB8PR05MB59308CF470D039BB70CF0D78A3020DB8PR05MB5930eurp_-- From nobody Wed Feb 5 23:03:45 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5236D1200B4; Wed, 5 Feb 2020 23:03:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: add@ietf.org, add-chairs@ietf.org, add@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158097262126.30614.7797455505583515546.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 23:03:41 -0800 Archived-At: Subject: [Add] Benjamin Kaduk's Yes on charter-ietf-add-00-02: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 07:03:41 -0000 Benjamin Kaduk has entered the following ballot position for charter-ietf-add-00-02: Yes 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: ---------------------------------------------------------------------- We use "define a mechanism" for two work items but "describes mechanisms" for the third -- is this intended to require exactly one mechanism (as opposed to different mechanisms for, e.g., public Internet and private-network resolvers) for those items? This working group will focus on discovery and selection of DNS resolvers by DNS clients in a variety of networking environments, including public networks, private networks, and VPNs; supporting both encrypted and unencrypted resolvers. It is chartered solely to develop technical mechanisms. Making any recommendations about specific policies for clients or servers is out of scope. Are discussions of situations in which a given technical mechanism is more or less useful considered to be a policy recommendation that is out of scope? And some (style) nits, since I can't un-notice them... I think the semicolon in the second paragraph is better as a comma (the part after the semicolon doesn't stand on its own). Clients adopting encrypted DNS protocols need to determine which DNS servers support encrypted transports, and which server to use for specific Any reason to stick with "protocols" in the first instance but "transports" in the second as opposed to just picking one for both places? - define a mechanism that allows clients to discover DNS resolvers, including encrypted DNS servers, that are available to the client [Similarly for resolvers/servers.] From nobody Wed Feb 5 23:15:38 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C961200B4 for ; Wed, 5 Feb 2020 23:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MTJieb58uv3 for ; Wed, 5 Feb 2020 23:15:32 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350FF120127 for ; Wed, 5 Feb 2020 23:15:32 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id z26so3298303lfg.13 for ; Wed, 05 Feb 2020 23:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0PRVZLxjIZTz26uKwugS8lEn/3gXnOXcuHdYm0O9jbE=; b=g1PbN1+XDHFvWvT+Lz53iuHNJRbXwBi77eKCD4De0lWUlVaq++c6EafDBAhAmtSEyu W3sNRZbOeeAZzVBMIGHW/8iEtFxhyT+UVFhk7kS9hYZjldUSmHGjiyLLhS5XJxpZRer/ 2Zov6WldTjSKnt2UH/BmK14dKufItTXWCS/NvWiM16F+8OJhnHl5JXFcfyChjKjFy2Nv PI91GIfRDe+Z7P/NXRNP1gHkQtwW6m72G59pq9Y9oqrAMIK9aYgMwFI1Cx3ayAlaOUdv n5FTr99LKkU9l2DDq0ieClzef66jfN0/O6uUbQNpr98qujwYtd59i3rEM/6d0cJ1fHTI nLkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0PRVZLxjIZTz26uKwugS8lEn/3gXnOXcuHdYm0O9jbE=; b=gU/aZKPM5eS5CiB7o7oZOOr7A5N78xp3byMg8gHxG19cr2DkIqj7QqI00AUbCwCubN Z1uy0ZDWR1xWHEOcGpY43li8MQGqRjCxQTEZi9IaPCw+96LIDDo5h/unnCsWIIQc1sRW VLFKkAiFaUXTK7EC0hsIoLhuV2wJUyTc3t83x5nw3m93L0LgzOL1xT//nYOWRt+dclzE xQIxsZk/UyoO7SG7MgnjonyOc4U5Xx7jbLb+pIQUPBWmrIyHSGx5gsavjpwW0mD6dm5T 0O63y5A0fvxssga/e2cvTDJrHhLYufgY3cKKga67Y62QslxuSzdenyjYLgGc2rlldsbE s2RQ== X-Gm-Message-State: APjAAAV/p7epRVukZU1NkaGCe9zHRMrH1RVvPsnLFxJUNvZAYNdcKMhV Tk3c1iMGJahfatYzxOOfkGgKWGmR2D8EejP6bPWpEg== X-Google-Smtp-Source: APXvYqz84MqRn509RfubrcpCauVzvbiq1IR2JeHkPeIXa2s+6EJWHlrY5QUOZzAMq1CmAK4Bla7szNCUlT0V1v+p/ZE= X-Received: by 2002:a19:cb17:: with SMTP id b23mr990449lfg.201.1580973330327; Wed, 05 Feb 2020 23:15:30 -0800 (PST) MIME-Version: 1.0 References: <158097262126.30614.7797455505583515546.idtracker@ietfa.amsl.com> In-Reply-To: <158097262126.30614.7797455505583515546.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 5 Feb 2020 23:14:53 -0800 Message-ID: To: Benjamin Kaduk Cc: The IESG , ADD Mailing list , add-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000c0f580059de309f2" Archived-At: Subject: Re: [Add] Benjamin Kaduk's Yes on charter-ietf-add-00-02: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 07:15:35 -0000 --000000000000c0f580059de309f2 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 5, 2020 at 11:03 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > charter-ietf-add-00-02: Yes > > 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: > ---------------------------------------------------------------------- > > We use "define a mechanism" for two work items but "describes > mechanisms" for the third -- is this intended to require exactly one > mechanism (as opposed to different mechanisms for, e.g., public Internet > and private-network resolvers) for those items? > The way I read this is that the first two work items are to define protocols and the other one is to attempt to just describe approaches the client could take (e.g., to detect split horizon on your own) but not standardize anything (hence not being proposed standard). > > This working group will focus on discovery and selection of DNS > resolvers > by DNS clients in a variety of networking environments, including public > networks, private networks, and VPNs; supporting both encrypted and > unencrypted resolvers. It is chartered solely to develop technical > mechanisms. Making any recommendations about specific policies for > clients > or servers is out of scope. > > Are discussions of situations in which a given technical mechanism is > more or less useful considered to be a policy recommendation that is out > of scope? > I suspect we'll need the chairs to manage this, but my general hope would be that we could keep any such analysis tightly focused on technical facts, rather than having it end up in discussions of the overall merits of any given set of approaches. -Ekr > > And some (style) nits, since I can't un-notice them... > > I think the semicolon in the second paragraph is better as a comma (the > part after the semicolon doesn't stand on its own). > > Clients adopting encrypted DNS protocols need to determine which DNS > servers support encrypted transports, and which server to use for > specific > > Any reason to stick with "protocols" in the first instance but > "transports" in the second as opposed to just picking one for both > places? > > - define a mechanism that allows clients to discover DNS resolvers, > including encrypted DNS servers, that are available to the client > > [Similarly for resolvers/servers.] > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000c0f580059de309f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 5, 2020 at 11:03 PM Benja= min Kaduk via Datatracker <noreply@i= etf.org> wrote:
Benjamin Kaduk has entered the following ballot position for
charter-ietf-add-00-02: Yes

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

We use "define a mechanism" for two work items but "describe= s
mechanisms" for the third -- is this intended to require exactly one mechanism (as opposed to different mechanisms for, e.g., public Internet and private-network resolvers) for those items?

The way I read this is that the first two work items are to define= protocols
and the other one is to attempt to just describe appro= aches the client
could take (e.g., to detect split horizon on you= r own) but not standardize
anything (hence not being proposed sta= ndard).

=C2=A0 =C2=A0This working group will focus on discovery and selection of DN= S resolvers
=C2=A0 =C2=A0by DNS clients in a variety of networking environments, includ= ing public
=C2=A0 =C2=A0networks, private networks, and VPNs; supporting both encrypte= d and
=C2=A0 =C2=A0unencrypted resolvers.=C2=A0 It is chartered solely to develop= technical
=C2=A0 =C2=A0mechanisms. Making any recommendations about specific policies= for clients
=C2=A0 =C2=A0or servers is out of scope.

Are discussions of situations in which a given technical mechanism is
more or less useful considered to be a policy recommendation that is out of scope?

I suspect we'll need the = chairs to manage this, but my general hope would
be that we could= keep any such analysis tightly focused on technical facts,
rath= er than having it end up in discussions of the overall merits of any given<= /div>
set of approaches.

-Ekr

<= /div>




And some (style) nits, since I can't un-notice them...

I think the semicolon in the second paragraph is better as a comma (the
part after the semicolon doesn't stand on its own).

=C2=A0 =C2=A0Clients adopting encrypted DNS protocols need to determine whi= ch DNS
=C2=A0 =C2=A0servers support encrypted transports, and which server to use = for specific

Any reason to stick with "protocols" in the first instance but "transports" in the second as opposed to just picking one for bot= h
places?

=C2=A0 =C2=A0- define a mechanism that allows clients to discover DNS resol= vers,
=C2=A0 =C2=A0including encrypted DNS servers, that are available to the cli= ent

[Similarly for resolvers/servers.]


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000c0f580059de309f2-- From nobody Wed Feb 5 23:23:25 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B9B120143; Wed, 5 Feb 2020 23:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCsyd93N54WQ; Wed, 5 Feb 2020 23:23:19 -0800 (PST) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E311120096; Wed, 5 Feb 2020 23:23:19 -0800 (PST) Received: by mail-io1-xd42.google.com with SMTP id i11so5166172ioi.12; Wed, 05 Feb 2020 23:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+32K7xq5GEo6jFjKopeixqJ6q5K0dY4Yf8Ogczjxe8A=; b=mOxe8MmpDEy+P6lbIOrxsNWmCAcibRhIXpqBh1cxagtl0skymc4RG4AFxF2U4JJOIG zC0sW06Cy0Oq9TFTaAE8J8jH2i7g5kECRo/7D5troSz2P50zVJEaYDVpGTFokmN3/rVs LA9OKgn59ggOwhf/a/C35RWe/C5UjvcZ6jjzXNhGp74ssePaYfrbVe1u2bY1brqrIWOm LArAQDfayoaDrBXz6goinEmjL3UjrdRmo+GyQJQF/3/g+P9xfKyHEFuZPKVqNyALOr3E EYXUVxXE7L3GFZg3MOmJYfPY6/z/GncKO+iB+d3j8C5FN2/6kdiVwTwYoWwkmeIz6xLu mF8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+32K7xq5GEo6jFjKopeixqJ6q5K0dY4Yf8Ogczjxe8A=; b=a7GbB9a6TijN/CK5jpm/VHCOG5Kf9e3wkwAv/tEW/LOU1VRAWZ9/o5XqhaHQ6TPNH+ p96QGkdJHdZHnDXJoZdu1TVNscFuqxlTVc+VVucVS0mVTVrzLJbn3Te9SDlL/3fEKoY9 6rSzTI4qMuDDe3PMLCP4O1QyBFsfx5h/o3amL0NTjRQRh986K6xMcvZ1HajkuLBw9A47 uoEGcz0QfKV/idcZ6sdvUe5/7gMLe8xSaVOT812JlDf6WrzCFgyS9MXSOyULwrTtNJHQ nRsKCNb5KgaF9y691FF9rBZTLLFoVQCRt5eoyNkDym6MJDV5yuvSByxy1nOVps9to4wh yaYg== X-Gm-Message-State: APjAAAUl2U/qY3m8XmDmfQPjh1uD5cYqVdm46R0JG8b79PQUXq3xAene jdxMJuqccr5JFNT1HNZx58XISqxmeJ6hC+MdjbM= X-Google-Smtp-Source: APXvYqxRXgSusHF5gQKSI8TGjKXa2yPgfswbruA7F0i5hG5dWu7TlDRoODBwv2w4bA1VfXwjYhIa0haxUrm/+RmdaT4= X-Received: by 2002:a02:a48e:: with SMTP id d14mr32169074jam.30.1580973798320; Wed, 05 Feb 2020 23:23:18 -0800 (PST) MIME-Version: 1.0 References: <1A08570C-7145-4501-A20C-A6701F17F86C@nbcuni.com> <4caa7276-228e-c3a3-d036-85f2bbdc7e5e@nostrum.com> In-Reply-To: From: Rob Sayre Date: Wed, 5 Feb 2020 23:23:04 -0800 Message-ID: To: Barry Leiba Cc: Eric Rescorla , ADD Mailing list , The IESG Content-Type: multipart/alternative; boundary="000000000000a5eebe059de3252a" Archived-At: Subject: Re: [Add] [Ext] Adam Roach's No Objection on charter-ietf-add-00-00: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 07:23:20 -0000 --000000000000a5eebe059de3252a Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 11:59 AM Barry Leiba wrote: > Given the significant support for EKR's suggestion, I'm incorporating > it into the charter proposal now. > This new charter sounds reasonable. But anything can be forked and/or ignored. thanks, Rob --000000000000a5eebe059de3252a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2020 at 11:59 AM Barry Lei= ba <barryleiba@computer.org> wrote:
Given the significant support for EKR's sugges= tion, I'm incorporating
it into the charter proposal now.

<= /div> --000000000000a5eebe059de3252a-- From nobody Thu Feb 6 03:52:01 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C365C120019 for ; Thu, 6 Feb 2020 03:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.297 X-Spam-Level: X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKoqk0RD6IGy for ; Thu, 6 Feb 2020 03:51:57 -0800 (PST) Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D3612087C for ; Thu, 6 Feb 2020 03:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1580989917; x=1612525917; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=IRF344v2dpJZXp5Ezo6uNVwIeFe75LaU96E0YYeWUBM=; b=TgUT1U+Yrz6uFzPUpzolq+nzJB0eH2ofDkRucmZFhVwlwJ+81F0w29dB 02het/j+rxoVkhyjzC/uoh3k3zA4pEBcbxLnr98wqx/rosuOCFBw5ytTt KWb3828bX56U2UMlIQtLhgulG51rPMC8Bk+E8jWuDDGk/0m5FbSrNZB6J wc+XowYPQGpE+5WXm7/a8YV5juNaskPOKSPpLH4v92sBn0sLvWZ53K3uo muXpg0n6UKNTX7w3KfnRkbW0lE3b6vqY123CMtq3umQOZqca21WAJNAuf sugCIjhrYgUjBHhQ8MhpWtME4da31+yNKu5XrokjpnBV8xDcj/LsiOiwx g==; IronPort-SDR: 0ZaOEUUQkBHBbJvI7bqhwsN+FQzI8hy6B64/lN7ZSvzky8bt5u/XGrcI1s5AGiLbf0TZ9FhR/s GUrX2wSlb/pg== Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2020 12:51:54 +0100 IronPort-SDR: Lpk4wAj/ohp9nzMqQKdAqX0q/hsfX1F7TNlNVIjlXINZWhGLgHGjWBwCvUq4v+4ZiADE7fwH/e BmjsE9Lx0X7PXluEmuLNAXAkXrYgget8E= X-IronPort-AV: E=Sophos;i="5.70,409,1574118000"; d="png'150?scan'150,208,217,150";a="721002974" X-MGA-submission: =?us-ascii?q?MDEld5dZ27HHgdTCw1qH8RSBc0CaE/FK75VKqf?= =?us-ascii?q?77zh9PWD31ktt14ox0O42nrzBpDbwv9CxAf1xfwQ4WnXhOOPvug+RXyE?= =?us-ascii?q?mjMB96fN+XT5SMdG/nFyPynKJXmrkIjhr6rk3WeaREPEPU/Wq+RApbKm?= =?us-ascii?q?zX0Spct2gxpuo1hsFwLqWm8A=3D=3D?= Received: from he105715.emea1.cds.t-internal.com ([10.169.118.51]) by QDE8PP.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 06 Feb 2020 12:51:54 +0100 Received: from HE105712.EMEA1.cds.t-internal.com (10.169.118.43) by HE105715.emea1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 6 Feb 2020 12:51:53 +0100 Received: from HE104160.emea1.cds.t-internal.com (10.171.40.36) by HE105712.EMEA1.cds.t-internal.com (10.169.118.43) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 6 Feb 2020 12:51:53 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.20) by O365mail03.telekom.de (172.30.0.232) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 6 Feb 2020 12:51:53 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AzhlHbq9HirpKJeiPsfwHtpri0KPSHevP5P4yGIP3BZlSb0eutV+Ge4l+u9oVn85DaIJ4EW8THBb3ycsWpH1E1snwlojhSIWfrDi2sT05DV3wbCW6IEBhsSuM8efusMy8IgVJr7mDNO2Umixjiecvap9PV3tbPC9kH5zyCQr0GIDs0DOldvCFNy4kmaB1198cq680ZOKwqajBja/NKBX+A3LXTrjGOvqhNXaYq4shkEMHh3Fe6vhEVSQUfRHGDzvIbmGhGT0bdZqKOIvB95w94WUX2o+gzO6Ksd860gBItiIMGoCjrztIQ8iy2pGiuw3buKk4tmvs+hXDZJ3B7n1RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IRF344v2dpJZXp5Ezo6uNVwIeFe75LaU96E0YYeWUBM=; b=bA82rKjdmp8A67F+VQ+ZsrWqS87jLsoMZ1kYb9VuvpZvsuwUsxprWSQSZNj32SDBAWHEV3fIFPUqNVskwYCfixwV7d771fkxYqFDl+c4RicM8FDP9Wy4g5J64nkq4LsE1K9Hfv6QqnBYM856YyqJigcb2WczajUGVrZwlVi8ExITgnjIuv/sCJTMZwwsjM6rpSp3rv+IIKOkPeTP2FYN3Nx5/7pg5qYEzw4bc+N/G4xW9tmTzFxUNG+Tqrw2sTdrYYqJ35aQ1uD8myC3FbkUbyb4Pnfi0JybK4MJns5lykDCoQcmYHwksLq9Ea/eh6GQF9ntkTe4sEXGJPZ9h8az5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from FRXPR01MB0197.DEUPRD01.PROD.OUTLOOK.DE (10.158.151.15) by FRXPR01MB1062.DEUPRD01.PROD.OUTLOOK.DE (10.158.157.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.32; Thu, 6 Feb 2020 11:51:53 +0000 Received: from FRXPR01MB0197.DEUPRD01.PROD.OUTLOOK.DE ([fe80::a1f7:779e:3bb0:9244]) by FRXPR01MB0197.DEUPRD01.PROD.OUTLOOK.DE ([fe80::a1f7:779e:3bb0:9244%7]) with mapi id 15.20.2686.035; Thu, 6 Feb 2020 11:51:52 +0000 From: To: , , , Thread-Topic: ADD Charter +1 Thread-Index: AdXcB9DglBi8KU8VQFWwwkhC5UHZjwAFnqewAApzklAAJuXkAA== Date: Thu, 6 Feb 2020 11:51:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Enabled=True; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Extended_MSFT_Method=Automatic; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Application=Microsoft Azure Information Protection; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Name=C2 General; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SetDate=2020-02-05T12:19:38.4194676Z; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Owner=Kevin.Smith@vodafone.com; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SiteId=68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Enabled=True; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_SiteId=0af648de-310c-4068-8ae4-f9418bae24cc; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Owner=Patrick.Tarpey@ofcom.org.uk; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_SetDate=2020-02-05T09:37:11.1995074Z; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Name=Protected; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Application=Microsoft Azure Information Protection; MSIP_Label_5a50d26f-5c2c-4137-8396-1b24eb24286c_Extended_MSFT_Method=Manual; Sensitivity=C2 General Protected authentication-results: spf=none (sender IP is ) smtp.mailfrom=N.Leymann@telekom.de; x-originating-ip: [164.19.4.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 160d6855-9077-45f3-939c-08d7aafaf548 x-ms-traffictypediagnostic: FRXPR01MB1062: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(346002)(396003)(39860400002)(199004)(189003)(5660300002)(2906002)(478600001)(110136005)(316002)(9686003)(55016002)(66476007)(7696005)(76116006)(64756008)(66616009)(66556008)(66946007)(66446008)(81166006)(186003)(19627235002)(53546011)(8676002)(81156014)(26005)(71200400001)(86362001)(8936002)(33656002)(7116003); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB1062; H:FRXPR01MB0197.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: U3CuYK0d+8CeR4kCia4g+enAqv9s3gRIWgLMabQxg3Kf5uUbzi9VNygRfts79z7vqMdNF1b1TKde36HuCsTO6/uniMZb7aytM3kfRljU3v4e/x7suLbFvOT17kdy+4qrP6uTakvMydMPZ3FVsQXmYt/8vOUf6KAg8kQQmuw1lcNHoI3ld60GertZuoHEagVKnEvsLLZD+1NE9pM/2Z79STY8pNnRJtpeLFnaT1EotWuMlltj5jyVYwVOtV/NvyoTym8L9tkwvNm4VUX4F+4egX0HZGij/hbfeFIIJ5+OCX4TKxjC9XulgwTMVBXXk1q7Zw9ixA1bgNfMHDlEOmS9lXkeqgqudexvLDfMff8EonqA+Pyhi0pjfjNqHn+c6gY8eApOXYWk6nJubmK1dX8bcwqKvUUxFVU3V02FVrAhS68yJu69oUrJPEg1vTNIcHRXAT2k0RKQJh4Ah7OguMFMpP4Y9fIh85cPGdbkEwhQwetVgB+gIk+s33DkjpCsSqM2S7+8vaqoJ55ZDZebtgkOxA== x-ms-exchange-antispam-messagedata: u/WAaNL2bd0sGQ0Ic/TyHebF16YUXHt6S719BfqcZwVDMzkPBhl839rhr8GJPLGzLF0Bz8Cu4vFJrvztPI/rPqqUKjpOufoD3dyAQkgi5784mx2MOiDrprr8Ikw0oKGioz0/Rzl3GmhZ//anFAygdw== x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_004_FRXPR01MB0197CE9448E73AB17414E6D5981D0FRXPR01MB0197DEUP_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 160d6855-9077-45f3-939c-08d7aafaf548 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2020 11:51:52.7955 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VVQ1e+y9FBh8jiZ84KpNPC0Fw6575lm7qDNkK6YoKPc85mtLlHrCloEbHi9EzUh49Z5LYbZ0WH/VK3gvNjGTjA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB1062 X-OriginatorOrg: telekom.de X-TM-SNTS-SMTP: 01B4AB7C3D4CB9059CED238AEC6584764BDEB853D0B5DB5B03F536D96E6D4FFE2000:8 Archived-At: Subject: Re: [Add] ADD Charter +1 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 11:52:00 -0000 --_004_FRXPR01MB0197CE9448E73AB17414E6D5981D0FRXPR01MB0197DEUP_ Content-Type: multipart/alternative; boundary="_000_FRXPR01MB0197CE9448E73AB17414E6D5981D0FRXPR01MB0197DEUP_" --_000_FRXPR01MB0197CE9448E73AB17414E6D5981D0FRXPR01MB0197DEUP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 also from me, supporting the charter. Von: Add Im Auftrag von Scalone, Gianpaolo Angelo, V= odafone Italy Gesendet: Mittwoch, 5. Februar 2020 18:19 An: Smith, Kevin, Vodafone Group ; Patrick Tarpey= ; add@ietf.org Betreff: Re: [Add] ADD Charter +1 A +1 also for me as I'm also supportive of the ADD Working Group Charter Gianpaolo [Vodafone] Gianpaolo Scalone Senior Engineer Service Applications Centre of Excellence Group Technology, Networks Mobile: +39 348 0001806 Email: gianpaolo-angelo.scalone@vodafone.com Address: Via Bisceglie 73 20147 Milano C2 General From: Add > On Behalf Of = Smith, Kevin, Vodafone Group Sent: Wednesday, February 5, 2020 1:20 PM To: Patrick Tarpey >; add@ietf.org Subject: Re: [Add] ADD Charter +1 And a +1 from me to the charter text incorporating EKR's comments (subseque= ntly accepted by Tommy) Kevin C2 General From: Add > On Behalf Of = Patrick Tarpey Sent: 05 February 2020 09:40 To: add@ietf.org Subject: [Add] ADD Charter +1 We are supportive of the ADD Working Group Charter. Pat :: Patrick Tarpey Technical Advisor 020 7981 3240 07834432016 patrick.tarpey@ofcom.org.uk :: Ofcom Riverside House 2a Southwark Bridge Road London SE1 9HA 020 7981 3000 www.ofcom.org.uk ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_FRXPR01MB0197CE9448E73AB17414E6D5981D0FRXPR01MB0197DEUP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 also from me, supporting the charter.

 

Von: Add <add-bounces@ietf.org> Im A= uftrag von Scalone, Gianpaolo Angelo, Vodafone Italy
Gesendet: Mittwoch, 5. Februar 2020 18:19
An: Smith, Kevin, Vodafone Group <Kevin.Smith@vodafone.com>; P= atrick Tarpey <Patrick.Tarpey=3D40ofcom.org.uk@dmarc.ietf.org>; add@i= etf.org
Betreff: Re: [Add] ADD Charter +1

 

A += 1 also for me as I’m also supportive of the ADD Working Group Charter=

&n= bsp;

Gianpao= lo

&n= bsp;

3D"Voda==

Gianpaolo= Scalone
Senior  Engineer

Service Appli= cations Centre of Excellence

Group Technol= ogy, Networks

Mobile: += 39 348 0001806

Email: gianpaolo-angelo.scalone@vodafone.com

Address: Via Bisceglie 73 20147 Milano = =

&n= bsp;

&n= bsp;

 

= C2 General

From: Add <add-bounces@iet= f.org> On Behalf Of Smith, Kevin, Vodafone Group
Sent: Wednesday, February 5, 2020 1:20 PM
To: Patrick Tarpey <Patrick.Tarpey=3D40ofcom.org.uk@dmarc.ietf.org>= ; add@ietf.org
Subject: Re: [Add] ADD Charter +1

 

And a &= #43;1 from me to the charter text incorporating EKR’s comments (subse= quently accepted by Tommy)

&n= bsp;

Kevin

&n= bsp;

&= nbsp;

= C2 General

From: Add <add-bounces@ietf.o= rg> On Behalf Of Patrick Tarpey
Sent: 05 February 2020 09:40
To: add@ietf.org
Subject: [Add] ADD Charter +1

 

We are supportive of the ADD Wo= rking Group Charter.

 

Pat

 

:: Patrick Tarpey 
Technical Advis= or 
020 7981 3240 
07834432016=  
pa= trick.tarpey@ofcom.org.uk 
 <= /b> 
 <= /b> 
:: Ofcom 
Riverside House=  
2a Southwark Br= idge Road 
London SE1 9HA 
020 7981 3000 
www.of= com.org.uk=

 

 

&= nbsp;

=
***************************************************************************= ***************************************
For more information visit www.ofcom.or= g.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************

--_000_FRXPR01MB0197CE9448E73AB17414E6D5981D0FRXPR01MB0197DEUP_-- --_004_FRXPR01MB0197CE9448E73AB17414E6D5981D0FRXPR01MB0197DEUP_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3053; creation-date="Thu, 06 Feb 2020 11:51:52 GMT"; modification-date="Thu, 06 Feb 2020 11:51:52 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAC4AAAAuCAYAAABXuSs3AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAS dAAAEnQB3mYfeAAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAttSURBVGhD tZlLbFTXHcb/d+bOjI15mIcJBGzMyxCaIDk8CkREiggoCYimoLQssqu66CJSVl12NF1220UVdRsp EW2UBRQolCpSEhwRwkOhGPOKwTwCNg8TgseeV3/f8dzJ9fiObYg54nCv75x7zne+839fP5PJ2NO2 36fTs3j3haJZW8xsKffNXOcV6NzP8PivZPaQ/n25X2fsZcZ0/WDW+c9M5u7Tru0/6YvvptMzEmbL WHwZIFbEzVoB2ERvZK7pAJzKdSq/pQScXk+f6k2dOs9fsGBJrKVltd/S0ju1oaH7vQsXuvLnz1/6 4cqVSx++//6DJ8EyYeDvpdMNWbOFebO1AN8ImHZALqfPZhP8c+xWesz3LdbQYLHGRovNn2/xlhbz lyyxOPelUqlY6Om5n+/tvejduXMq1d/fwemdqDPr+Wsm82giG5gQcFiex2wbYXcLL2wAZTMgG7lP 8sw1xMNg2QE3APsrV5r/0kuWpCeWLze/tZU3OJSBASt1dMQeHz8+e+jatemlu3eXesXiBt776rHZ f9nAsb9nMjfHAz8m8D+l07EeZBig29TFctLsORi3IXqufHVgJRbTplmirc0Sa9dact0681essHiZ ZfM8K/X32+CXX9rA4cOWP3HC4rduJRLZbBObb2K+hdKTQbPFf0inD31mdq4zkxEfka0m8D3pdPKW 2UsA3Q2wt3l7JRN7iIoDLLAVhhEL//nnLQHY1Natlnr1VQfYS6Uqi5YePbLsJ5/Yow8+sKEzZ9j5 kMVKJTeXdEHgmXMrpLSCtmmD2T/eSafP/DmTEUejWiRwMQ3olxm9h8l+xWSLmNjTIqIgLMtePG4J xCH11lsOdOKFFyw2d+6IhUqIx+DRozbw6ac2dOqUlXI5pxTB5gVcQFjHY/42kP6W9aaA4SOwdABe HI1oo4CXmf6FQDPRLrrk2QZCrwXAPWQ5iVjU79plqW3bnFxHNRTRBg8csMGOjgpogQ2a5hMp6iio 1Zu1cLJvi2rAZ8F09uNMBin6qY0Ank6nvfcwc1iPd5h4Jz82azKJR3XzkklLrV9v9e++a/U7dphX xXJlfDZrmDzLwXTx7l3HdBh09bxCJ1D0Bay7A6ofz0SwYP4szAfq5MZU2r1hJXmdB7therF+EGid U7CYuwd0sr3dpuzZY6mxQDO2cOeO5c+ds/ytW040nN0co2l+rSlrhX4tAs8u+m2Y7+MRl+FWAc6O 6m5g8ph4Oy+16QfMk2sB6GC7ssf1u3c7ua6W52pMpYcPHdOlwcGKbgRjopgve1snmg3DG1iK3G/n thtfchA772A54ID2epErBr3Bn2v0crUqB3IthyKrkdq+3WILF47DH5tGD+R8pLSGUsqOF7EoHhZl rBbGAJntjH0TEe4Ea6dExgHnQSNHJCuyHuWYLdDVaqxlvFjMki+/bHVYj/iyZeOC1gCdSGrLFos9 95zlz561XGen5b791gqXLlmxMGymy6HBqPn0q0QLZW2E5nWMWwPW2zy664AT8LQCbDNgWyVbAbvB TAE38aYmS732miU2bHByPpEmxv1Vq8xno4WNGy2HvOdOnrQhHJGuhbLsR4lN5ZSHF2qhb75vdr4C HIZXAngtL8+QVlcfomMboAkAyCvGcDZP3Hg/3tzsmNepqQ/s22eD9Dzmkvgl0tpobUkA2KZzWQO5 n2P9TvjEBnN4uEIBExzGA69YzXZszhzzsSTxxRgbROZpmwjwOLkkeuLNnGkxHNjA/v2Wv3KlIjbh uQVcVgYfHINURaVtl83m4qxtObK0iN8aJSaR/pXncbn01atNG5iM5tXXWxI/4KwIFmdg714r3EcQ htkd0UJmVKwvwlSv9AGqIErxtBclIsFEcZRM8UdsxozJwF2ZI8Ep1r35puVR2uJXX1lJFidiBSeu w2LcBN5VfjlzaQzihup33G7r6iw2b57rpjOazJZImM9JJjdtstx335nCgwBkeJkgoOO3mUpihGIh O5lWbUnCLylclUWZbLaDNSR+Unr/iy8c8KgWkgaJS7PPgwXcTNPgUSFYeQaZNG/6dJNcPotGWleJ 22OK27Ew1awH2JQGgmG+z40SW/0xygw6kEzkcZwutp5sMQlYYI347NkmPfKmTLHijz9GKmh5+BSu TWJc2biL+Gs64SL7lZcbx03/rNNAj9ypwr4BPErXHI+E7eBsGF/TdGwKkJQrSuNh5Jk0nSYna9j1 iTRZlX524BgPIrNRu1WEh40tiQklvM+i6UQVhOWjov+fsIFVPvJHHyG4DWBFkLLlo5rbDPli4fvv rdjX5xyR5H6ym0gpPXhgxcdBMD1yhVBoPcB9nxi/wV7nyomrh9Pq4ASKyHjh5k0rXL1q/tKlw3I4 mY35i729Vrh924lkVLQYwkZMaDelnDcYqPLZmClV4fp1y5Gdy9PFJxm42M4T5hZu3LASIlPr5Mtc PeTaI8YvIS6rNTgqdKqwTgqWwyXnX3nF4gsw/T8j0Ko+LEcKdZY8p1qrhXLVB6o/CngnN73hvLL6 ZYGX7OVOn7ahY8ecuMQXKS6bhAbDSqaHqAAUEZVaSUXoFPqE2UeHLyAuV/mhH/BBhXU0IsyiEt7s wYNOQZVzepMQcCkrGjxyxCUYtQIsR5yMhJnqilfJ0jp96nR9v0unu9jFRSLFdqxpXAYp7IwqGq3K E1lLVl6OhCCxebPFcBpP1WC6cO2aKxJlKRYVMblRbOuZnA2xuNzfZf7umokldA4I0F08/IbbJSQT s4JqVRhQAL5InWSQYMjDYdSxmMsna9VUxthRTkyTQAi4kgglz7WUUkkipPaD8xuMeFclWSZ8755N SsRx/JI+K9h5dQgQKLCcUZbjLWLfiyitQlLJvEsyxlDaEpsu4g/yXV1OPLKHDjn5VjhRC3TIKfaA 53OYJgEqlydWmd2j0nKSv49Tz1jEjzPleCMrWGUWBXrws8+s0N3tzGSSRNh/8UXzKVk42Q8CMh0w gAvUVtxYrMcQJ6YaoopFlJhrFokC5w+mh7B9gpm+nk+GXwEu6im2dHMchxAT2fQtOp6gkhplZfRM xcvcxYtWwOPJ4qgGHldH/p2TUohKfFOUR8TU5ZHpAslCXva6HAHW8sE67QADUnCaTfybuKQ7KMNV giwqRAMU8Dvw/a0AVpliqaJvZf1RpjLkgp3XG6LnYdGbNctiJMGK4SvA0QVDvGRSA/GrZfZcxkVX 8CRdA0s3z/4Fhi/AWAkbR0SHS9BWKlr/YeA8XvgNL7dqQLWVCU6gWhdc+nfv3nDSG8QzEpWQ4tUC HMwp0FpT4yDtGpdPeXYYERnhnUYA1zFQ0r1AOrSXF6YA+NeqmkrWqCDVbGH2nTKVwYY3qPtaYhGe WOIh8Kx9iy0f4PZjZPx8uFKr8aPicdWhqc+dQlnrkHmPvhPmmyU24cJ+1C4CYBMBGH5f40WOPtFI PAB6nct++kcw/Q2gR31SiUwk9AUA8F8DfohdDwB4Jwy0BeYwSKxrZkxjnE414PAmVdORk0Ge98H8 xwjcaRxk5HegmhmQvr0A/iQyn2XCO7CxlQnbYX+O2Am+IDwteAEWwwHLyPM9np1mjSOIyqEms7N/ y2Sis4ooUQkzUj6ibynT3WPb3fz2OrK+nolVX25kUV+bkNUJ1T1GFE0DZQyu4bgfVHnmfcBVinec uY4Sh8h6SFTGbOPnnLzOcd1QUR3Q5/hzLX0TTLdzEsu4qkBTM9GO8r7lUsMDhdT002zqGHJ9ghik G9BKFMZtEwKuWcpffP/3x3T6JrLXyaPlLLiCq0rUKpw2ch98Em/gb0mBNiSpUj72iGdKAu4Dto/n 1+hdALgA45c+fMLv+hMGHlDwl0wG3HZcnU3M5Y9VMKgyNW7AmukYAvfNMsjvFIr2AVrfb3oQjSsA Pw+755hLRfqnav8HgNV2pZx782UAAAAASUVORK5CYII= --_004_FRXPR01MB0197CE9448E73AB17414E6D5981D0FRXPR01MB0197DEUP_-- From nobody Thu Feb 6 08:53:04 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9912009E; Thu, 6 Feb 2020 08:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKX63E8vjXdT; Thu, 6 Feb 2020 08:52:59 -0800 (PST) Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07E1120089; Thu, 6 Feb 2020 08:52:59 -0800 (PST) Received: by mail-il1-f194.google.com with SMTP id f10so5663374ils.8; Thu, 06 Feb 2020 08:52:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q2Y0S2zPVqGGVs5i0ZweaRHcMbPLXWo7raT8nKmMvgo=; b=r389kSEM9/dBWv80/JPBjSMI2m5fe0ZKT3jc/pNwafEqyMz916s2/Dd+leOFXtVcQE NaPdYE8ND6vqsml4R8nd4WtrG97Xfp6CPtTtd6UoGIJUzRgmfTRsApkyt+PsWt36X0cO RaHkot73uXETjkDW9evdXMHelkXfWlKjfQ9I3T1UBo+HDAEWT9BK79i+zx0e3aIWfEZg FrwIEDjUx3p693rn76db4EFlVWPAkQNrYHxhXJDG+RhZUU0n4pNJ9m2CAmlHJ8Q6Qr44 eRAdanCoBILXzS9G1ihDOJoaT75D39ItkgfauF2t/VkxehX+mhWFfxS9s7z4B3w13ZJV RXGg== X-Gm-Message-State: APjAAAVtzKqMo82bWm6SSWJjPG9aE1v4GJq3aK3klcGlmlrZ2F5Y8jkO oNse0+BQcjlGzasz934bybDJWDRwhRTtcoaeYxx2rQ== X-Google-Smtp-Source: APXvYqxWZQd57P5/k+PYNiRUfAtsN4WtAnPXkZ2cSsqit9V/3ws3UbLb9doL+65IUSxxqAQdCXllbQ1R/lgFLzQkel4= X-Received: by 2002:a92:508:: with SMTP id q8mr4731805ile.187.1581007978859; Thu, 06 Feb 2020 08:52:58 -0800 (PST) MIME-Version: 1.0 References: <158097262126.30614.7797455505583515546.idtracker@ietfa.amsl.com> In-Reply-To: <158097262126.30614.7797455505583515546.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Thu, 6 Feb 2020 11:52:47 -0500 Message-ID: To: Benjamin Kaduk Cc: The IESG , ADD Mailing list , add-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Add] Benjamin Kaduk's Yes on charter-ietf-add-00-02: (with COMMENT) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 16:53:01 -0000 > We use "define a mechanism" for two work items but "describes > mechanisms" for the third -- is this intended to require exactly one > mechanism (as opposed to different mechanisms for, e.g., public Internet > and private-network resolvers) for those items? I agree with EKR's answer here, and I don't think the wording is an issue or needs to be changed. I think we generally understand that "a mechanism" can encompass multiple aspects that might differ for different networks. > This working group will focus on discovery and selection of DNS resolvers > by DNS clients in a variety of networking environments, including public > networks, private networks, and VPNs; supporting both encrypted and > unencrypted resolvers. It is chartered solely to develop technical > mechanisms. Making any recommendations about specific policies for clients > or servers is out of scope. > > Are discussions of situations in which a given technical mechanism is > more or less useful considered to be a policy recommendation that is out > of scope? Again, i think EKR's response is right, and the chairs will be responsible for keeping the discussion away from actual policy issues, with backing from the AD. > And some (style) nits, since I can't un-notice them... You can un-notice them now, because I've edited them away. Barry From nobody Fri Feb 7 09:20:27 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F16512097A; Fri, 7 Feb 2020 09:20:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Cc: add@ietf.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158109602115.11739.2061302115014660192.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 09:20:21 -0800 Archived-At: Subject: [Add] WG Review: Adaptive DNS Discovery (add) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 17:20:24 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-02-17. Adaptive DNS Discovery (add) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: David Lawrence Glenn Deen Assigned Area Director: Barry Leiba Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: add@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/add Archive: https://mailarchive.ietf.org/arch/browse/add/ Group page: https://datatracker.ietf.org/group/add/ Charter: https://datatracker.ietf.org/doc/charter-ietf-add/ Adaptive DNS Discovery (ADD) ==================================== Proposed Working Group Charter Sending DNS messages over encrypted transports, as defined in DNS over TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides benefits to the security and privacy of DNS data. Clients, such as applications and host operating systems, have started adopting these protocols to provide these user benefits. This working group will focus on discovery and selection of DNS resolvers by DNS clients in a variety of networking environments, including public networks, private networks, and VPNs, supporting both encrypted and unencrypted resolvers. It is chartered solely to develop technical mechanisms. Making any recommendations about specific policies for clients or servers is out of scope. Clients adopting encrypted DNS protocols need to determine which DNS servers support those protocols, and which server to use for specific queries if multiple servers are available. These decisions can vary based on the network environment, and also based on the content and purpose of the client queries. Network operators that start offering DNS encryption on their servers also need a way to indicate this support to clients. Communicating information about resolver configuration and behavior allows clients to make more informed decisions about which DNS servers to use. For example, a resolver may be able to resolve private or local names as a split DNS server. The Adaptive DNS Discovery (ADD) working group will work on the following deliverables: - Define a mechanism that allows clients to discover DNS resolvers that support encryption and that are available to the client either on the public Internet or on private or local networks. - Define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions. This could be part of the mechanism used for discovery, above. - Develop an informational document that describes mechanisms for clients to detect specific network environments (such as captive portal and split horizon) and to use that information to inform their DNS configuration. This working group will coordinate with dnsop, doh, and dprive for any changes required in DNS protocols and will make sure that those groups are included in major document reviews at appropriate times. It will also work with capport to ensure that solutions are applicable to captive networks. Milestones: TBD From nobody Fri Feb 7 09:20:39 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BE31209A5; Fri, 7 Feb 2020 09:20:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158109603392.11660.1922289037729458466.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 09:20:33 -0800 From: IETF Secretariat Archived-At: Subject: [Add] Datatracker State Update Notice: X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 17:20:37 -0000 State changed to External Review (Message to Community, Selected by Secretariat). Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-add/ From nobody Fri Feb 7 09:20:49 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5727120999; Fri, 7 Feb 2020 09:20:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: "The IESG" , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158109604173.11673.1073379069311587706.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 09:20:41 -0800 From: IETF Secretariat Archived-At: Subject: [Add] Telechat update notice: X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 17:20:46 -0000 Telechat date has been changed to 2020-02-20 from 2020-02-06 Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-add/ From nobody Tue Feb 11 11:24:25 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C79120A42 for ; Tue, 11 Feb 2020 11:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=canada.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMhi4YGrh0xT for ; Tue, 11 Feb 2020 11:22:25 -0800 (PST) Received: from mx1.canada.ca (mx1.canada.ca [205.193.214.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2965120A55 for ; Tue, 11 Feb 2020 11:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=canada.ca; i=@canada.ca; q=dns/txt; s=mx1; t=1581448945; x=1612984945; h=from:to:subject:date:mime-version; bh=9Fi5xQMfnUEe9NikX60iRguZhx8BokKf8GgwJZWGPT0=; b=uXqfsfkh5NeyyKMLYoYB41kXSezxv6I9eGU62PX3R9sOdfPhWGeWJPKI sDv6/oTZdONfG6FN8Yn8e6gtoSi/MgZeiKpsKATUEdTdQY+GfxAxXH2aD OQdnskTKv2YGwva+b4F3xzBFAGgHDBjezAGAIYLoOi2z8PS1nOd4QS7b4 7Pc02lxTXKRrcNFmIdy/pqZnpmGIzzPtwgY1WaZcCNK0jR3eEj5qWr1bk TBohYgnYm5JMn5MPZRxHTaOPIy4x2XtHRYeofz8lqOk9ckrag9DTZwQXN wGNinm3mpeZW2VKOFZj4NsW7/Jq+c6PWiE9wd/FG8pMANr1S7uE/tWCil w==; X-Time-IN: 11 Feb 2020 19:22:10 -0000 From: "Juskevicius, Ed (IC)" To: "add@ietf.org" Thread-Topic: Updated ADD Charter proposal +1 Thread-Index: AdXhD+znZD2IKzNBQeenxH6gM8FdFA== Date: Tue, 11 Feb 2020 19:21:56 +0000 Accept-Language: en-CA, en-US Content-Language: en-US x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_9c2a3fe0e99444238467549f7b8926a7PEVDACDEXC027birchintbe_" MIME-Version: 1.0 Message-Id: <20200211192224.C2965120A55@ietfa.amsl.com> Archived-At: X-Mailman-Approved-At: Tue, 11 Feb 2020 11:24:23 -0800 Subject: Re: [Add] Updated ADD Charter proposal +1 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 19:22:37 -0000 --_000_9c2a3fe0e99444238467549f7b8926a7PEVDACDEXC027birchintbe_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am supportive of the draft charter being proposed for ADD < charter-ietf-= add-00-04 > that was last updated 2020-02-07. Regards, Ed Juskevicius Manager, ICT Resilience Innovation, Science and Economic Development / Government of Canada Ed.Juskevicius@canada.ca / Tel: 613-220-93= 22 / TTY: 1-866-694-8389 Gestionnaire, R=E9silience des TIC Innovation, Sciences et D=E9veloppement =E9conomique / Gouvernement du Cana= da Ed.Juskevicius@canada.ca / T=E9l: 613-220-9= 322 / ATS: 1-866-694-8389 --_000_9c2a3fe0e99444238467549f7b8926a7PEVDACDEXC027birchintbe_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am supportive of the draft charter being pro= posed for ADD < charter-ietf-add-00-04 > that was last updated 2020-0= 2-07.
 
Regards,
 
<= b>Ed Juskevicius
Manager, ICT Resilience
Innovation, Science and Economic Development /= Government of Canada
Ed= .Juskevicius@canada.ca / Tel: 613-22= 0-9322 / TTY: 1-866-694-8389
 
Gestionnaire, R=E9silience des TIC
Innovation, Sciences et D=E9veloppement =E9con= omique / Gouvernement du Canada
Ed.= Juskevicius@canada.ca / T=E9l: 613-2= 20-9322 / ATS: 1-866-694-8389
 
 
 --_000_9c2a3fe0e99444238467549f7b8926a7PEVDACDEXC027birchintbe_-- From nobody Thu Feb 13 10:43:53 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB111201AA; Thu, 13 Feb 2020 10:43:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: avezza@amsl.com, add@ietf.org, barryleiba@computer.org, add-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158161943216.20564.11911125911262324281.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2020 10:43:52 -0800 Archived-At: Subject: [Add] add - New Meeting Session Request for IETF 107 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 18:43:52 -0000 A new meeting session request has just been submitted by Amy K. Vezza, on behalf of the add working group. --------------------------------------------------------- Working Group Name: Adaptive DNS Discovery Area Name: Internet Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Technology Overlap: capport dhc dnsop doh dprive opsawg mops wpack People who must be present: Barry Leiba Glenn Deen David C Lawrence Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Feb 20 05:09:38 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE241200F9; Thu, 20 Feb 2020 05:09:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: add@ietf.org, add-chairs@ietf.org, add@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158220417722.12484.18328972472163955473.idtracker@ietfa.amsl.com> Date: Thu, 20 Feb 2020 05:09:37 -0800 Archived-At: Subject: [Add] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Record_on_charter-ie?= =?utf-8?q?tf-add-00-04=3A_=28with_COMMENT=29?= X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 13:09:38 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-add-00-04: No Record 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: ---------------------------------------------------------------------- Waiting for an update before I ballot... From nobody Thu Feb 20 05:11:56 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A591200FD; Thu, 20 Feb 2020 05:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWLg_j0evmIk; Thu, 20 Feb 2020 05:11:44 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E651200F9; Thu, 20 Feb 2020 05:11:44 -0800 (PST) Received: from 200116b82c4c570089df8513372e4081.dip.versatel-1u1.de ([2001:16b8:2c4c:5700:89df:8513:372e:4081]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j4lcE-0007DV-9I; Thu, 20 Feb 2020 14:11:42 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <158220417722.12484.18328972472163955473.idtracker@ietfa.amsl.com> Date: Thu, 20 Feb 2020 14:11:41 +0100 Cc: The IESG , add@ietf.org, add-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158220417722.12484.18328972472163955473.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1582204304;0f3e71bc; X-HE-SMSGID: 1j4lcE-0007DV-9I Archived-At: Subject: Re: [Add] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Record_on_charter-ie?= =?utf-8?q?tf-add-00-04=3A_=28with_COMMENT=29?= X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 13:11:47 -0000 Sorry, this was on the wrong charter=E2=80=A6 I=E2=80=99m a yes here = now! > On 20. Feb 2020, at 14:09, Mirja K=C3=BChlewind via Datatracker = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > charter-ietf-add-00-04: No Record >=20 > 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.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-add/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Waiting for an update before I ballot... >=20 >=20 >=20 From nobody Fri Feb 21 09:09:53 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B62120168; Fri, 21 Feb 2020 09:09:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , add@ietf.org, add-chairs@ietf.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158230497422.29089.513949427831779800.idtracker@ietfa.amsl.com> Date: Fri, 21 Feb 2020 09:09:34 -0800 Archived-At: Subject: [Add] WG Action: Formed Adaptive DNS Discovery (add) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 17:09:35 -0000 A new IETF WG has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. Adaptive DNS Discovery (add) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: David Lawrence Glenn Deen Assigned Area Director: Barry Leiba Internet Area Directors: Suresh Krishnan Éric Vyncke Mailing list: Address: add@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/add Archive: https://mailarchive.ietf.org/arch/browse/add/ Group page: https://datatracker.ietf.org/group/add/ Charter: https://datatracker.ietf.org/doc/charter-ietf-add/ Sending DNS messages over encrypted transports, as defined in DNS over TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides benefits to the security and privacy of DNS data. Clients, such as applications and host operating systems, have started adopting these protocols to provide these user benefits. This working group will focus on discovery and selection of DNS resolvers by DNS clients in a variety of networking environments, including public networks, private networks, and VPNs, supporting both encrypted and unencrypted resolvers. It is chartered solely to develop technical mechanisms. Making any recommendations about specific policies for clients or servers is out of scope. Clients adopting encrypted DNS protocols need to determine which DNS servers support those protocols, and which server to use for specific queries if multiple servers are available. These decisions can vary based on the network environment, and also based on the content and purpose of the client queries. Network operators that start offering DNS encryption on their servers also need a way to indicate this support to clients. Communicating information about resolver configuration and behavior allows clients to make more informed decisions about which DNS servers to use. For example, a resolver may be able to resolve private or local names as a split DNS server. The Adaptive DNS Discovery (ADD) working group will work on the following deliverables: - Define a mechanism that allows clients to discover DNS resolvers that support encryption and that are available to the client either on the public Internet or on private or local networks. - Define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions. This could be part of the mechanism used for discovery, above. - Develop an informational document that describes mechanisms for clients to detect specific network environments (such as captive portal and split horizon) and to use that information to inform their DNS configuration. This working group will coordinate with dnsop, doh, and dprive for any changes required in DNS protocols and will make sure that those groups are included in major document reviews at appropriate times. It will also work with capport to ensure that solutions are applicable to captive networks. From nobody Tue Feb 25 10:01:22 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87043A1247 for ; Tue, 25 Feb 2020 10:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XDQuuX6AQzu for ; Tue, 25 Feb 2020 10:01:18 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B603A1243 for ; Tue, 25 Feb 2020 10:01:17 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id r27so351255otc.8 for ; Tue, 25 Feb 2020 10:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OK7nYjp4gcHcMoU3izVQF9zZe1Bz+/Ccb/yN/saZAO0=; b=uESM5cci1+6Gni7DbnOI+d4O+wdldqmJA08SL3KauanfXM1n64NH/uIigW+duFQiBQ 5YMQMO06HWn4YLBlZqELNRPIZFoMcxlDScneiXUJrCqBSbM8mcgMcdf8XN+ONt1n/l5c XcQhb3lxieipyBHFgLskYzm97thFCW3ZA2oMnUFk4gAeGB72ms8RWEgv5LrITAMtTK6d 4e4czkRygvrVFujgxwuZpTEI6NqWzTpaxUB0q+nk5eoGSTU5476aBwk3QQ3sXR5Uzp1I otgK9oVwbhH3eM0kAk8I/d5gKXdlbLiut8WMd+EgPAQaxXxRQBQXBRlBxfyOxb3rO1B0 15dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OK7nYjp4gcHcMoU3izVQF9zZe1Bz+/Ccb/yN/saZAO0=; b=UQHOKuaTZ2sV1LO2FOdDOzUE9n6vSUP3wDL7dK8JE8pYN74JvLiYrie4OkYUjkN5ZM 0XS7IZ1Jf9bkD54M/D8hLd0PZbryRMQv+s4tSm/CjmrV9QMZFBay1O2GXAbXeXO76KOc r8spsSAnVFtDnqkJvR/tk4slK5CDy/wShq8nc0nWTdmPeNSeWag7lTdx6y1NxLfPPWnP BDNwLXtOwmUT51gKt+aBLOeHwNP1dybzAh0+aaRKGtWamfs+po8XVxYBUqKkoIqPChCx 2w8NgQr+SzuN93QkSRhZAskpX2diLEGdnVzDMNGWB5j3s+4chh5M4Jgm4GIWIjo0VhsC rgDw== X-Gm-Message-State: APjAAAVRRufnA0uXbQpKMb3Ctt3WPRx5Q7AOAD6ASjFbWoqSK6wyNyAR qrTTJ9FPSW2yije3ec6wfrDstkMYzfwThEu8GJOpzXKR X-Google-Smtp-Source: APXvYqwF2D7wpipZY7QN0dBZgDyA7nE06vygjer0BR2sswMlaIXFo3/6i052ayw3HVskzT1LxqjvOENBIh0XMjyFx+A= X-Received: by 2002:a05:6830:16c5:: with SMTP id l5mr46504290otr.165.1582653676945; Tue, 25 Feb 2020 10:01:16 -0800 (PST) MIME-Version: 1.0 From: Ted Hardie Date: Tue, 25 Feb 2020 10:00:51 -0800 Message-ID: To: ADD Mailing list , Jari Arkko , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000003788e6059f6a46b2" Archived-At: Subject: [Add] draft-arkko-abcd-distributed-resolver-selection X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 18:01:21 -0000 --0000000000003788e6059f6a46b2 Content-Type: text/plain; charset="UTF-8" Howdy, Jari, Martin, and I put together draft-arkko-abcd-distributed-resolver-selection to start a discussion on whether DNS clients can improve their privacy through the use of a set of multiple recursive resolver services. We think it might be in scope for ADD, since the charter says the group "will focus on discovery and selection of DNS resolvers" and this discusses the impact of selecting more than one. Do the chairs and the working group agree? If so, can we ask for agenda time at IETF 107 to present? thanks, Ted --0000000000003788e6059f6a46b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

Jari, Martin, and I p= ut together draft-arkko-abcd-distribute= d-resolver-selection to start a discussion on whe= ther DNS clients can improve their privacy through the use of a set of mult= iple recursive resolver services.=C2=A0 We think it might be in scope for A= DD, since the charter says the group "will focus on discovery and sele= ction of DNS resolvers" and this discusses the impact of selecting mor= e than one.=C2=A0

Do the chairs an= d the working group agree?=C2=A0 If so, can we ask for agenda time at IETF = 107 to present?=C2=A0
=
thanks,

<= /div>
Ted
--0000000000003788e6059f6a46b2-- From nobody Tue Feb 25 13:06:12 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3673A15C9 for ; Tue, 25 Feb 2020 13:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwUpUHRoaG44 for ; Tue, 25 Feb 2020 13:06:09 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB4C3A15C8 for ; Tue, 25 Feb 2020 13:06:08 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id q23so478387ljm.4 for ; Tue, 25 Feb 2020 13:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5L7uThNc6Fq/8+JYFriLJk5a2ft5NAgaO7Ydck5pyJg=; b=iYEGIsVORf0CwKWOjBc9ZA1ddIiBdq6onHgqi1wUQlJANUqvNplXGjkp257sKOZZ6s +GptgKpJUqnKzarw3JgLA2cPf+Wu9ztMwADnZ+TqG3rhonXLHSwWhOU8sBaDxVWvMez6 06ZXSMqQIq0/BZzKadvbZF6HbPTFO12MCT5ji7zLHETL27Rgaw/7QrsXeFLea/UNk80L mkWXb/qh9IXannkXT9n4goSdOrgx5WBKTQupvWfLi9cWzI6XbJoVF+EXGtMYy9riH8/H qGAKcorsogcirbMYudjPkB6X0UX3LWJMPJ+GkLAHhw+0jby0igYhXRPcKAwc/uCZq0uS kOiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5L7uThNc6Fq/8+JYFriLJk5a2ft5NAgaO7Ydck5pyJg=; b=iX4maH4Pqf9On7ZVAEt/y0Kwm8ll3MlDd1LWBVZZPk+pZhZY53D8UJPdQHVtsjOQdv aF4UlesfJvjGCRgu7wibZjUDfPfk9ic//whbzoY0m4Z8UD6ell2dKToC0KaZd/H7WRsp XTQ5FtsRyzReUVir0ozNTG9PoWuHA+/Byrje+VSQ4FJRcTtXtO1QRYWI1wa4gfNWW8Mk 4+xqZkLwLR8dVrT9avchvDuhxzzpEm0N9UodUHNmNzvGIJW8Mru0XuihHTCv5c6kd529 v3ukg1A/26+lSN1cpnaomX2+430uaT48aU/QEob2g5clUuNkyCIkn7hvs7cfpl5y+Xs4 Vx1Q== X-Gm-Message-State: APjAAAXRH/MqqeG5cfKKv5sX+ZZDXVLRzfBa7sJ2dBLbjmvMhOL/sOf7 IpOwpifcXFRFlBKEw6L6PLUryrtBQqViLrmRYnISdA== X-Google-Smtp-Source: ADFU+vsVioSjnijv8VcfwHG8Y3TQJiOjK0Cwv0WphPEZFvuLlw/Chh1nkRGcDxJBmmScU74rq1uoUAmYbcko3wfnIVI= X-Received: by 2002:a2e:9b12:: with SMTP id u18mr562232lji.274.1582664766682; Tue, 25 Feb 2020 13:06:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 25 Feb 2020 13:05:29 -0800 Message-ID: To: Ted Hardie Cc: ADD Mailing list , Jari Arkko , Martin Thomson Content-Type: multipart/alternative; boundary="00000000000037b7f1059f6cdb91" Archived-At: Subject: Re: [Add] draft-arkko-abcd-distributed-resolver-selection X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 21:06:11 -0000 --00000000000037b7f1059f6cdb91 Content-Type: text/plain; charset="UTF-8" I'd be interested in seeing a presentation on this. I don't really agree with much of the analysis but I believe the topic is relevant. -Ekr On Tue, Feb 25, 2020 at 10:01 AM Ted Hardie wrote: > Howdy, > > Jari, Martin, and I put together > draft-arkko-abcd-distributed-resolver-selection > to > start a discussion on whether DNS clients can improve their privacy through > the use of a set of multiple recursive resolver services. We think it > might be in scope for ADD, since the charter says the group "will focus on > discovery and selection of DNS resolvers" and this discusses the impact of > selecting more than one. > > Do the chairs and the working group agree? If so, can we ask for agenda > time at IETF 107 to present? > > thanks, > > Ted > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000037b7f1059f6cdb91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd be interested in seeing a presentation on thi= s. I don't really agree with much of the analysis but I believe the top= ic is relevant.

-Ekr


On Tu= e, Feb 25, 2020 at 10:01 AM Ted Hardie <ted.ietf@gmail.com> wrote:
Howdy,

Jari, Martin, and I put together draft-arkko-abcd-distributed-resolver-selection to start a discussion on whether DNS clients can improve thei= r privacy through the use of a set of multiple recursive resolver services.= =C2=A0 We think it might be in scope for ADD, since the charter says the gr= oup "will focus on discovery and selection of DNS resolvers" and = this discusses the impact of selecting more than one.=C2=A0

<= div>Do the chairs and the working group agree?=C2=A0 = If so, can we ask for agenda time at IETF 107 to present?=C2=A0
=

thanks,

T= ed
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000037b7f1059f6cdb91-- From nobody Tue Feb 25 13:20:58 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5B13A1630 for ; Tue, 25 Feb 2020 13:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DekKPvrFz897 for ; Tue, 25 Feb 2020 13:20:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A316F3A1623 for ; Tue, 25 Feb 2020 13:20:49 -0800 (PST) Received: from [172.17.121.48] (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 01PLKhR7076501 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Feb 2020 15:20:44 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1582665646; bh=WL2Pws1oUVRECU9pTVPEeBgnDju6P2ONwGx25XwtLsQ=; h=Subject:To:References:From:Date:In-Reply-To; b=sxjoi+M8FHJ8X+PeVcXwJJsQZVcFzNoktCqRhbeexuncHOjH3gIAEjPYsG8OhhW/G agfA9dvPbqkbAjwwR/urf0sRBKTUcoNkHhRdvgrVvHX3EyEB4/kHrWKkO18n5Lfd+u 2Y82LUJMIzjpF39qoQ6+CQ+p0FZA4YtMwtz0XFvI= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be [172.17.121.48] To: Ted Hardie , ADD Mailing list , Jari Arkko , Martin Thomson References: From: Adam Roach Message-ID: <0bb2b0fb-002c-bf81-3dc8-898532155079@nostrum.com> Date: Tue, 25 Feb 2020 15:20:37 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DF0092BAC2D4AF4EDD66A01A" Content-Language: en-US Archived-At: Subject: Re: [Add] draft-arkko-abcd-distributed-resolver-selection X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 21:20:57 -0000 This is a multi-part message in MIME format. --------------DF0092BAC2D4AF4EDD66A01A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Not relating to the question at hand as much as the contents -- it's probably useful in any treatment of this topic to include a discussion of how to handle additional records. E.g., if the query distribution algorithm would ordinarily query server A for record X, but has already received record X as additional information from server B, what behavior would we recommend? (A simple analysis would say to use the already-received information, since it minimizes transmission of queries altogether.) /a On 2/25/2020 12:00 PM, Ted Hardie wrote: > Howdy, > > Jari, Martin, and I put together > draft-arkko-abcd-distributed-resolver-selection > > to start a discussion on whether DNS clients can improve their privacy > through the use of a set of multiple recursive resolver services.  We > think it might be in scope for ADD, since the charter says the group > "will focus on discovery and selection of DNS resolvers" and this > discusses the impact of selecting more than one. > > Do the chairs and the working group agree?  If so, can we ask for > agenda time at IETF 107 to present? > > thanks, > > Ted > --------------DF0092BAC2D4AF4EDD66A01A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Not relating to the question at hand as much as the contents -- it's probably useful in any treatment of this topic to include a discussion of how to handle additional records. E.g., if the query distribution algorithm would ordinarily query server A for record X, but has already received record X as additional information from server B, what behavior would we recommend?

(A simple analysis would say to use the already-received information, since it minimizes transmission of queries altogether.)

/a

On 2/25/2020 12:00 PM, Ted Hardie wrote:
Howdy,

Jari, Martin, and I put together draft-arkko-abcd-distributed-resolver-selection to start a discussion on whether DNS clients can improve their privacy through the use of a set of multiple recursive resolver services.  We think it might be in scope for ADD, since the charter says the group "will focus on discovery and selection of DNS resolvers" and this discusses the impact of selecting more than one. 

Do the chairs and the working group agree?  If so, can we ask for agenda time at IETF 107 to present? 

thanks,

Ted


--------------DF0092BAC2D4AF4EDD66A01A-- From nobody Tue Feb 25 13:26:41 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19CB3A1624 for ; Tue, 25 Feb 2020 13:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Smitt-SSynM2 for ; Tue, 25 Feb 2020 13:26:39 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6158F3A1623 for ; Tue, 25 Feb 2020 13:26:39 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id c16so831699oic.3 for ; Tue, 25 Feb 2020 13:26:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ybPwGhOjzKVJSHtID5rM0wJxHg715hCc9ecekeeyrqM=; b=JNE85cA+wf8BNNnAgY1R5n2A8I1hERMaPkTRhnAKi7poXIwxiPvvFyyXYbMQ1vk54U 6HXGlXNjXn8ZxtSVAhehrWtXFTL16nj8EMg7PgpQEm7XDHkVUc10EUexc2Ql7AucbbWU b1mW8bhJVKwyu4z02hZkJXStf+fwd0rePtFRAZG6JVjjsQ053V9eJwRvjD4sbBQ9IeJw oyflwxBZG4jQ+B0uNu+glRPXdEa13Q3BO5d7lC8++fqMRCRBljrB9vq60wD1Zqbe/6M4 dyl7akby1of4FH6lQ1lbfNhPCwbPVTMthQOwekJM5lQJl7GUHSODdBXupGPZowu8R21c 8K7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ybPwGhOjzKVJSHtID5rM0wJxHg715hCc9ecekeeyrqM=; b=n8mSC3qK7thsZTAoArlXdsFTFIbblTroPvNA2JQn5Whff1HPAhmi6fSfib3GcznSik 7pug4BzAhRoRm3K7865UwVQ4umGHDvJFUba/NQCld5VJsIo97ALFdlHjpTCCSZpV94ZN SfD1j3JBSAKnVxp2zuz+fWkRWjmdF+E86k9Gcu8DrGSUeRqH+04SbRjAGWCjB8A5Rbmz Xyo9FYv3AaEqibXEa6yJnxs946J/KiKiv1gwmoaNKzWvWNU3wj6HnOO5hBcIOrKrr7+J Cdye9UtCcj+/DFT0Iam/GYaHERM1jUj9DLOKkVYWkhc4x0SMNPXd6VWl1XlcRgYYXBWp zlGw== X-Gm-Message-State: APjAAAXu1ljdCJ54v4FD2CLWBXBA7mI+2AxO4fOkrH+XlvjfjIPohjYx 2JXf8gABVxE6cdTxD6/YvsxDwR5Cyhfoj51Vqw4= X-Google-Smtp-Source: APXvYqxC4RCGIvk3Ldk4MGKbBi/YmnDOHDGDENBYVtsLP7lOUHbKIrzKxkj1NGk65uAXddjixLtmQRUQ/+zo/oC9fN0= X-Received: by 2002:aca:5194:: with SMTP id f142mr727940oib.100.1582665998668; Tue, 25 Feb 2020 13:26:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Kline Date: Tue, 25 Feb 2020 13:26:27 -0800 Message-ID: To: Ted Hardie Cc: ADD Mailing list , Jari Arkko , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000a61646059f6d2407" Archived-At: Subject: Re: [Add] draft-arkko-abcd-distributed-resolver-selection X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 21:26:41 -0000 --000000000000a61646059f6d2407 Content-Type: text/plain; charset="UTF-8" I think section 4 (maybe) could have some discussion of per-app based resolver selection. Mobile operating systems can sometimes have more data about which apps are making which queries than, say, general Unix-derived OSes. Also, with DoH, this might be something that can be chosen/randomized by the webpage itself (e.g. on a per-service-worker basis or something; /me handwaves in W3C). On Tue, Feb 25, 2020 at 10:01 AM Ted Hardie wrote: > Howdy, > > Jari, Martin, and I put together > draft-arkko-abcd-distributed-resolver-selection > to > start a discussion on whether DNS clients can improve their privacy through > the use of a set of multiple recursive resolver services. We think it > might be in scope for ADD, since the charter says the group "will focus on > discovery and selection of DNS resolvers" and this discusses the impact of > selecting more than one. > > Do the chairs and the working group agree? If so, can we ask for agenda > time at IETF 107 to present? > > thanks, > > Ted > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000a61646059f6d2407 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think section 4 (maybe) could have some discussion of pe= r-app based resolver selection.

Mobile operating systems= can sometimes have more data about which apps are making which queries tha= n, say, general Unix-derived OSes.

Also, with DoH,= this might be something that can be chosen/randomized by the webpage itsel= f (e.g. on a per-service-worker basis or something; /me handwaves in W3C).<= /div>

On Tue, Feb 25, 2020 at 10:01 AM Ted Hardie <ted.ietf@gmail.com> wrote:
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000a61646059f6d2407-- From nobody Tue Feb 25 13:56:56 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0003A16A0 for ; Tue, 25 Feb 2020 13:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YoxZd_GMdJg for ; Tue, 25 Feb 2020 13:56:53 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66BA3A169F for ; Tue, 25 Feb 2020 13:56:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 75BF9BE24; Tue, 25 Feb 2020 21:56:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImPrH--nV72p; Tue, 25 Feb 2020 21:56:45 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 89B62BE20; Tue, 25 Feb 2020 21:56:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1582667805; bh=2ViOlDvZ/cp61nRXX5hgyNLPj8BkZSUF66OLyGhs6eA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kmuEqONNlmzxvAaqliSZOypCJfJpT4Yw3DwxiJoTmx/cwI3lL1ysONDEpl5C+x0LK V0T8gCq3m8rfLcDamchriurDO0WY+jCDhJo/uKa7w17bcDdj8GWr7MCm4ifBhmnFBc N0WlXSoNf9IkSwQ8eIlIZI/ZG+fM0g+DeKgRNnkM= To: Eric Rescorla , Ted Hardie Cc: ADD Mailing list , Jari Arkko , Martin Thomson References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <4c9fc507-23a5-61a8-d05d-568e2059e63c@cs.tcd.ie> Date: Tue, 25 Feb 2020 21:56:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZymspmJbLJBtq1yXnbvNWaIzGFqXXm27o" Archived-At: Subject: Re: [Add] draft-arkko-abcd-distributed-resolver-selection X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 21:56:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZymspmJbLJBtq1yXnbvNWaIzGFqXXm27o Content-Type: multipart/mixed; boundary="VfxZn2ZE3VUzsWGXwJBvTzuZKwKcqKcZg"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , Ted Hardie Cc: ADD Mailing list , Jari Arkko , Martin Thomson Message-ID: <4c9fc507-23a5-61a8-d05d-568e2059e63c@cs.tcd.ie> Subject: Re: [Add] draft-arkko-abcd-distributed-resolver-selection References: In-Reply-To: --VfxZn2ZE3VUzsWGXwJBvTzuZKwKcqKcZg Content-Type: multipart/mixed; boundary="------------4C9B83A64ECB8C52E8CAD152" Content-Language: en-US This is a multi-part message in MIME format. --------------4C9B83A64ECB8C52E8CAD152 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 25/02/2020 21:05, Eric Rescorla wrote: > I'd be interested in seeing a presentation on this.=20 +1 > I don't really agree > with much of the analysis but I believe the topic is relevant. I suspect this is an area where some good new ideas may be needed to make progress. On the draft itself, the set of available recursives is often not the same as the set of configured/potential recursives, in my experience mainly because of IPv4/IPv6 and blocking of 853. e.g. when I'm on the TCD college n/w (during office-ish hours:-) 853 is blocked and IPv6 only works on the wireless interface, etc. All of that could skew the output of any selection algorithm with relatively long cycle durations. Cheers, S. >=20 > -Ekr >=20 >=20 > On Tue, Feb 25, 2020 at 10:01 AM Ted Hardie wrote:= >=20 >> Howdy, >> >> Jari, Martin, and I put together >> draft-arkko-abcd-distributed-resolver-selection >> to >> start a discussion on whether DNS clients can improve their privacy th= rough >> the use of a set of multiple recursive resolver services. We think it= >> might be in scope for ADD, since the charter says the group "will focu= s on >> discovery and selection of DNS resolvers" and this discusses the impac= t of >> selecting more than one. >> >> Do the chairs and the working group agree? If so, can we ask for agen= da >> time at IETF 107 to present? >> >> thanks, >> >> Ted >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> >=20 >=20 --------------4C9B83A64ECB8C52E8CAD152 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------4C9B83A64ECB8C52E8CAD152-- --VfxZn2ZE3VUzsWGXwJBvTzuZKwKcqKcZg-- --ZymspmJbLJBtq1yXnbvNWaIzGFqXXm27o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5VmBwACgkQWrL68XsX K+ogihAAj2NwB1VRiZWxDvocgaJBvk0lTqPvQvJDkHI0oKwvNSgZ96kiIHt7k9iU F2U81ECorWTbfkti1V2fvIYBPB6GJZ6G74vQvS7tpjKamKGZs57ySOYVnLxjHR3o w8TYWXpxjjY3ywySfYNHryBzkjCIHC4F3+cEsufEBJRF2WB1EOIMOulSMYMsT0wm 2ADua14Em8ekH6EEm8pfdD2wSC81MV3rzk8DWNpaZg3nKb8P/RlhrFq44pFtxvE1 gPKf6BlHKKsOTquMGOakRNqEbB5tj0Fxy/E6ZH2Xbo9cVOFUYWzpsmzFXixDSWyP 7kowcY6iS1PLftzFt8vi0zdoSSvGw6sOaTF2lLMWYt2ooPTIEYoa4nMPLOXAjpJ0 0Gs2kURpZ1ux+hBMvKNe5I3qmn0DMvaRzsetLWe3SByF6EjyPnYskM1qOfOKEUdg KKxzh/grfkiydVmyid9Ck1C2rnJuFURHGr/EosraHYEjbgzb4bGnsPUFrXmX9EtG gbTPGI+KQisLIdbUTW4Jam2zA8QMjRKucZ0jsB2mCoT8XhpunPJ9s590YJBJ6pBP x3+Mf/VVxzBGWPRb1aAfcnLuA/3OaH+GwWEtmVEoHDLbwRBCzZHOk/SmfIrwBWNv OxrYjcYTsRGZdVevZHI0dUk+BHNRIGuNBbbAbehZAnXKr6j2XDw= =AIMv -----END PGP SIGNATURE----- --ZymspmJbLJBtq1yXnbvNWaIzGFqXXm27o-- From nobody Wed Feb 26 02:20:44 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370893A124E for ; Wed, 26 Feb 2020 02:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzDSb2wqzX2k for ; Wed, 26 Feb 2020 02:20:38 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EAD3A124C for ; Wed, 26 Feb 2020 02:20:37 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 8AEA56A275 for ; Wed, 26 Feb 2020 11:20:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1582712435; bh=yw9AzWKnWabuJas9V2doNJENWf2b4hpMwhqf+GymvHI=; h=Date:From:To:In-Reply-To:References:Subject:From; b=bidPQ8UkcsRma92oIBguc0lv/f7qfp2g4tMgF13YKF29uE080tfRKp3lVWZLVb+D4 GkASBNSGAPr3KsyECZ1H9a4BoSTPHg/A0ZAGO6iQeXY2uvM5rRrCBQ9TL/Q3FDi1AZ 3l3C7zqJlCH+mJ1fiuQpU2mNG3DKbnY3FrPGwj2gN3xZz192o31rPT7CsLfDTVltPw v0zvXKAWEIH+pFDOOdw6layA8IAeWKVx/ErPJ9OxhxJOQJPW4RWz8bd5y7/Afw6pJX Qs9bihkPjCLiZeMJoHuuSVlJ/QGrBtHkqw8TrMEBqOTl5DDls5+OS1WL4Dr6Bk9vrq EWKfRrvwKegnQ== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 7E17A3C0331 for ; Wed, 26 Feb 2020 11:20:35 +0100 (CET) Date: Wed, 26 Feb 2020 11:20:35 +0100 (CET) From: Vittorio Bertola To: ADD Mailing list Message-ID: <1280546249.15154.1582712435424@appsuite-gw1.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15152_651447221.1582712435410" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev5 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] draft-arkko-abcd-distributed-resolver-selection X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 10:20:42 -0000 ------=_Part_15152_651447221.1582712435410 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 25/02/2020 19:00 Ted Hardie ha scritto: > > > Howdy, > > Jari, Martin, and I put together draft-arkko-abcd-distributed-resolver-selection https://datatracker.ietf.org/doc/draft-arkko-abcd-distributed-resolver-selection/?include_text=1 to start a discussion on whether DNS clients can improve their privacy through the use of a set of multiple recursive resolver services. We think it might be in scope for ADD, since the charter says the group "will focus on discovery and selection of DNS resolvers" and this discusses the impact of selecting more than one. > This is another idea that looks great from a purely technical standpoint but a total nightmare in terms of policy, both public and local, both legal and technical (e.g. network security). Also, it only increases privacy if by privacy you mean spreading your data as much as possible among many parties, but not if (as per the GDPR's data minimization principle) by privacy you mean minimizing the amount of data you give away and the number of parties who know something about you - let alone the discussion on whether this model in the end would lead to more or less centralization in terms of DNS providers. For example, if the client, rather than using a single resolver in its own country that offers reasonable privacy guarantees, spreads its queries among N resolvers that are all or almost all run under a single foreign jurisdiction, this creates an additional risk for surveillance by that country's national security agencies that did not exist before, and that might outweigh any advantage gained by spreading the queries across multiple resolvers. This said, of course I'm fine with a presentation, but I challenge the draft's conclusion that these strategies are "generally beneficial in the common cases". If this ever becomes a working item, the analysis should cover all the pros and cons and the discussion should go well beyond the IETF to understand the conditions for doing this that would make all stakeholders happy (like it should have been done with DoH). -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_15152_651447221.1582712435410 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 25/02/2020 19:00 Ted Hardie <ted.ietf@gmail.com> ha scritto:


Howdy,

Jari, Martin, and I put together draft-arkko-abcd-distributed-resolver-selection to start a discussion on whether DNS clients can improve their privacy through the use of a set of multiple recursive resolver services.  We think it might be in scope for ADD, since the charter says the group "will focus on discovery and selection of DNS resolvers" and this discusses the impact of selecting more than one. 
This is another idea that looks great from a purely technical standpoint but a total nightmare in terms of policy, both public and local, both legal and technical (e.g. network security). Also, it only increases privacy if by privacy you mean spreading your data as much as possible among many parties, but not if (as per the GDPR's data minimization principle) by privacy you mean minimizing the amount of data you give away and the number of parties who know something about you - let alone the discussion on whether this model in the end would lead to more or less centralization in terms of DNS providers.

For example, if the client, rather than using a single resolver in its own country that offers reasonable privacy guarantees, spreads its queries among N resolvers that are all or almost all run under a single foreign jurisdiction, this creates an additional risk for surveillance by that country's national security agencies that did not exist before, and that might outweigh any advantage gained by spreading the queries across multiple resolvers.

This said, of course I'm fine with a presentation, but I challenge the draft's conclusion that these strategies are "generally beneficial in the common cases". If this ever becomes a working item, the analysis should cover all the pros and cons and the discussion should go well beyond the IETF to understand the conditions for doing this that would make all stakeholders happy (like it should have been done with DoH).

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_15152_651447221.1582712435410-- From nobody Fri Feb 28 14:37:51 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF7E3A1FA5; Fri, 28 Feb 2020 14:35:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: add@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292931562.19931.6663708910334376682@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:15 -0800 Archived-At: Subject: [Add] add - Requested session has been scheduled for IETF 107 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:22 -0000 Dear Amy Vezza, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. add Session 1 (2:00 requested) Monday, 23 March 2020, Afternoon Session II 1550-1750 Room Name: Regency F size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/add.ics Request Information: --------------------------------------------------------- Working Group Name: Adaptive DNS Discovery Area Name: Internet Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Technology Overlap: capport dhc dnsop doh dprive opsawg mops wpack People who must be present: Barry Leiba Glenn Deen David C Lawrence Resources Requested: Special Requests: ---------------------------------------------------------