From nobody Sat Aug 1 10:43:17 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 CFC1D3A0CE7 for ; Sat, 1 Aug 2020 10:43:14 -0700 (PDT) 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 vDMW6qDGsi13 for ; Sat, 1 Aug 2020 10:43:12 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 C44813A0CE6 for ; Sat, 1 Aug 2020 10:43:12 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id b2so5024819qvp.9 for ; Sat, 01 Aug 2020 10:43:12 -0700 (PDT) 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=FwcRs6a6phTmwoFLxoHkc5lDZRqZSkrb6VXHnCkDBCQ=; b=JadhABROmZbtxdg3wmK811BFbeftKDvp3Yis15CEGI7W00xu1rSEC5qSS6AIAJLzXa hHJormMh8uvKIstSaY9ahKFOubmNl5fEwkGtFZmWH6pqPkYcfm2c/GHgJDnj93xeq47I c6CwAYiwHe/HdB4OcLdjT2ELrPnRstZyAT/jKs+UbKE6Hu5lnk83wPLB7BQ4dP/IDmU2 em8jQ0HpAcDunCEJEoEYvJ+CGvpnZcZ40o3Ej7zL4KEFlv9tYVimmwj+uQU0i75gNh5G XhWKt2XSV2zocmLfku+VH2I2dbrkI4R59GSPCz+jLEvnlDVqpfAihX98SX2qR+B+fUWf ORlQ== 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=FwcRs6a6phTmwoFLxoHkc5lDZRqZSkrb6VXHnCkDBCQ=; b=hbFqbvdVB2OziORPKif9Vvp3rsRA1amidO3qEhDJuwwW64nesthqL4Nl0s7vMW34Bm jRMF9Y+rKgS/pLfwLc3/CBFCPwYPnmxpAs1q+z1qYC5A8vvXsJH5CUSoioiIRf1uux4t Mk+JIb4ZE07nQarSiPKicohiO6hnkMYUTGjJrE+zi3xLUKRfsUt2C6XoUk3eBVdetA10 tZPNWVkfzriNPYXoJgaYZvw4GO0FFsBFzvmmiBG2AUn701nCcLLBDPY2HubL+SVak/Ee pE44WXFSrg94ajn9lpSJjMbioe7m3y1tCxsexg7QZubghZQ9LffWiPZRT/cZfmz2xanh RC8Q== X-Gm-Message-State: AOAM532jkkLeYAdE8/hF8b3E4MQ/NWdcyqZznxjArc0v5rP4re3s46+F ErdRuqv1M16MuFQ+6rF9Anckf5F0t8teT2BNMrg= X-Google-Smtp-Source: ABdhPJwgiXNjOE3rPoTI1/CaYu2W4rrUekXl9veu3j/qXith1Jsd2AuWtnSwL1Vq9pNJXIAZCa2lcXSdL1FUUQGuDjg= X-Received: by 2002:a0c:e591:: with SMTP id t17mr9508686qvm.74.1596303791865; Sat, 01 Aug 2020 10:43:11 -0700 (PDT) MIME-Version: 1.0 References: <0d768d14-0a11-46fa-8ff8-1b63c578df2a@www.fastmail.com> <20200721073934.GA29757@nic.fr> <20200723143446.GA648@nic.fr> <20200727142812.GC4377@nic.fr> In-Reply-To: <20200727142812.GC4377@nic.fr> From: Lanlan Pan Date: Sun, 2 Aug 2020 01:42:59 +0800 Message-ID: To: Stephane Bortzmeyer Cc: "Chris Box (BT)" , Neil Cook , Andrew Campling , "add@ietf.org" Content-Type: multipart/alternative; boundary="00000000000077c19905abd47030" Archived-At: Subject: Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators 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 Aug 2020 17:43:15 -0000 --00000000000077c19905abd47030 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agree, CPE is not a terminal equipment. For example=EF=BC=8Cdefault CPE is customed by ISP, forwards the dns querie= s to ISP DNS. CPE can act as a DoT/DoH client. If CPE offers DoT/DoH service at local network (not consider about the certificate verification problem), it is hard to say the "end to end" security for the terminal equipment. Stephane Bortzmeyer =E4=BA=8E2020=E5=B9=B47=E6=9C=8827= =E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=8810:30=E5=86=99=E9=81=93=EF=BC= =9A > On Thu, Jul 23, 2020 at 05:50:15PM +0100, > Chris Box (BT) wrote > a message of 87 lines which said: > > > These have been in force for some years. If Orange don't let you > > change, they are most likely in breach of the French law which > > adopts these regulations. > > IANAL (and I don't know if you are) but I guess the problem is in the > definition of "terminal equipment of their choice". Some people may > claim it is the PC (or smartphone), and that the CPE is actually part > of the network, not a terminal equipment. > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000077c19905abd47030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree, CPE is not a terminal equipment.

For example=EF=BC=8Cdefault CPE is custom= ed by ISP, forwards the dns queries to ISP DNS.
CPE ca= n act as a DoT/DoH client.
If CPE offers DoT/DoH service at = local network (not consider about the certificate verification problem), it= is hard to say the "end to end" security for the terminal equipm= ent.

Stephane Bortzmeyer <bortzmeyer@nic.fr> =E4=BA=8E2020=E5=B9=B47=E6=9C=8827=E6=97=A5=E5= =91=A8=E4=B8=80 =E4=B8=8B=E5=8D=8810:30=E5=86=99=E9=81=93=EF=BC=9A
On Thu, Jul 23, 2020 at = 05:50:15PM +0100,
=C2=A0Chris Box (BT) <chris.box.ietf@gmail.com> wrote
=C2=A0a message of 87 lines which said:

> These have been in force for some years. If Orange don't let you > change, they are most likely in breach of the French law which
> adopts these regulations.

IANAL (and I don't know if you are) but I guess the problem is in the definition of "terminal equipment of their choice". Some people m= ay
claim it is the PC (or smartphone), and that the CPE is actually part
of the network, not a terminal equipment.

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000077c19905abd47030-- From nobody Mon Aug 3 00:58: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 2B2973A0C4A for ; Mon, 3 Aug 2020 00:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 UT2WeBfoeATZ for ; Mon, 3 Aug 2020 00:58:21 -0700 (PDT) Received: from mail3.bemta25.messagelabs.com (mail3.bemta25.messagelabs.com [195.245.230.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 B8DDC3A0C49 for ; Mon, 3 Aug 2020 00:58:20 -0700 (PDT) Received: from [100.112.197.196] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-b.eu-west-1.aws.symcld.net id 0A/77-29177-A93C72F5; Mon, 03 Aug 2020 07:58:18 +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: H4sIAAAAAAAAA+NgFlrJLsWRWlGSWpSXmKPExsWi75nTqjvzsHq 8wYYeeYv/p9exWXzbkeLA5LFz1l12jyVLfjIFMEWxZuYl5VcksGZMu/uGqeDKVMaKK58sGhhf dDJ2MXJxCAlsY5TYtuYHC4RziFFi5vxuJrjMtFd72CCcC4wSW3c3QznzmSSeHLoMVfaIUeLOo tNA0zg52ASiJLoa3jOD2CICgRLz5z8GiwsLqEk8WdDJ3sXIARRXl+i5WQlhGklM/QZWzSKgIv FzbhcbiM0rkCDx79AGsLiQQIDEmj/X2UFsTqCJB29sB7MZBWQlJuxeBDadWUBc4taT+UwgtoS AiMTDi6fZIGxRiZeP/7GCnMkr8I5F4sKz2WB/Mgr0MEpcmtHHDFElL/Hh6WoWCFtW4tL8bkYI 21fiw7ytULaWxOxv/1kh7GyJlnsHoXrVJVo+zoOKy0ms6n0INUdG4sGN7eDQkhDYzSxx4+w6q JMms0hsmpMHkdjDKvFv5x72CYxGs5C8MQsoxyzQySjx+OMnllng8BCUODnzCQtEUZ7Ek/vvoW wdiQW7P7FB2NoSyxa+Zoaxzxx4zIQpriPx+1sXVL2ixO2rU1kh7MWMEleO58LUnJzQywpTM6X 7IfsCRt5VjBZJRZnpGSW5iZk5uoYGBrqGhka6hpYWuobGBnqJVbpJeqmluuWpxSW6hnqJ5cV6 xZW5yTkpenmpJZsYgSk1peBY0w7Gk68/6B1ilORgUhLlTdysHi/El5SfUpmRWJwRX1Sak1p8i FGGg0NJglflIFBOsCg1PbUiLTMHmN5h0hIcPEoivLGHgNK8xQWJucWZ6RCpU4yWHBNezl3EzP Fx1RIg+R1ECrHk5eelSonz9oHMEwBpyCjNgxsHy0GXGGWlhHkZGRgYhHgKUotyM0tQ5V8xinM wKgnzmoOs5cnMK4Hb+groICagg2w2qIIcVJKIkJJqYJL8sVL7wsF9HbXZ00+9n8Gyy9H8/UZL d4tbyhesWs6W7ja5XvT85uPuxjlXfT6y3076Oo3h04Z3PCWLHV71y3htcfVSjDe/EVLMpPf1z cXyz3V7PHeF+Eg9sP5sdMSw7qawoNLLX23vnI4c3aRzTKY72DzgcBGT5O5qGd7LF+bPkXxVaS rLMHnqG8uw/nt3ktx4/pqoibpaHdnvlXjaIXbHmjt/jB80Bv1zePAlwzvo1FNnQdU1KvsN7qt xfn8VNUneiEVK7PQzYT7vhV0cG7imtZ9o3CB47lXd850nhQJ3fWE9VPu3Mf5x8KyJrh9MXni7 OS35t8bclutUorXV4s9VNTyxB9wUnlsUilk+yVBiKc5INNRiLipOBAC2365SvAQAAA== X-Env-Sender: Gianpaolo-Angelo.Scalone@vodafone.com X-Msg-Ref: server-6.tower-285.messagelabs.com!1596441488!6789!16 X-Originating-IP: [47.73.108.133] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.50.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27946 invoked from network); 3 Aug 2020 07:58:17 -0000 Received: from unknown (HELO voxe06hw.internal.vodafone.com) (47.73.108.133) by server-6.tower-285.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 3 Aug 2020 07:58:17 -0000 Received: from VOEXH06W.internal.vodafone.com (47.73.211.204) by edge1.vodafone.com (195.232.244.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Aug 2020 09:58:15 +0200 Received: from voxe04hw.internal.vodafone.com (195.232.244.49) by VOEXH06W.internal.vodafone.com (47.73.211.204) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Aug 2020 09:58:15 +0200 Received: from VOEXH09W.internal.vodafone.com (47.73.211.213) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Aug 2020 09:58:14 +0200 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (172.17.213.43) by VOEXH09W.internal.vodafone.com (47.73.211.213) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Aug 2020 09:58:13 +0200 Received: from VI1PR0502MB3712.eurprd05.prod.outlook.com (2603:10a6:803:2::31) by VI1PR05MB5536.eurprd05.prod.outlook.com (2603:10a6:803:95::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Mon, 3 Aug 2020 07:58:12 +0000 Received: from VI1PR0502MB3712.eurprd05.prod.outlook.com ([fe80::a1e5:2abe:8b8c:51f9]) by VI1PR0502MB3712.eurprd05.prod.outlook.com ([fe80::a1e5:2abe:8b8c:51f9%7]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 07:58:12 +0000 From: "Scalone, Gianpaolo Angelo, Vodafone Italy" To: "Chris Box (BT)" , ADD Mailing list Thread-Topic: [Add] Requirements drafts Thread-Index: AQHWZ2ENwp9/gg+TV0KphRDj0WIgBqkmB2Ow Date: Mon, 3 Aug 2020 07:58:12 +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_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Enabled=True; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SiteId=68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Owner=Gianpaolo-Angelo.Scalone@vodafone.com; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SetDate=2020-08-03T07:58:06.9428858Z; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Name=C2 General; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Application=Microsoft Azure Information Protection; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Extended_MSFT_Method=Automatic; Sensitivity=C2 General x-originating-ip: [2.35.70.212] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a16db4bc-7dd9-4316-4daa-08d83782f891 x-ms-traffictypediagnostic: VI1PR05MB5536: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Fpo5GFiOIwVB8hg+GeB//nSSu/WGm+dqfAqZ22xql2d090qUMg0smI7aTZKAzNHK33u57fpQDu2A3d9VDTmWZT8wtEQBcxPLR74Os6H7/N/QeP4czgHj9gcFovk6ohr3xNLev3d0S3kZOqoZ/ovNCqU63F8HZD9XYNetojAsaOTzjjH9lBU1DM0YNHVehDpqUVIx1x14havPHbKdZigka1grHAFP26YNUVdO88TCN3+ofB8azsizrMdvVl+uVSSkdIWOQtth8ZX+5sp5lkT7Um+VDhr4QPtC3ZropLOfrTTUfTU+NI03eY6eagafRZu/+ivYRKIHVDld2qvNVbjNy6ihPS0WRw3tP7IurVzUACjOWMoLCkQM8DZ0VOJaWijHdnSJvRUFFCtCnEpipwu8XA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0502MB3712.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(39860400002)(376002)(366004)(346002)(83380400001)(8936002)(316002)(71200400001)(86362001)(9326002)(966005)(8676002)(110136005)(478600001)(2906002)(166002)(9686003)(52536014)(55016002)(99936003)(5660300002)(7696005)(6506007)(53546011)(66616009)(66476007)(66556008)(66946007)(76116006)(26005)(66446008)(186003)(33656002)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: LSYgHrx95Cmyc1BGIotWbJXqeVNfDgNZPr6A5HISm8obBo+MCulyM2XaIgqJocXfyVji0yND8HpnRSuG7DLqatXQADBYjdO+G5P9w2lipfsf3kXHn7UtGm/YVSDSp6yWfQlt/yQQAknYB5yjCY0oXs67y1AeboCM2L7sTc4uX3ni4K7FNs/7eaXF8ZNgltj6qHljIo6EwSp7xH9XHCoCXknJU1KxYLo1LdEirg53P6o+wlE4mbs9VML+2cK9Jdzvvt84feejRD2wzsKDwTICnRRW/42/QL750pQtbwKviwKOzVRQRx61848AC0NHBdmpcAcQUTKLay+vRVuhzXe0itY0HK/WdiYfCA0CSiQB76/KUm7PV1fFs2nD32xRGUDw/Vey1lvUcDSZsws4yaMhgf69wI3xPtO2wk98yHjfy1DG2RReHvU0Hd56cmVQcf7yQTDWjEO64qc06EbJ4EG3GSozUbFh7/QY02YA7p3uWkUcuNe8wKUMdPX9kppw9o4SED6Sm5LJ8prlA1QxX6FH/IrYYpn2NnTUAdE0aLMs81l47NbL8m/IARByPGBTMjGu7E7mdmXKR+/0NqMES9o8mCpKwbI8fO/UzpXnge/NjOwviRhN6kshT5nM84nVSkvY0r/dciuiRSXSnVL80ZMQEg== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FT6F2gfPWAywUS3WyFe4UI8wMgXgBoDHMmf97DvHxjuTWraWvHdxuW4x2k5ZulwLuRi1Me0hCKYXcAKi8xtaJFuXOzi/HM7+qogYV7ZLyi+DXlgPMqWqZLCjhEZOiuQguvf+k2Vxv0W2kQhcA2lrP1Pj3TTzmbnDMtvlIPW0dHkWYvARxNszoL1zeKS/r7hRMGKKKy/4x/CJoDhxd00v4eCbSmHmoKYeSe71r8u2yWXGUDuBfxUL2AMm93b5sJ23GOlaYZwhPzZvu/DqsNHk6QKROm6WxqhenXvBYbj7Bwmz95peZnyDHUfHRc+OQDQ0lyDGwXZVp+VX7gXZ2/GZUQ== 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=HFSiRipwYdJ/cmwZajCeZYDZTKaVYS1SV76rXYXLXZQ=; b=AVWrKdGRyy5U4JxVDHq+RZVwAU4Qoc6/SHxGpl5JYk04Pb9mS13zz8UgxKx6UqEw5F4tF/KqFdDbPphb6i4H/KqcQT0ut0zkCATUYsKF2ra1j8uEziaxhBJ/SyWqBiXwfKpPGcLtZjtsMMrTrPlumpV0yuBsTPKcqUmysipiuNP81qAdrrkT6tdEHxLrex7SU6MKWU4zfZYV0iWWc70rMD22Sh5C5p8VMl7dIS0INC8zVNCljVtdKm3g4HHhgnvx7qXzWycL0t7qU1YJbKeC66BYswSP/CcU52S7snFcr/ooHsFPNVaDWrSHaDTNLHW81y+k9Sy0a7yK7+160LKOWA== 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-authas: Internal x-ms-exchange-crosstenant-authsource: VI1PR0502MB3712.eurprd05.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: a16db4bc-7dd9-4316-4daa-08d83782f891 x-ms-exchange-crosstenant-originalarrivaltime: 03 Aug 2020 07:58:12.7144 (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: ZUGNYQ1xUFjvNCXqmonazxDecwj95Bwe05PpW/zAzmeS4INZmifBi2oST+l34kgR4reVJU06gM4wSVw1vEtGj5dOHuk9kBTgwAjzDAPabWw6cRJ1CTWpffQeikmzkKCr x-ms-exchange-transport-crosstenantheadersstamped: VI1PR05MB5536 Content-Type: multipart/related; boundary="_004_VI1PR0502MB371226DB7C3B236EA87CA555A34D0VI1PR0502MB3712_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: vodafone.com X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 07:58:23 -0000 --_004_VI1PR0502MB371226DB7C3B236EA87CA555A34D0VI1PR0502MB3712_ Content-Type: multipart/alternative; boundary="_000_VI1PR0502MB371226DB7C3B236EA87CA555A34D0VI1PR0502MB3712_" --_000_VI1PR0502MB371226DB7C3B236EA87CA555A34D0VI1PR0502MB3712_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think that Same Provider Auto Upgrade could be the best path: this guaran= tees that the encrypted DNS is under the same policy that the customer alr= eady knows . I also think that if we follow the path of potentially upgrading to a diffe= rent DNS the discovery process should take into consideration (and pass dur= ing the process) also other parameters, such as GDPR compliancy, So that in this case the customer could upgrade to GDPR compliant encrypted= DNS, Edge/Core/Central DNS 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 Chris Box (BT) Sent: 31 July 2020 19:35 To: ADD Mailing list Subject: [Add] Requirements drafts CYBER SECURITY WARNING: This email is from an external source - be careful = of attachments and links. Please follow the Cyber Code and report suspiciou= s emails. All, My take on the conclusion of this week's meeting (notes at https://codimd.i= etf.org/notes-ietf-108-add?view) was that the next step should be to step b= ack and write some new drafts that clearly define the problem statement and= requirements to be met. Assuming there is more than one of these drafts, how would you define the s= ubject area for each one? Martin and Eric (Orth) both suggested Same Provider Auto Upgrade, aka "disc= overing potential upgrade information for the current resolver". Eric also suggested "networks communicating what their preferred resolver i= s". If the current resolver is the one automatically learned from the netwo= rk, this is identical to the above. If it is not, because there's manual co= nfiguration, presumably we always/nearly-always honor the manual config? Bu= t are there cases where it's still helpful to know the network's preference= ? Within SPAU, I think a useful distinction is Ekr's "steering which generic = resolver will be used". This allows for the current provider to have multip= le possible resolvers (e.g. edge vs core), and communicating the nature of = the differences between those options. Finally we have Domain Designated Resolvers, where domains tell you what th= eir preferred resolver is. Any thoughts on the scope of each draft, and how many should be created in = time for the September interim? Chris P.S. In terms of content, one idea I've had is that each should also mentio= n performance considerations, particularly as I'm now thinking that the lar= ger the set of resolvers a client talks to, the fewer requests it sends to = each, and the more likely it is that a query will require a new TLS setup. = Jim also mentioned another, that they'll need to report on GDPR-type issues --_000_VI1PR0502MB371226DB7C3B236EA87CA555A34D0VI1PR0502MB3712_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I think that Same Provider Auto Upgra= de could be the best path: this guarantees that the encrypted  DNS is = under the same policy that the customer already knows .

I also think that if we follow the pa= th of potentially upgrading to a different DNS the discovery process should= take into consideration (and pass during the process) also other parameters, such as GDPR compliancy,=

So that in this case the customer cou= ld upgrade to GDPR compliant encrypted DNS, Edge/Core/Central DNS

 

Gianpaolo

 

3D"Vo=<= o:p>

Gianpaolo= Scalone
Senior  Engineer

Service Appli= cations Centre of Excellence

Group Technol= ogy, Networks

Mobile: += 39 348 0001806

Email: gianpaolo-angelo.s= calone@vodafone.com<= /o:p>

Address: Via Bisceglie 73 20147 Milano =

 

 

 

= C2 General

From: Add <add-bounces@ietf.org&g= t; On Behalf Of Chris Box (BT)
Sent: 31 July 2020 19:35
To: ADD Mailing list <add@ietf.org>
Subject: [Add] Requirements drafts

 

<= span style=3D"font-size:11.0pt;font-family:"Vodafone Rg",sans-ser= if;color:black">CYBER SECURITY WARNING: This email is from an external source - be careful of attachments and link= s. Please follow the Cyber Code and report suspicious emails.

All,

 

My take on the conclusion of this week's meeting (no= tes at https://codimd.ietf.org/notes-ietf-108-add?view) was that the next step= should be to step back and write some new drafts that clearly define the p= roblem statement and requirements to be met.

 

Assuming there is more than one of these drafts, how= would you define the subject area for each one?

 

Martin and Eric (Orth) both suggested Same Provider = Auto Upgrade, aka "discovering potential upgrade information for the c= urrent resolver".

 

Eric also suggested "networks communicating wha= t their preferred resolver is". If the current resolver is the one aut= omatically learned from the network, this is identical to the above. If it = is not, because there's manual configuration, presumably we always/nearly-always honor the manual config? But are there = cases where it's still helpful to know the network's preference?=

 

Within SPAU, I think a useful distinction is Ekr's &= quot;steering which generic resolver will be used". This allows for th= e current provider to have multiple possible resolvers (e.g. edge vs core),= and communicating the nature of the differences between those options.

 

Finally we have Domain Designated Resolvers, where d= omains tell you what their preferred resolver is.

 

Any thoughts on the scope of each draft, and how man= y should be created in time for the September interim?

 

Chris

 

P.S. In terms of content, one idea I've had is that = each should also mention performance considerations, particularly as I'm no= w thinking that the larger the set of resolvers a client talks to, the fewe= r requests it sends to each, and the more likely it is that a query will require a new TLS setup. Jim also ment= ioned another, that they'll need to report on GDPR-type issues

 

--_000_VI1PR0502MB371226DB7C3B236EA87CA555A34D0VI1PR0502MB3712_-- --_004_VI1PR0502MB371226DB7C3B236EA87CA555A34D0VI1PR0502MB3712_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3053; creation-date="Mon, 03 Aug 2020 07:58:12 GMT"; modification-date="Mon, 03 Aug 2020 07:58:12 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_VI1PR0502MB371226DB7C3B236EA87CA555A34D0VI1PR0502MB3712_-- From nobody Mon Aug 3 01:10: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 7A79F3A0CE9 for ; Mon, 3 Aug 2020 01:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 Pyo8SYlc01dC for ; Mon, 3 Aug 2020 01:10:31 -0700 (PDT) Received: from mx3.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 1C08F3A0C81 for ; Mon, 3 Aug 2020 01:10:30 -0700 (PDT) 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)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 4CAB46A232; Mon, 3 Aug 2020 10:10:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1596442228; bh=SAACGKnwmAt2JEsrQnkyOtvI6es/0h2gTRdS6lhK3TU=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ojn7+lkxD14QI1BjlX/v7LURHa1UfBB5lLwvtUDlRjae4DqX5D6Gu1vFzoJKckcFP 40cpJIj77Y49s3FxVTGq9Fi2jDTGv1r01Jy3xWtIU14cM0iRQWjy8BHEwfes2LIXml pkNQEPT8u3oWvLJbRmIXZj8mBLZth5m2cdm9y/AbmYcyeINzFvohx2a9LyTKVGDvbu IxoUKj9ulsaYgx9C2aWY1qBlpp3dF7WYopf317aDmYy8VzdCvcjDKY6D1K3fFSCtJI dSt39qiuYT3q8ybxQJckHTU/V8ZiFKwqDIJjPfeErNmbI5Q58YmN9/m3M1P3A9GwJI fTe8iVJrPbYnw== 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 32C793C0124; Mon, 3 Aug 2020 10:10:28 +0200 (CEST) Date: Mon, 3 Aug 2020 10:10:27 +0200 (CEST) From: Vittorio Bertola To: Lanlan Pan , Stephane Bortzmeyer Cc: Andrew Campling , "add@ietf.org" Message-ID: <959429540.478.1596442228109@appsuite-gw2.open-xchange.com> In-Reply-To: References: <0d768d14-0a11-46fa-8ff8-1b63c578df2a@www.fastmail.com> <20200721073934.GA29757@nic.fr> <20200723143446.GA648@nic.fr> <20200727142812.GC4377@nic.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_476_279145761.1596442228088" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev19 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] Practical Observations from Encrypted DNS Deployments by Network Operators 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 Aug 2020 08:10:37 -0000 ------=_Part_476_279145761.1596442228088 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Il 01/08/2020 19:42 Lanlan Pan ha scritto: > =20 > =20 > Agree, CPE is not a terminal equipment. >=20 Just for reference, "terminal equipment" in Europe is defined by directive = 2008/63/EC: 'terminal equipment=E2=80=99 means: (a) equipment directly or indirectly connected to the interface of a public= telecommunications network to send, process or receive information; in eit= her case (direct or indirect), the connection may be made by wire, optical = fibre or electromagnetically; a connection is indirect if equipment is plac= ed between the terminal and the interface of the network; (b) satellite earth station equipment; Of course, this then changes the question into: where is the "interface of = a public telecommunications network" located? This is a definition that fal= ls under the competence of each individual member State, so one could read = this useful 94-page BEREC report that has information on each country: https://berec.europa.eu/eng/document_register/subject_matter/berec/reports/= 8252-berec-report-on-the-location-of-the-network-termination-point Bottom line: understanding regulation in Europe is not always immediate :-)= But according to the report, almost all the countries that took a decision= located the interface between the modem and the Internet, making the CPE "= terminal equipment"; in one country this depends on who owns it. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com= =20 Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_476_279145761.1596442228088 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =20 =20
 
=20
=20
Il 01/08/2020 19:42 Lanlan Pan <abbypan@gmail.com> ha scritto:
=20
 
=20
 
=20
=20
Agree, CPE is not a terminal equipment.
=20
=20
=20
Just for reference, "terminal equipment" in Europe is defined by directi= ve 2008/63/EC:
=20
 
=20
 
=20
'ter= minal equipment=E2=80=99 means: =20
=20
=20
=20
 
=20
= (a) equipment directly or indirectly connected to the interface of a public= telecommunications network to send, process or receive information; in eit= her case (direct or indirect), the connection may be made by wire, optical = fibre or electromagnetically; a connection is indirect if equipment is plac= ed between the terminal and the interface of the network;
=20
 
=20
= (b) satellite earth station equipment;
=20
 
=20
=20
=20
=20
=20
 
=20
Of course, this then changes the question into: where is the "interface = of a public telecommunications network" located? This is a definition that = falls under the competence of each individual member State, so one could re= ad this useful 94-page BEREC report that has information on each country:
=20
 
=20 =20
 
=20
Bottom line: understanding regulation in Europe is not always immediate = :-) But according to the report, almost all the countries that took a decis= ion located the interface between the modem and the Internet, making the CP= E "terminal equipment"; in one country this depends on who owns it.
=20
=20

--

=20 
Vittorio Bertola | Head of Policy & Innovation, Open=
-Xchange
vittorio.b=
ertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Ital=
y
=20
------=_Part_476_279145761.1596442228088-- From nobody Mon Aug 3 01:43: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 D29883A0C73 for ; Mon, 3 Aug 2020 01:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 2oNJWABTbPxA for ; Mon, 3 Aug 2020 01:43:49 -0700 (PDT) Received: from mx3.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 EC5003A0AE7 for ; Mon, 3 Aug 2020 01:43:48 -0700 (PDT) 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)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 7F59F6A230; Mon, 3 Aug 2020 10:43:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1596444225; bh=J4x+97/aeA66TppDHhgoRowTjiCqzPPCNOFOiifhsfc=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=pMi8Tk69HQY9Slq0I1kDWUAvGMW6SSC8srSh69ryzGvQCRiVxsgc1rTjYURZwW9qx rtcGNocPuyWdhqssoe/dPPmOw2vm4a7eLXkYxuf42HJqcjqjGODRpqFnCBar5pm/y8 kFKu7OM0ZNApBM0MT4ZDFJGMk7zuG1b07MkmZpcZr10bKyeTNccrLeh4lJmu8sCDvn Gm4o67BJg+gSoUc55kGFgBAyoO0QVGJOsO3H7oe65CBbeSzkg7QcquO+ik3Fw4GNtT LcgoMD+bmnVF2A1aflUC8LWFR5eSlzrKf7HyiIu1Ekm8bVMG/27fUlctQMse+MEpN8 m2ya2Lzs60hhA== 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 7118B3C0230; Mon, 3 Aug 2020 10:43:45 +0200 (CEST) Date: Mon, 3 Aug 2020 10:43:45 +0200 (CEST) From: Vittorio Bertola To: Tommy Pauly , "Chris Box (BT)" Cc: ADD Mailing list Message-ID: <1872348479.704.1596444225366@appsuite-gw2.open-xchange.com> In-Reply-To: <08FF1483-D954-46A1-8231-D4C0C7078966@apple.com> References: <08FF1483-D954-46A1-8231-D4C0C7078966@apple.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_702_1472450556.1596444225306" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev19 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] Requirements drafts 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 Aug 2020 08:43:51 -0000 ------=_Part_702_1472450556.1596444225306 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Il 01/08/2020 02:05 Tommy Pauly = ha scritto: > =20 > =20 > Hi Chris, > =20 > Thanks for starting this thread. I think focusing the interim meeting= on clarifying these use cases is a good idea. > =20 > As I mentioned in my presentation, I think there are two clear catego= ries we see repeated across the proposals for discovery. In the most abstra= ct terms, these are: > =20 > 1. Given a known resolver, discover one or more associated/equivalent= encrypted resolvers > 2. Discover an encrypted resolver that is applicable to a limited dom= ain > =20 > Each of these has several specific use cases for *both* local network= resolvers and Internet-accessible resolvers. > =20 > Under (1), we have: > 1a: Discover encrypted resolvers that are equivalent to the resolver = given out by DHCP/RA > 1b: Discover encrypted resolvers that are equivalent to a manually-co= nfigured resolver, which may be a public Internet resolver > 1c: Discover encrypted resolvers that are equivalent to a VPN-configu= red DNS servers >=20 If we develop a mechanism that starts by the IP address of a resolver (eith= er public or private) and gets to the equivalent DoH URI / DoT IP:port addr= ess, then it will work in all those cases. There are already several propos= als for that, so I think we could progress relatively easily by setting dow= n the requirements and then evaluating the various proposals. > ... > =20 > Under (2), we have: > 2a: Discover a mapping between a locally-hosted domain and an encrypt= ed resolver > - Walled-garden content > - Locally-cached content > - Private enterprise names > 2b: Discover a mapping between a public domain and an encrypted resol= ver > - Name hosted by CDN foo can use CDN foo=E2=80=99s resolver > =E2=80=A6 >=20 This (especially 2b) looks less immediate due to the architectural change t= hat it implies and the policy issues it creates. But it makes sense to work= on a requirements doc, it will allow clarification and hopefully agreement= at least on the issues. > =20 > I don=E2=80=99t think we need to cover the manual configuration case,= other than to indicate that user preference should always take precedence.= I don=E2=80=99t think there is a viable use for having a network claim a p= reference that should override manual user configuration. >=20 Dr. Vixie would disagree :-) and there's nothing bad in letting networks co= mmunicate policy requirements to clients, since clients will always be able= to ignore them - and if they won't, because the network finds technical wa= ys to force them, then it'd be better for clients to have a way to know wha= t's happening. In any case, this looks like a separate working item that could fall under = the third bullet of our charter, but could also be accomplished as part of = a broader network handshake and provisioning mechanism. So I'd see whether = anyone wants to work on that topic here and propose a requirements draft, a= nd in that case we'll discuss whether to adopt it. > =20 > I think these two use cases could share one document, or be separate.= They probably shouldn=E2=80=99t be broken down any further than that. > =20 > Beyond use cases, I think any requirements document needs to primaril= y address the privacy, security, and authentication requirements of the arc= hitecture. I suggest using some of the conversation from Martin Thomson=E2= =80=99s email thread titled =E2=80=9CMy principles for discovery=E2=80=9D. = We should have baseline standards for how trusted a given signal must be be= fore a client should use it. >=20 This smells like an endless policy discussion: "how secure is secure enough= ?". I would already be satisfied if we documented the security issues conne= cted with each approach, leaving it to implementers (and possibly to policy= /regulatory discussions) to determine the best tradeoff between the technic= al risks, the non-technical risks (e.g. consolidation) and the market and r= egulatory demand for a certain model. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com= =20 Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_702_1472450556.1596444225306 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =20 =20
 
=20
=20
Il 01/08/2020 02:05 Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org= > ha scritto:
=20
 
=20
 
Hi Chris,=20
 
=20
Thanks for starting this thread. I think focusing the interim meeting o= n clarifying these use cases is a good idea.
=20
 
=20
As I mentioned in my presentation, I think there are two clear categori= es we see repeated across the proposals for discovery. In the most abstract= terms, these are:
=20
 
=20
1. Given a known resolver, discover one or more associated/equivalent e= ncrypted resolvers
=20
2. Discover an encrypted resolver that is applicable to a limited domai= n
=20
 
=20
Each of these has several specific use cases for *both* local network r= esolvers and Internet-accessible resolvers.
=20
 
=20
Under (1), we have:
=20
1a: Discover encrypted resolvers that are equivalent to the resolver gi= ven out by DHCP/RA
=20
1b: Discover encrypted resolvers that are equivalent to a manually-conf= igured resolver, which may be a public Internet resolver
=20
1c: Discover encrypted resolvers that are equivalent to a VPN-configure= d DNS servers
=20
=20
If we develop a mechanism that starts by the IP address of a resolver (e= ither public or private) and gets to the equivalent DoH URI / DoT IP:port a= ddress, then it will work in all those cases. There are already several pro= posals for that, so I think we could progress relatively easily by setting = down the requirements and then evaluating the various proposals.
=20
=20
...
=20
 
=20
Under (2), we have:
=20
2a: Discover a mapping between a locally-hosted domain and an encrypted= resolver
=20
- Walled-garden content
=20
- Locally-cached content
=20
- Private enterprise names
=20
2b: Discover a mapping between a public domain and an encrypted resolve= r
=20
- Name hosted by CDN foo can use CDN foo=E2=80=99s resolver
=20
=E2=80=A6
=20
=20
This (especially 2b) looks less immediate due to the architectural chang= e that it implies and the policy issues it creates. But it makes sense to w= ork on a requirements doc, it will allow clarification and hopefully agreem= ent at least on the issues.
=20
=20
 
=20
I don=E2=80=99t think we need to cover the manual configuration case, o= ther than to indicate that user preference should always take precedence. I= don=E2=80=99t think there is a viable use for having a network claim a pre= ference that should override manual user configuration.
=20
=20
Dr. Vixie would disagree :-) and there's nothing bad in letting networks= communicate policy requirements to clients, since clients will always be a= ble to ignore them - and if they won't, because the network finds technical= ways to force them, then it'd be better for clients to have a way to know = what's happening.
=20
 
=20
In any case, this looks like a separate working item that could fall und= er the third bullet of our charter, but could also be accomplished as part = of a broader network handshake and provisioning mechanism. So I'd see wheth= er anyone wants to work on that topic here and propose a requirements draft= , and in that case we'll discuss whether to adopt it.
=20
=20
 
=20
I think these two use cases could share one document, or be separate. T= hey probably shouldn=E2=80=99t be broken down any further than that.
=20
 
=20
Beyond use cases, I think any requirements document needs to primarily = address the privacy, security, and authentication requirements of the archi= tecture. I suggest using some of the conversation from Martin Thomson=E2=80= =99s email thread titled =E2=80=9CMy principles for discovery=E2=80=9D. We = should have baseline standards for how trusted a given signal must be befor= e a client should use it.
=20
=20
This smells like an endless policy discussion: "how secure is secure eno= ugh?". I would already be satisfied if we documented the security issues co= nnected with each approach, leaving it to implementers (and possibly to pol= icy/regulatory discussions) to determine the best tradeoff between the tech= nical risks, the non-technical risks (e.g. consolidation) and the market an= d regulatory demand for a certain model.
=20
=20

--

=20 
Vittorio Bertola | Head of Policy & Innovation, Open=
-Xchange
vittorio.b=
ertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Ital=
y
=20
------=_Part_702_1472450556.1596444225306-- From nobody Mon Aug 3 02:50: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 DBEC53A0D3D for ; Mon, 3 Aug 2020 02:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.075 X-Spam-Level: * X-Spam-Status: No, score=1.075 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=1.274, SPF_HELO_NONE=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=noware.co.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 zOMwnaAnK6qo for ; Mon, 3 Aug 2020 02:50:54 -0700 (PDT) Received: from mail.noware.co.uk (unknown [IPv6:2604:a880:0:1010::add:2001]) by ietfa.amsl.com (Postfix) with ESMTP id CC42F3A0D38 for ; Mon, 3 Aug 2020 02:50:54 -0700 (PDT) Received: from [192.168.1.170] (unknown [109.154.94.123]) by mail.noware.co.uk (Postfix) with ESMTPSA id 8F7E01DC579; Mon, 3 Aug 2020 09:49:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.noware.co.uk 8F7E01DC579 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=noware.co.uk; s=default; t=1596448162; bh=Xx90OW4ZI4XSj8n8OQiFbjT7FyFFCxi8dqHhTDf8m1w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=QLmZCf8kVIMh9GDjjUISOF7dnETcu5FL+SOWdZ6JpjGAr1We9P1r6BW+t0mAGy/Qd V8ggxvPfW1MKfQzDsaR/7unpLM3PsEnkujrLFKwLMTnbrVrIU3/+NmhiI0fyWGXJda 9JqbH8FWmYnwWZmRJ8D4jQqtq95TDtRJjgk+Ad5c= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Neil Cook In-Reply-To: <08FF1483-D954-46A1-8231-D4C0C7078966@apple.com> Date: Mon, 3 Aug 2020 10:50:52 +0100 Cc: "Chris Box (BT)" , ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <697F8CF2-963F-457E-83B9-869AD17A3E94@noware.co.uk> References: <08FF1483-D954-46A1-8231-D4C0C7078966@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3608.80.23.2.2) X-VADE-SPAMSTATE: clean X-VADE-SPAMSCORE: -100 X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrjeeggddvtdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfpgffknfevqffqmfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheppfgvihhlucevohhokhcuoehnvghilhdrtghoohhksehnohifrghrvgdrtghordhukheqnecuggftrfgrthhtvghrnhepfeekjeehtdehfefgteefudfgkeelteekvefhgfehleettdeuieeuhfettdejhfejnecukfhppedutdelrdduheegrdelgedruddvfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedutdelrdduheegrdelgedruddvfedphhgvlhhopegludelvddrudeikedruddrudejtdgnpdhmrghilhhfrhhomheppfgvihhlucevohhokhcuoehnvghilhdrtghoohhksehnohifrghrvgdrtghordhukheqpdhrtghpthhtohepthhprghulhihsegrphhplhgvrdgtohhmpdhrtghpthhtoheptghhrhhishdrsghogidrihgvthhfsefiofetkffnrdevqffopdhrtghpthhtoheprgguugesihgvthhfrdhorhhg Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 09:50:56 -0000 > On 1 Aug 2020, at 01:05, Tommy Pauly wrote: >=20 > Hi Chris, >=20 > Thanks for starting this thread. I think focusing the interim meeting = on clarifying these use cases is a good idea. >=20 > Under (1), we have: > 1a: Discover encrypted resolvers that are equivalent to the resolver = given out by DHCP/RA > 1b: Discover encrypted resolvers that are equivalent to a = manually-configured resolver, which may be a public Internet resolver > 1c: Discover encrypted resolvers that are equivalent to a = VPN-configured DNS servers > ... Given all the discussion and drafts on the existing situation with = forwarders, for 1a I think we also need to explicitly spell out = use-cases involving forwarders, in terms of: i) Discovering encrypted resolvers =E2=80=9Cbehind=E2=80=9D forwarders, = and using them directly (thus bypassing the forwarder). i) Discovering and using encrypted DNS running on forwarders (note that = this could involve interactions with the encrypted resolver =E2=80=9Cbehin= d=E2=80=9D the forwarder) I think we should also discuss the threat models for each of these = use-cases. Neil From nobody Mon Aug 3 09:45: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 38CF93A0F44 for ; Mon, 3 Aug 2020 09:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 e73Lo7_tePqx for ; Mon, 3 Aug 2020 09:45:09 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450: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 19C5A3A0EBC for ; Mon, 3 Aug 2020 09:45:08 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id x5so206423wmi.2 for ; Mon, 03 Aug 2020 09:45:08 -0700 (PDT) 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=nab3nCIysgBqA4tVdg5HV0fFez/amyAHesWbrrfvUuI=; b=jJo4vUsTSXpBjNih6yqJSgwf4DUSiPco7CaxZkDX/zIl80oziAsbmYsoz2ebVdqp6y KcTwDkTXTrE9c+vCxlF8KeISMNzAK8i0Zrc2knBGf0SMGnhJ9b3Gi5+KeupvKPEZUg4c sI9Aw5ip4fh6SKdwaovAoh2+A58+z/g7cfEJG29kjceU4WQhTaPtvyeqiLQEeuGcVsgi 1NNZEYezNCyafYRe8fSXk70P4qlmrIPQyhnNmBjgzp/ESJW/6oc37r3ikrCh9gCt6cGP wHxofnWZRl7m2TFyU2431UQUeb5mFRzMF9VVN5OMgjcldfpz/6htfOzg6XRfqJA5A7PD 8WXg== 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=nab3nCIysgBqA4tVdg5HV0fFez/amyAHesWbrrfvUuI=; b=n8dpdwL3LeOqUHUyAvmTAXOxTMtZwzHe3DzRJbR847y3i/KB1Adlk8rzFQEC6A33iW X3MCJr2fcP7Dshyn46Jggj3ziraavHLIczVvHY+Ubjkfq4e5YOvx4EIx3BZhATF1M+aQ 5Pr9v4gc/X+M4vVuzZ3+2vTSNjLuwyH9mmgSSndCVgp6nEYWeqzUVXS/fML36lpIx/hp TIp32yrnn75umTE+o5BAkaK+ATT6HOufS12e6OCkh3Js8PYa9o7GuSI7CcIgYNpdIvZV T3rkZcYGVyXgZRpXtmpDNZSmAnnewIThZPrmPXBYZYgRxFwSwV1MxElfVy7hE0OE9o7Q DdCg== X-Gm-Message-State: AOAM531iSHVyTeY3b4V+F7C/9yY+/qxDbDN1SObkgSITHsqQDlB1oEej zwYshY3b6n3LUBkaAtuaJ9We4K/vd8aATH8mzvxNmg== X-Google-Smtp-Source: ABdhPJxPGw8A854WKAqqp71dx9rsOG+nm4P40zrvI3CICb4EOn5MXIv82wGT1vQfraa5HPl+LYeWajpNu2UE9qsFO4I= X-Received: by 2002:a7b:c0cb:: with SMTP id s11mr121696wmh.89.1596473106889; Mon, 03 Aug 2020 09:45:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Orth Date: Mon, 3 Aug 2020 12:44:55 -0400 Message-ID: To: "Chris Box (BT)" Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000006e6eb705abfbdcdf" Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 16:45:11 -0000 --0000000000006e6eb705abfbdcdf Content-Type: text/plain; charset="UTF-8" On Fri, Jul 31, 2020 at 1:35 PM Chris Box (BT) wrote: > All, > > My take on the conclusion of this week's meeting (notes at > https://codimd.ietf.org/notes-ietf-108-add?view) was that the next step > should be to step back and write some new drafts that clearly define the > problem statement and requirements to be met. > > Assuming there is more than one of these drafts, how would you define the > subject area for each one? > > Martin and Eric (Orth) both suggested Same Provider Auto Upgrade, aka > "discovering potential upgrade information for the current resolver". > > Eric also suggested "networks communicating what their preferred resolver > is". If the current resolver is the one automatically learned from the > network, this is identical to the above. If it is not, because there's > manual configuration, presumably we always/nearly-always honor the manual > config? But are there cases where it's still helpful to know the network's > preference? > I would anticipate most clients wanting to respect manual config as much as possible, but that still doesn't rule out potential use for communicating network preferences. Some possible cases I can think of: 1. Network configuration is in use, but the network wants to request different providers for classic vs encrypted DNS. Eg, maybe the network wants to advertise some legacy resolver for Do53 that for whatever reason doesn't support any upgrade discovery, but the network still wants to say "if you support DoH, use this other provider instead". 2. In client configuration UIs, it may be helpful to inform the user of current configuration or other network preferences as the user makes decisions. 3. Respecting manual config gets more nuanced as more and more parties do DNS and potentially have their own configuration at different levels. E.g., I believe the current Firefox behavior is to respect manual configuration in Firefox, but generally ignore OS configuration (and Firefox may simply not know whether that OS config is manual or automatic config). Firefox or other clients with similar behavior may then want to know more about network preferences while ignoring the OS-configured classic DNS resolver. In fact, I would say that Firefox's current use of the use-application-dns.net canary domain would be a non-standardized example of such network-preference communication, and standardizing similar communication seems to me to be very in-scope for this WG. 4. Even if clients don't want to respect network preferences at all, it could be helpful for the client to get signals about it if the network starts attempting to actively enforce its preferences. Could be helpful in error messaging and such. I believe a few people have brought up this case in the mailing list in the past few weeks. > > Within SPAU, I think a useful distinction is Ekr's "steering which generic > resolver will be used". This allows for the current provider to have > multiple possible resolvers (e.g. edge vs core), and communicating the > nature of the differences between those options. > > Finally we have Domain Designated Resolvers, where domains tell you what > their preferred resolver is. > > Any thoughts on the scope of each draft, and how many should be created in > time for the September interim? > > Chris > > P.S. In terms of content, one idea I've had is that each should also > mention performance considerations, particularly as I'm now thinking that > the larger the set of resolvers a client talks to, the fewer requests it > sends to each, and the more likely it is that a query will require a new > TLS setup. Jim also mentioned another, that they'll need to report on > GDPR-type issues > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000006e6eb705abfbdcdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jul 31, 2020 at 1:35 PM Chris= Box (BT) <chris.box.ietf@gm= ail.com> wrote:
All,

My take on the c= onclusion of this week's meeting (notes at https://codimd.ietf.org/n= otes-ietf-108-add?view) was that the next step should be to step back a= nd write some new drafts that clearly define the problem statement and requ= irements to be met.

Assuming there is more tha= n one of these drafts, how would you define the subject area for each one?<= /div>

Martin and Eric (Orth) both suggested Same Provide= r Auto Upgrade, aka "discovering potential upgrade information for the= current resolver".

Eric also suggested &= quot;networks communicating what their preferred resolver is". If the = current resolver is the one automatically learned from the network, this is= identical to the above. If it is not, because there's manual configura= tion, presumably we always/nearly-always honor the manual config? But are t= here cases where it's still helpful to know the network's preferenc= e?

I would anticipate most clie= nts wanting to respect manual config as much as possible, but that still do= esn't rule out potential use for communicating network preferences.=C2= =A0 Some possible cases I can think of:
  1. Network confi= guration is in use, but the network wants to request different providers fo= r classic vs encrypted DNS.=C2=A0 Eg, maybe the network wants to advertise = some legacy resolver for Do53 that for whatever reason doesn't support = any upgrade discovery, but the network still wants to say "if you supp= ort DoH, use this other provider instead".
  2. In client configura= tion UIs, it may be helpful to inform the user of current configuration or = other network preferences as the user makes decisions.
  3. Respecting m= anual config gets more nuanced as more and more parties do DNS and potentia= lly have their own configuration at different levels.=C2=A0 E.g., I believe= the=C2=A0current=C2=A0Firefox behavior is to respect manual configuration = in Firefox, but generally ignore OS configuration (and Firefox may simply n= ot know whether that OS config is manual or automatic config).=C2=A0 Firefo= x or other clients with similar behavior may then want to know more about n= etwork preferences while ignoring the OS-configured classic DNS resolver.= =C2=A0 In fact, I would say that Firefox's current use of the use-application-dns.net canary doma= in would be a non-standardized example of such network-preference communica= tion, and standardizing similar communication seems to me to be very in-sco= pe for this WG.
  4. Even if clients don't want to respect network p= references at all, it could be helpful for the client to get signals about = it if the network starts attempting to actively enforce its preferences.=C2= =A0 Could be helpful in error messaging and such.=C2=A0 I believe a few peo= ple have brought up this case in the mailing list in the past few weeks.
=C2=A0

Within SPAU, I think a useful dis= tinction is Ekr's "steering which generic resolver will be used&qu= ot;. This allows for the current provider to have multiple possible resolve= rs (e.g. edge vs core), and communicating the nature of the differences bet= ween those options.

Finally we have=20 Domain Designated Resolvers, where domains tell you what their preferred re= solver is.

Any thoughts on the scope of each draft= , and how many should be created in time for the September interim?

Chris

P.S. In terms of content, one idea I've had is that each should also me= ntion performance considerations, particularly as I'm now thinking that= the larger the set of resolvers a client talks to, the fewer requests it s= ends to each, and the more likely it is that a query will require a new TLS= setup. Jim also mentioned another, that they'll need to report on GDPR= -type issues

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000006e6eb705abfbdcdf-- From nobody Tue Aug 4 05:47: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 7DA543A0AFA for ; Tue, 4 Aug 2020 05:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 3iYMhDcaE-TF for ; Tue, 4 Aug 2020 05:47:11 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 9D23F3A0AF8 for ; Tue, 4 Aug 2020 05:47:11 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id g26so38239674qka.3 for ; Tue, 04 Aug 2020 05:47:11 -0700 (PDT) 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=MlKjnLUdm7dy57UZXR0iilzFo08aA7I1Auk3YKjo/oA=; b=jNBvcmid7qFg4TYZPwjs3hcZvBbjLTASLKHJ91lYkpCJuhIkG3WYD/uk8hWOqPGVMB /f3MDNDmpm7hjkmCfCP96uJ5OnHw+sN1/9xBjhmMaSSyL8HPl2ueFyZugja3Y0ttNXU7 WPppgdSWZSOjI03ZCdLPJ3Wjr8w798yO1ihdV10e8oXIbOlm2sr+LjijzCKb1oMcNBG4 IEsKw7ZfVaNHG3dt5fNkItqKVQXWTXy7V6Fn7RIJwXD6xCYN+n6Bh+k5xA193g9W2UYm h59cuMjtIPFQQvYyM1jhmi3DIo+LF0Bhnb+bRb5QIDHc/6NuX6h4zcDCUvCd6n9bkNKo Bh6w== 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=MlKjnLUdm7dy57UZXR0iilzFo08aA7I1Auk3YKjo/oA=; b=U2xpxZEZAfbQ3uB63pmgERuZFPbVfEcBFI9vD1zla/4qaccrV1C7JV+j4XVUQU20DB BNHXhMEs3wDpfd1XNQBiivzt7VV3R5NpylXHwvmpBZsbnVF4/s7P3vYqYw5e7madvHE+ NU4Eqpk/i4Dkdqt/gVF4EC9U8eCvhgc4/pDXmPeN3AbeGHYp5sddbaQcHOU02UGeoAX1 HwLmBWdj47HWbkmTqSu8Awa2tstPcVJHBtx2jXOQITlbjMEbKTdkejWO9SQGoWpqvw4d bxFXLTLHaB6jkup+7hZJ0S/2JE+fbC2h2H189gtEaMtjUiYbxWTUD9BG16dusIIYvQgV 0/zg== X-Gm-Message-State: AOAM530WJ9z5LHCHN7ushLuGsKFQYWbTeqI/kbS0aAUrypNJqc12by9E JqECxDZqvfC941xdRQ4yJf3CTRAoa8fD48gBf14= X-Google-Smtp-Source: ABdhPJxyEohzy/lFPPnptEbHGBvd4jsNUHO7QbI21nkqGgz/C20NCxPMRAVpZbLQS87Nr3VfTXU629rK8GAc1d33RY0= X-Received: by 2002:a05:620a:21cf:: with SMTP id h15mr20275351qka.123.1596545230682; Tue, 04 Aug 2020 05:47:10 -0700 (PDT) MIME-Version: 1.0 References: <0d768d14-0a11-46fa-8ff8-1b63c578df2a@www.fastmail.com> <20200721073934.GA29757@nic.fr> <20200723143446.GA648@nic.fr> <20200727142812.GC4377@nic.fr> <959429540.478.1596442228109@appsuite-gw2.open-xchange.com> In-Reply-To: <959429540.478.1596442228109@appsuite-gw2.open-xchange.com> From: Lanlan Pan Date: Tue, 4 Aug 2020 20:46:59 +0800 Message-ID: To: Vittorio Bertola Cc: Stephane Bortzmeyer , Andrew Campling , "add@ietf.org" Content-Type: multipart/alternative; boundary="00000000000057c0e605ac0ca75b" Archived-At: Subject: Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators 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 Aug 2020 12:47:13 -0000 --00000000000057c0e605ac0ca75b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Vittorio Bertola =E4=BA=8E2020=E5=B9=B4= 8=E6=9C=883=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=884:10=E5=86=99=E9= =81=93=EF=BC=9A > > > Il 01/08/2020 19:42 Lanlan Pan ha scritto: > > > Agree, CPE is not a terminal equipment. > > Just for reference, "terminal equipment" in Europe is defined by directiv= e > 2008/63/EC: > > > 'terminal equipment=E2=80=99 means: > > (a) equipment directly or indirectly connected to the interface of a > public telecommunications network to send, process or receive information= ; > in either case (direct or indirect), the connection may be made by wire, > optical fibre or electromagnetically; a connection is indirect if equipme= nt > is placed between the terminal and the interface of the network; > > (b) satellite earth station equipment; > > On my personal option, for home network environment ( PC/Mobile Phone <---> CPE <---> Internet ), CPE is not a teminal equipment, but a intermediate equipment on PC/Mobile Phone <---> Internet connection. Of course, this then changes the question into: where is the "interface of > a public telecommunications network" located? This is a definition that > falls under the competence of each individual member State, so one could > read this useful 94-page BEREC report that has information on each countr= y: > > > https://berec.europa.eu/eng/document_register/subject_matter/berec/report= s/8252-berec-report-on-the-location-of-the-network-termination-point > > Bottom line: understanding regulation in Europe is not always immediate > :-) But according to the report, almost all the countries that took a > decision located the interface between the modem and the Internet, making > the CPE "terminal equipment"; in one country this depends on who owns it. > Of course, for NTP scenario ( CPE <--> NTP Server ), CPE is a terminal equipment. Personal technology discussion, nothing to do with BEREC. Thanks, :-) > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > --00000000000057c0e605ac0ca75b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Vittorio Bertola <vittorio.bertola@open-xchange.com> = =E4=BA=8E2020=E5=B9=B48=E6=9C=883=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5= =8D=884:10=E5=86=99=E9=81=93=EF=BC=9A
=20 =20 =20
=C2=A0
=20
=20
Il 01/08/2020 19:42 Lanlan Pan <abbypan@gmail.com> ha scritto:
=20
=C2=A0
=20
=C2=A0
=20
=20
Agree, CPE is not a terminal equipment.
=20
=20
=20
Just for reference, "terminal equipment" in Europe is defined = by directive 2008/63/EC:
=20
=C2=A0
=20
=C2=A0
=20
'= terminal equipment=E2=80=99 means: =20
=20
=20
=20
=C2=A0
=20
(= a) equipment directly or indirectly connected to the interface of a public = telecommunications network to send, process or receive information; in eith= er case (direct or indirect), the connection may be made by wire, optical f= ibre or electromagnetically; a connection is indirect if equipment is place= d between the terminal and the interface of the network;
=20
=C2=A0
=20
(= b) satellite earth station equipment;
=20
=C2=A0
=
On my personal option,=C2=A0 for home network environment (=C2=A0 PC/Mobil= e Phone <--->=C2=A0 CPE <---> Internet=C2=A0 ),=C2=A0 CPE is no= t a teminal equipment, but=C2=A0 a intermediate equipment on PC/Mobile Phon= e=C2=A0 <--->=C2=A0 Internet=C2=A0 connection.

=20
Of course, this then changes the question into: where is the "inter= face of a public telecommunications network" located? This is a defini= tion that falls under the competence of each individual member State, so on= e could read this useful 94-page BEREC report that has information on each = country:
=20
=C2=A0
=20 =20
=C2=A0
=20
Bottom line: understanding regulation in Europe is not always immediate = :-) But according to the report, almost all the countries that took a decis= ion located the interface between the modem and the Internet, making the CP= E "terminal equipment"; in one country this depends on who owns i= t.

Of course,=C2=A0=C2=A0 for NTP scenario ( CPE <--> NTP Server ),=C2= =A0 CPE is a terminal equipment.
Personal technology dis= cussion, nothing to do with BEREC.=C2=A0
Thanks, :-)
=20
=20

--

=20 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchangevit=
torio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torin=
o, Italy
=20
--00000000000057c0e605ac0ca75b-- From nobody Tue Aug 4 10:47: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 DD5413A0E05 for ; Tue, 4 Aug 2020 10:47:18 -0700 (PDT) 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 UPl2CV-8_7pw for ; Tue, 4 Aug 2020 10:47:16 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 B2BC53A0E04 for ; Tue, 4 Aug 2020 10:47:16 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id t6so14520828qvw.1 for ; Tue, 04 Aug 2020 10:47:16 -0700 (PDT) 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; bh=IqKM6Hv6vV82PYZUozUr312Yc7SRmc3/boaxbabLoQo=; b=H2Z1PxQ7JzGxh1qxobE4miiB/5I4UwSIxllLZTuQmyG9OOIZv0+9sw3Ahw5rgWU/ea /1n58ytGp153wjiLYCv7WDyG/seRKl0msmdWZ8Z4ALvEfp5HIxFbI1sgDR1mAetjij6D AdJEcRn1UkDSM3fTqcYRxmM3pERtIFM3sc5FDEWUjaEmPWa8/Bmun3Y9JsG2v33ScEx6 n8xbVf9+ji+liPPQvDw17/rQONDmS19TWWor6ukyi6ob9r7+0pad8G71yqRIYS7KyXs0 KkYwrkaPMP8BVq1IMpF7PqxeZRgS8WGPIe5RCAz152SmuDUYA2J25WDgh8riwjq6I2in vLLg== 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; bh=IqKM6Hv6vV82PYZUozUr312Yc7SRmc3/boaxbabLoQo=; b=ErFz2qRaa1hnTn4mcSMMxdtZv93HhWX0ppPudyA1VmRTIXuPygI6C74l61utMfjRYG 9WZKezz2ujyyyHdeOO5RXf1/jgWdcPTCdrZGj7JKv1HSPyFrLqdSNYvcPEIdIJc++o3D MTEsA6lyvh8uH0epk12iOZ4h/kvRRX+y/z8l+pbnUFSunyQYooXLyIFzM3+DHoTI+n8j 75q7+kgHdpELWRQW+cg3u6FM9c2wQJ7klcVToErbQY/dA5Lp0AKsJyOeoFRG5nTum8iC jU5ikGntVMO4EQYg3TchjRMOCj0/ENAdXzIteqvOTzOS1JyKh1WdUm4Z1E3xT4hZKz+G PYsg== X-Gm-Message-State: AOAM530s5F2mfHxaFK7tnKA4fL5hE98AztXEhDMDfoq+KQEmYpD3G4qW fe4XvtUrr3JVrnZNvJNL7UVPqeruWFm+WyD0WBJz8e/P X-Google-Smtp-Source: ABdhPJwlt0quEZmzy/KhxcuEuOhbEZxFJ8cU7/qGJHcx7T5ml+Gush5OF1zZ2wHN6J1pTulUddJS2aAF3dDe4o8r1ug= X-Received: by 2002:a0c:b665:: with SMTP id q37mr22853298qvf.75.1596563235320; Tue, 04 Aug 2020 10:47:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Chris Box (BT)" Date: Tue, 4 Aug 2020 18:47:03 +0100 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000080b5e805ac10d839" Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 17:47:19 -0000 --00000000000080b5e805ac10d839 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What a good start to the thread. You've managed to turn my uncertain grouping into something that looks a *lot* cleaner. So perhaps we only need one requirements draft, containing use cases broken down like this. 1. Given a known resolver, discover one or more associated/equivalent encrypted resolvers 1a: Discover encrypted resolvers that are equivalent to the resolver given out by DHCP/RA/PCO 1aa: Discovering encrypted resolvers behind forwarders, and using them directly (thus bypassing the forwarder) 1ab: Discovering and using encrypted DNS running on forwarders (note that this could involve interactions with the encrypted resolver =E2=80=9Cbehind= =E2=80=9D the forwarder) 1b: Discover encrypted resolvers that are equivalent to a manually-configured resolver, which may be a public Internet resolver 1c: Discover encrypted resolvers that are equivalent to a VPN-configured DNS servers 2. Discover an encrypted resolver that is applicable to a limited domain 2a: Discover a mapping between a locally-hosted domain and an encrypted resolver - Walled-garden content - Locally-cached content - Private enterprise names 2b: Discover a mapping between a public domain and an encrypted resolver - Name hosted by CDN foo can use CDN foo=E2=80=99s resolver Eric's point 1 I think can be addressed within 1a. Point 2 perhaps applies to the whole document. Point 3 may require some ability for the discovered information to be shared between OS and applications; we can probably describe this in high level terms. Point 4 may need its own section that elaborates the need for the network to communicate the enforcement that may take place (or is taking place). I agree the capability is needed, but is this more appropriate for ADD or CAPPORT? Chris On Mon, 3 Aug 2020 at 17:45, Eric Orth wrote: > > > On Fri, Jul 31, 2020 at 1:35 PM Chris Box (BT) > wrote: > >> All, >> >> My take on the conclusion of this week's meeting (notes at >> https://codimd.ietf.org/notes-ietf-108-add?view) was that the next step >> should be to step back and write some new drafts that clearly define the >> problem statement and requirements to be met. >> >> Assuming there is more than one of these drafts, how would you define th= e >> subject area for each one? >> >> Martin and Eric (Orth) both suggested Same Provider Auto Upgrade, aka >> "discovering potential upgrade information for the current resolver". >> >> Eric also suggested "networks communicating what their preferred resolve= r >> is". If the current resolver is the one automatically learned from the >> network, this is identical to the above. If it is not, because there's >> manual configuration, presumably we always/nearly-always honor the manua= l >> config? But are there cases where it's still helpful to know the network= 's >> preference? >> > > I would anticipate most clients wanting to respect manual config as much > as possible, but that still doesn't rule out potential use for > communicating network preferences. Some possible cases I can think of: > > 1. Network configuration is in use, but the network wants to request > different providers for classic vs encrypted DNS. Eg, maybe the netwo= rk > wants to advertise some legacy resolver for Do53 that for whatever rea= son > doesn't support any upgrade discovery, but the network still wants to = say > "if you support DoH, use this other provider instead". > 2. In client configuration UIs, it may be helpful to inform the user > of current configuration or other network preferences as the user make= s > decisions. > 3. Respecting manual config gets more nuanced as more and more parties > do DNS and potentially have their own configuration at different level= s. > E.g., I believe the current Firefox behavior is to respect manual > configuration in Firefox, but generally ignore OS configuration (and > Firefox may simply not know whether that OS config is manual or automa= tic > config). Firefox or other clients with similar behavior may then want= to > know more about network preferences while ignoring the OS-configured > classic DNS resolver. In fact, I would say that Firefox's current use= of > the use-application-dns.net canary domain would be a non-standardized > example of such network-preference communication, and standardizing si= milar > communication seems to me to be very in-scope for this WG. > 4. Even if clients don't want to respect network preferences at all, > it could be helpful for the client to get signals about it if the netw= ork > starts attempting to actively enforce its preferences. Could be helpf= ul in > error messaging and such. I believe a few people have brought up this= case > in the mailing list in the past few weeks. > > > >> >> Within SPAU, I think a useful distinction is Ekr's "steering which >> generic resolver will be used". This allows for the current provider to >> have multiple possible resolvers (e.g. edge vs core), and communicating = the >> nature of the differences between those options. >> >> Finally we have Domain Designated Resolvers, where domains tell you what >> their preferred resolver is. >> >> Any thoughts on the scope of each draft, and how many should be created >> in time for the September interim? >> >> Chris >> >> P.S. In terms of content, one idea I've had is that each should also >> mention performance considerations, particularly as I'm now thinking tha= t >> the larger the set of resolvers a client talks to, the fewer requests it >> sends to each, and the more likely it is that a query will require a new >> TLS setup. Jim also mentioned another, that they'll need to report on >> GDPR-type issues >> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > --00000000000080b5e805ac10d839 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What a good start to the thread. You've managed t= o turn my uncertain grouping into something that looks a *lot* cleaner.

So perhaps we only need one requirements draft, conta= ining use cases broken down like this.

1. Given a known resolver, discover one or more associated/equivalent encrypted resolvers

= 1a: Discover encrypted resolvers that are equivalent to the resolver given out = by DHCP/RA/PCO

1aa:=20 Discovering encrypted resolvers behind forwarders, and using them directly = (thus bypassing the forwarder)

1ab:=20 Discovering and using encrypted DNS running on forwarders (note that=20 this could involve interactions with the encrypted resolver =E2=80=9Cbehind= =E2=80=9D the forwarder)

= 1b: Discover encrypted resolvers that are equivalent to a manually-configured resolver, which may be a public Internet resolver

= 1c: Discover encrypted resolvers that are equivalent to a VPN-configured DNS servers

=C2=A0

2. Discover an encrypted resolver that is applicable to a limited domain

= 2a: Discover a mapping between a locally-hosted domain and an encrypted resolve= r

= - Walled-garden content

= - Locally-cached content

= - Private enterprise names

= 2b: Discover a mapping between a public domain and an encrypted resolver

= - Name hosted by CDN foo can use CDN foo=E2=80=99s resolver


Eric's point 1 I think can be addressed withi= n 1a. Point 2 perhaps applies to the whole document. Point 3 may require so= me ability for the discovered information to be shared between OS and appli= cations; we can probably describe this in high level terms. Point 4 may nee= d its own section that elaborates the need for the network to communicate t= he enforcement that may take place (or is taking place). I agree the capabi= lity is needed, but is this more appropriate for ADD or CAPPORT?
=

Chris


On Mon, 3 Aug 2020 = at 17:45, Eric Orth <ericorth@goo= gle.com> wrote:


On Fri, Jul 31, 2020 at 1:35 P= M Chris Box (BT) <chris.box.ietf@gmail.com> wrote:
All,

<= /div>
My take on the conclusion of this week's meeting (notes at https://codimd.ietf.org/notes-ietf-108-add?view) was that the next ste= p should be to step back and write some new drafts that clearly define the = problem statement and requirements to be met.

= Assuming there is more than one of these drafts, how would you define the s= ubject area for each one?

Martin and Eric (Orth) b= oth suggested Same Provider Auto Upgrade, aka "discovering potential u= pgrade information for the current resolver".

=
Eric also suggested "networks communicating what their preferred = resolver is". If the current resolver is the one automatically learned= from the network, this is identical to the above. If it is not, because th= ere's manual configuration, presumably we always/nearly-always honor th= e manual config? But are there cases where it's still helpful to know t= he network's preference?

I = would anticipate most clients wanting to respect manual config as much as p= ossible, but that still doesn't rule out potential use for communicatin= g network preferences.=C2=A0 Some possible cases I can think of:
<= div>
  1. Network configuration is in use, but the network wants to reque= st different providers for classic vs encrypted DNS.=C2=A0 Eg, maybe the ne= twork wants to advertise some legacy resolver for Do53 that for whatever re= ason doesn't support any upgrade discovery, but the network still wants= to say "if you support DoH, use this other provider instead".
  2. In client configuration UIs, it may be helpful to inform the user of = current configuration or other network preferences as the user makes decisi= ons.
  3. Respecting manual config gets more nuanced as more and more pa= rties do DNS and potentially have their own configuration at different leve= ls.=C2=A0 E.g., I believe the=C2=A0current=C2=A0Firefox behavior is to resp= ect manual configuration in Firefox, but generally ignore OS configuration = (and Firefox may simply not know whether that OS config is manual or automa= tic config).=C2=A0 Firefox or other clients with similar behavior may then = want to know more about network preferences while ignoring the OS-configure= d classic DNS resolver.=C2=A0 In fact, I would say that Firefox's curre= nt use of the = use-application-dns.net canary domain would be a non-standardized examp= le of such network-preference communication, and standardizing similar comm= unication seems to me to be very in-scope for this WG.
  4. Even if clie= nts don't want to respect network preferences at all, it could be helpf= ul for the client to get signals about it if the network starts attempting = to actively enforce its preferences.=C2=A0 Could be helpful in error messag= ing and such.=C2=A0 I believe a few people have brought up this case in the= mailing list in the past few weeks.
=C2=A0

Within SPAU, I think a useful distinction is Ekr's "steering= which generic resolver will be used". This allows for the current pro= vider to have multiple possible resolvers (e.g. edge vs core), and communic= ating the nature of the differences between those options.
Finally we have=20 Domain Designated Resolvers, where domains tell you what their preferred re= solver is.

Any thoughts on the scope of each draft= , and how many should be created in time for the September interim?

Chris

P.S. In terms of content, one idea I've had is that each should also me= ntion performance considerations, particularly as I'm now thinking that= the larger the set of resolvers a client talks to, the fewer requests it s= ends to each, and the more likely it is that a query will require a new TLS= setup. Jim also mentioned another, that they'll need to report on GDPR= -type issues

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000080b5e805ac10d839-- From nobody Tue Aug 4 10:54: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 2E8593A0E26 for ; Tue, 4 Aug 2020 10:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 VvYtfB0nq7Wm for ; Tue, 4 Aug 2020 10:54:08 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 49F9A3A0E27 for ; Tue, 4 Aug 2020 10:54:08 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id 3so3783702wmi.1 for ; Tue, 04 Aug 2020 10:54:08 -0700 (PDT) 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; bh=8thCiUOxG3iFi5gWRvV86lnS2U1LZB95zZvJl2JIsqs=; b=YI2pJsjz/XpIE1dFHwz9O0KOmi035Yb5USgvo21Y50utz6cLEueFXcZJQ9G+JG+UVJ b0FN/H+poCsDefxukwcBrYvp7OxMaK7IIzWqdZhQnA2ql73ZIWjfgRXTJj7gfEN9+jSF N7lwI+SXUR4vMVi0VWyqqCQmpLKHMGXoXogfD6x1KXUoF/7xB/f5G3Lmlf3GOO4S016n 9wEcw3oxIkpi8dBtk2Zz3m78xQk5kf/3DI3378Z8mBOR8LcVkJw6FZEOUCkrTGO+nMIt JGTgUNRFp7PbTBOGhFbzqBYoy4r6zhNRpFOqqQnwQol7KCTR/zdYwVHih29LSsYodGEc XHLg== 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; bh=8thCiUOxG3iFi5gWRvV86lnS2U1LZB95zZvJl2JIsqs=; b=TwqnY9d72+gGuUlJGmWojyMnxsFlhwFXv5n0dkshrmcrX0MIr9DfkLNXzE4x0RH2PU J9838hAtBfE4cZLmyu4AHyL7BsBdBj/LmAVuZa8FcIBtzIAqLGnzybVHVYTB3XMmQOcm 4gKsJRMDuKqR5ZYkNMgr1fM/55whtXbALymdUw2Enm3v7G6rH8Mc41Z6y36uWR01O74x BP8Lz6R0styTg0UUWlqe6w20wg6DwDwALCMBv0he3GMYpwauwFici2zbJvEgcuI5Pcj7 4lSjXZHDX5Pe3tKdkwUTWsbYsjXFKTI9LmmLG4Mu1twwp2NhEfS6fOZbg86hXJTDfX7L jd1A== X-Gm-Message-State: AOAM532KtxtmyZHS3PwVFiaTzANU7Zo94Y8ndGFYaYMxvvGKKV1Q63xR CAWhYJKT8rTN2OQ4q8GkjNMKoj82OQeK9U9HdvjCvX6GnN8= X-Google-Smtp-Source: ABdhPJyNKvbGcP4F1Cr4EZKmEocKOwHLXzFE/bRJRY2W/KDU3HE1MXnd1X30yBxwg4bewZsuOxEzQHKO2RCggDMsvmc= X-Received: by 2002:a1c:49c6:: with SMTP id w189mr4786475wma.97.1596563646141; Tue, 04 Aug 2020 10:54:06 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> In-Reply-To: <159656272783.7072.6229544475907348131@ietfa.amsl.com> From: Ben Schwartz Date: Tue, 4 Aug 2020 13:53:54 -0400 Message-ID: To: ADD Mailing list , DNS Privacy Working Group , dnsop Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000047e6905ac10f113" Archived-At: Subject: [Add] Fwd: New Version Notification for draft-schwartz-svcb-dns-00.txt 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 Aug 2020 17:54:10 -0000 --000000000000047e6905ac10f113 Content-Type: multipart/alternative; boundary="000000000000fdac1e05ac10f0f7" --000000000000fdac1e05ac10f0f7 Content-Type: text/plain; charset="UTF-8" Hi ADD and DPRIVE, I've noticed three recent drafts that propose to use the SVCB format: draft-mglt-add-rdp, draft-tapril-ns2, and draft-pauly-add-resolver-discovery. These drafts, across multiple working groups, consider distinct use cases and architectures, but they all propose using SVCB (in very different ways) to convey information about a DNS server that supports encrypted transport. In the interest of harmonizing these proposals, creating a solid foundation, and separating concerns, I've written a short draft that specifies _only_ a minimal SVCB mapping for DNS URIs*, and does not address any specific use case. I hope this draft can enable each of these proposals to focus more on their goals, and worry less about the SVCB encoding. (It also serves as an interesting test of the SVCB design.) Please review, Ben Schwartz *SVCB is based on URIs like https://, so for a DNS mapping we start with dns:// URIs. ---------- Forwarded message --------- From: Date: Tue, Aug 4, 2020 at 1:38 PM Subject: New Version Notification for draft-schwartz-svcb-dns-00.txt To: Benjamin Schwartz A new version of I-D, draft-schwartz-svcb-dns-00.txt has been successfully submitted by Benjamin Schwartz and posted to the IETF repository. Name: draft-schwartz-svcb-dns Revision: 00 Title: Service Binding Mapping for DNS URIs Document date: 2020-08-04 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-00.txt Status: https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/ Htmlized: https://tools.ietf.org/html/draft-schwartz-svcb-dns-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns Abstract: The SVCB DNS record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a hostname in a "dns:" URI. This document provides the SVCB mapping for name-based DNS URIs, allowing DNS servers to indicate support for new transport protocols. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000fdac1e05ac10f0f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ADD and DPRIVE,

I've noticed thr= ee recent drafts that propose to use the SVCB format: draft-mglt-add-rdp, d= raft-tapril-ns2, and draft-pauly-add-resolver-discovery.=C2=A0 These drafts= , across multiple working=C2=A0groups,=C2=A0consider distinct use cases and= architectures, but they all propose using SVCB (in very different ways) to= convey information about a DNS server that supports encrypted transport.

In the interest of harmonizing these proposals, cre= ating a solid foundation, and separating concerns, I've written a short= draft that specifies _only_ a minimal SVCB mapping for DNS URIs*, and does= not address any specific use case.

I hope thi= s draft can enable each of these proposals to focus more on their goals,=C2= =A0and worry less about the SVCB encoding.=C2=A0 (It also serves as an inte= resting test of the SVCB design.)

Please revie= w,
Ben Schwartz

*SVCB is based on URIs like https://, so for a DNS mapping we start w= ith dns:// URIs.

---------- Forward= ed message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Aug 4, 2020 at 1:38 PM
Subject: New Version Notificat= ion for draft-schwartz-svcb-dns-00.txt
To: Benjamin Schwartz <bemasc@google.com>



A new version of I-D, draft-schwartz-svcb-dns-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-svcb-dns
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Service Binding Mapping for DNS UR= Is
Document date:=C2=A0 2020-08-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-0= 0.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-schwartz-svcb-dns-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns


Abstract:
=C2=A0 =C2=A0The SVCB DNS record type expresses a bound collection of endpo= int
=C2=A0 =C2=A0metadata, for use when establishing a connection to a named se= rvice.
=C2=A0 =C2=A0DNS itself can be such a service, when the server is identifie= d by a
=C2=A0 =C2=A0hostname in a "dns:" URI.=C2=A0 This document provid= es the SVCB mapping
=C2=A0 =C2=A0for name-based DNS URIs, allowing DNS servers to indicate supp= ort for
=C2=A0 =C2=A0new transport protocols.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--000000000000fdac1e05ac10f0f7-- --000000000000047e6905ac10f113 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCAlm7VDi/2ZV4Yq17WZohTSASTdrKDO0O/jrIlONZg4OjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA4MDQxNzU0MDZaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAUiusL3er36sdwaRxG5XBGQ1PwGOGOa0j4xegMhltN2wZOIUk1Dv2lTJpLi9s19feJnPrFf7B Er6SjRFHwZU/HZunl4+AGJlfHufQ6ZRiHQV8j/0dQ6/t6yn4yH59VFYaetOEH7TwFnw/o93cx3Gg 4BmFk3ydlexfOptpciNcHcCr6xvPlz7Nefa/QYgzcc94CUl+9DIBLZ9Mg6knCXIsHHxkZW4xNUu/ IrzAMnNN1zqzWO1zWbhMZRdnHIDI+aMUU6AQOUUrddJWE+NTNBKtugIQL6vcx4PxHolcRJ59Ct23 3gqLTvy71v0c3gYwZlp+fNQJfHiMppnopYHLu4hmzQ== --000000000000047e6905ac10f113-- From nobody Tue Aug 4 15:23: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 579FF3A11C7 for ; Tue, 4 Aug 2020 15:23:17 -0700 (PDT) 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, 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 YOd8givWhpm7 for ; Tue, 4 Aug 2020 15:23:16 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638673A111E for ; Tue, 4 Aug 2020 15:23:16 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id BF6BF2334A; Tue, 4 Aug 2020 15:23:15 -0700 (PDT) From: Wes Hardaker To: "Chris Box \(BT\)" Cc: ADD Mailing list References: Date: Tue, 04 Aug 2020 15:23:15 -0700 In-Reply-To: (Chris Box's message of "Tue, 4 Aug 2020 18:47:03 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 22:23:17 -0000 "Chris Box (BT)" writes: > What a good start to the thread. You've managed to turn my uncertain grouping into > something that looks a *lot* cleaner. > > So perhaps we only need one requirements draft, containing use cases broken down > like this. I suspect there is another case that most want to explicitly not pursue: Given a network, discover whether its use is acceptable according to the its operators, the ISP you're connecting under, and laws within the region. Functionally, use-application-dns.net is a mechanism for detecting ISP policy, eg. -- Wes Hardaker USC/ISI From nobody Tue Aug 4 17:41: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 5A39D3A0D5F for ; Tue, 4 Aug 2020 17:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 0IDziFa_86yv for ; Tue, 4 Aug 2020 17:40:58 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 623373A117A for ; Tue, 4 Aug 2020 17:40:58 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id k8so4627366wma.2 for ; Tue, 04 Aug 2020 17:40:58 -0700 (PDT) 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; bh=XFD5tcUnKfsf15UoUFJlWYFCiZm1ZWb6Vh/5ZjkdUsY=; b=CQRhbwugfe50+wFylf6AkjIUNPnDTSvM8EqNKCNLNU2/JKZ3xTulaq0GC/562DFHc4 1r2JabSTckG6d72i8Ael97j00sGsTvQGs8fe7yYrkuIrOsjteMxl2xerqad1PrnGqHGa fxbBGJvMEUeD0y6+pn/U7ODKzxk/z4Oqe8gHhRMGaoPpZjmFiZkVuIEjkUwdn+J/cW9P elXfGRqUk98nY/XGTU7a/3kmLTpaHGVK7+7RaT+eYWDKzQI/hhDGNK4K0R51mH7UpxfT Ac+HYtJExcGV//VA1Ud93/UxGG2pAosrflfoQUf3qJWLJivq+Ka6c0TdiK6UIjjMikgO jDMA== 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; bh=XFD5tcUnKfsf15UoUFJlWYFCiZm1ZWb6Vh/5ZjkdUsY=; b=UqEtxmoChfON+EJcxEL/3vVi6fmwInHrBQY3rphnqpqYxzsA8zK0kQueqwGjMHTdHi g5wAQ9EdLyhIrkbGckCv61sLTYnjjSOFpn9DqXrNrN/lkCvv7Eb9O8Cb6Ozkv836r9r3 kcd+jIvjcNoOMMkYKZlCSQhKTo2VyhGd+z1HbNYfDwuaIcXRhaUMqrs6l5aoDBj0lx0R O87CfMIOK/YPdurTjpwTIttaNThHJsybifApC9FmrTYZIhYQKPct18uSwA/YmCwhXwh0 szN5x5pDokl8cdjQ1oAb4tv0fkfwIdNBvS7pXXGdQEqVRPteBB76s/0l4GQfYVZ3RmQ/ J79A== X-Gm-Message-State: AOAM531iG8yTETscXRNBYD9AkZuPBGOZ3oTAG4HOpJtBOJobY5q1sV6t MUuale5LgDAy6cAddXb2gSU4E0/70szmIsBBK+X2y/Pm X-Google-Smtp-Source: ABdhPJxjiNNXrbeJn6JXURc1npkkcoEuBcmrLlii9to69O8vsLW235UFUsq7aF4tnsuwarT4Wf1CCJy5SjOQR1kEWJo= X-Received: by 2002:a1c:7918:: with SMTP id l24mr798260wme.132.1596588056100; Tue, 04 Aug 2020 17:40:56 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> In-Reply-To: From: Ben Schwartz Date: Tue, 4 Aug 2020 20:40:44 -0400 Message-ID: To: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000f6595705ac169fa3" Archived-At: Subject: Re: [Add] New Version Notification for draft-schwartz-svcb-dns-00.txt 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 Aug 2020 00:41:00 -0000 --000000000000f6595705ac169fa3 Content-Type: multipart/alternative; boundary="000000000000f0200005ac169fd3" --000000000000f0200005ac169fd3 Content-Type: text/plain; charset="UTF-8" Moving DPRIVE and DNSOP to BCC to avoid cross-posting. On Tue, Aug 4, 2020 at 1:53 PM Ben Schwartz wrote: > Hi ADD and DPRIVE, > > I've noticed three recent drafts that propose to use the SVCB format: > draft-mglt-add-rdp, draft-tapril-ns2, and > draft-pauly-add-resolver-discovery. These drafts, across multiple > working groups, consider distinct use cases and architectures, but they all > propose using SVCB (in very different ways) to convey information about a > DNS server that supports encrypted transport. > > In the interest of harmonizing these proposals, creating a solid > foundation, and separating concerns, I've written a short draft that > specifies _only_ a minimal SVCB mapping for DNS URIs*, and does not address > any specific use case. > > I hope this draft can enable each of these proposals to focus more on > their goals, and worry less about the SVCB encoding. (It also serves as an > interesting test of the SVCB design.) > > Please review, > Ben Schwartz > > *SVCB is based on URIs like https://, so for a DNS mapping we start with > dns:// URIs. > > ---------- Forwarded message --------- > From: > Date: Tue, Aug 4, 2020 at 1:38 PM > Subject: New Version Notification for draft-schwartz-svcb-dns-00.txt > To: Benjamin Schwartz > > > > A new version of I-D, draft-schwartz-svcb-dns-00.txt > has been successfully submitted by Benjamin Schwartz and posted to the > IETF repository. > > Name: draft-schwartz-svcb-dns > Revision: 00 > Title: Service Binding Mapping for DNS URIs > Document date: 2020-08-04 > Group: Individual Submission > Pages: 8 > URL: > https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-00.txt > Status: https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/ > Htmlized: https://tools.ietf.org/html/draft-schwartz-svcb-dns-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns > > > Abstract: > The SVCB DNS record type expresses a bound collection of endpoint > metadata, for use when establishing a connection to a named service. > DNS itself can be such a service, when the server is identified by a > hostname in a "dns:" URI. This document provides the SVCB mapping > for name-based DNS URIs, allowing DNS servers to indicate support for > new transport protocols. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > --000000000000f0200005ac169fd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Moving DPRIVE and DNSOP to BCC to avoid cross-posting.
On T= ue, Aug 4, 2020 at 1:53 PM Ben Schwartz <bemasc@google.com> wrote:
Hi ADD and DPRIVE,

I've noticed three recent drafts that propose to use the SVCB format= : draft-mglt-add-rdp, draft-tapril-ns2, and draft-pauly-add-resolver-discov= ery.=C2=A0 These drafts, across multiple working=C2=A0groups,=C2=A0consider= distinct use cases and architectures, but they all propose using SVCB (in = very different ways) to convey information about a DNS server that supports= encrypted transport.

In the interest of harmonizi= ng these proposals, creating a solid foundation, and separating concerns, I= 've written a short draft that specifies _only_ a minimal SVCB mapping = for DNS URIs*, and does not address any specific use case.
I hope this draft can enable each of these proposals to focus = more on their goals,=C2=A0and worry less about the SVCB encoding.=C2=A0 (It= also serves as an interesting test of the SVCB design.)

=
Please review,
Ben Schwartz

<= div style=3D"margin:0px;padding:0px 0px 20px;width:856px;font-family:Roboto= ,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium">
*SVCB is ba= sed on URIs like https://, so for a DNS mapping we start with dns:// URIs.<= /div>

---------- Forwarded message ------= ---
From: <internet-drafts@ietf.org>
Date: Tue= , Aug 4, 2020 at 1:38 PM
Subject: New Version Notification for draft-sch= wartz-svcb-dns-00.txt
To: Benjamin Schwartz <bemasc@google.com>


<= br> A new version of I-D, draft-schwartz-svcb-dns-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-svcb-dns
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Service Binding Mapping for DNS UR= Is
Document date:=C2=A0 2020-08-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-0= 0.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-schwartz-svcb-dns-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns


Abstract:
=C2=A0 =C2=A0The SVCB DNS record type expresses a bound collection of endpo= int
=C2=A0 =C2=A0metadata, for use when establishing a connection to a named se= rvice.
=C2=A0 =C2=A0DNS itself can be such a service, when the server is identifie= d by a
=C2=A0 =C2=A0hostname in a "dns:" URI.=C2=A0 This document provid= es the SVCB mapping
=C2=A0 =C2=A0for name-based DNS URIs, allowing DNS servers to indicate supp= ort for
=C2=A0 =C2=A0new transport protocols.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--000000000000f0200005ac169fd3-- --000000000000f6595705ac169fa3 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCDaORh2jyE5dM+ojL+nqBtID96adzKBtg/XHNs4dWJ6fjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA4MDUwMDQwNTZaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAelLmGfmOX5Hy4LzY4oQCLm6z7E9H6PizHL4XRj5AEM5iZ9SMvUglOWXCsBlhyZyprXYtBdBY XqLazOBChkcgXrTzxuCWXvdODYzwGMNYjsAiVWmOJrGOeP6m+Qf5tB2PJ1RSGo063aDsfsPfVWTG YGwCibi5x/12ej5wanJcoBo24acGZHHWAuyaKsJM3UTy/H7vrZ+TfSZOdD/FOMOSTDtULCi6qMos z37C3GwqgR3D4mXDtlNki2JvlZXyaiuez/tOdjimkX7x0Qb5/zk7wzRvx4yiJ+StTqu+UXVhUaJx kAm9jZ/HfKKERxttcMJsirSe1zikcK0LYG+Mnh5IDw== --000000000000f6595705ac169fa3-- From nobody Tue Aug 4 20:37: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 49B593A1285 for ; Tue, 4 Aug 2020 20:37:20 -0700 (PDT) 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, 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 (2048-bit key) header.d=lowentropy.net header.b=lhxA25yL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kUIIyP6k 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 iFC3PPx46ugO for ; Tue, 4 Aug 2020 20:37:19 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1EC3A1286 for ; Tue, 4 Aug 2020 20:37:18 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3213D5C00B0 for ; Tue, 4 Aug 2020 23:37:18 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 04 Aug 2020 23:37:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=8yuPs OzVFhnN0Yy+z1aEaBjXgdrUgPpyJzbIkE9cVuk=; b=lhxA25yLT10216b7mmDT3 nayWd0G9LCYMIY2yVrLHSGMzM4X5BTMDDuWMCt8zqcNqHMs1oVnLLxNY5HEkC/MN mVY71pY/JPYLjYPTwmcb95EvmZqtoshckAXlUTW0SK9XipS1xZoBX2qkPZsrms// A6FS9sLynqju8LgqaRgQhcJXi6Hpf+dgj7qoh+kbSeGGuIzEY7pUUYqvpFr4dSyU mtSJTLyAI/pleuBeQFAvOtkQPt2rf/AuRJWgEq48jptBrNHXZzzCAFkfjf0mAuqv 3boiccyBS1MNluMq0kMiwCxB60CaifUFSdkR55CGs94wV/8XXc0O9ZIAUTAzmyFM w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=8yuPsOzVFhnN0Yy+z1aEaBjXgdrUgPpyJzbIkE9cV uk=; b=kUIIyP6kQbfsmmgI4bzSHGbpHDxboNejbd0bGvfPEyV7pEBuIY9ODX+bh EBS8AafhE9f4BtXNSlXUwC6rMXNUavH/sh6oa4X9XstANAUYR+0ofifiZCFYfazE YVKG7LmkS88xs+kFfAnaxdSSoIEkQqLRAsi/kM4fD4wLo5wIVx36YeJXGDFP6dtB M5o+O6cWLMY2yfwltyKmaOWe/bI3uG1l3zhNtMmHfFHPIRNefkAQcGg8S0WNpLvS LG8d4Z/5NtsfotOjvZyq/4J80cPE32Ztol8FsThjr/DF5TG+cM3+YbHICcyB/tBq 9JcFtJ+13bstFN9v8/7C3VVO+hLrA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeejgdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefgjeeuudeiffeltdegle ehjedvtedtjeduudehgfegfefgkefgueeiteegffdttdenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DA5B0E00C9; Tue, 4 Aug 2020 23:37:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-137-g55afb58-fm-20200804.001-g55afb586 Mime-Version: 1.0 Message-Id: <356083f6-0a16-4c05-926b-e13e5a195a3c@www.fastmail.com> In-Reply-To: References: Date: Wed, 05 Aug 2020 13:36:57 +1000 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 03:37:20 -0000 Hi Chris, I think that this is a helpful simplification. I have a question on the= first arm of your taxonomy below. This is probably just tactical, but = it would be good to clarify. On Wed, Aug 5, 2020, at 03:47, Chris Box (BT) wrote: > So perhaps we only need one requirements draft, containing use cases=20= > broken down like this. >=20 > 1. Given a known resolver, discover one or more associated/equivalent=20= > encrypted resolvers Do we necessarily have to have knowledge of a resolver before starting d= own this path? I say that because 1a ultimately involves the network sa= ying something about the resolver and you could do this one of two ways:= i) The network says "here is a resolver" and then you define a mechanism= to go from that information - which is probably just an IP address - to= encrypted resolver coordinates. ii) The network says "here are the coordinates for a resolver that suppo= rts DoE". I can see how you might want the former if your view is that you want to= provide an upgrade path where the resolver is configured via unspecifie= d means (your 1b or 1c), but I don't think that is the dominant case. W= e heard that >90% of people don't touch defaults, so it seems to me that= there are two avenues for investigation, which conveniently correspond = to your 1aa/1ab distinction: =CE=B1) enhance the mechanisms that people use to discover a resolver (D= HCP, RA, PPP, whatever) =CE=B2) find a way to talk to the resolver and get its opinion You can imagine that a client with no opinion might do =CE=B1 then =CE=B2= . In those deployments that include a forwarder as part of a gateway/ro= uter this offers that device an opportunity to offer its opinion if it h= as been updated. Absent that upgrade, there will be no DoE information = presented, so clients might then try asking the resolver (using resolver= -info.arpa and SVCB or whatever happens to be fashionable when we eventu= ally decide). A client with an opinion about a resolver, but no information about DoE = might just do =CE=B2. From nobody Wed Aug 5 07:36: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 097F53A0A09 for ; Wed, 5 Aug 2020 07:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 r4PDW1-SbO9u for ; Wed, 5 Aug 2020 07:36:09 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 E876B3A0A29 for ; Wed, 5 Aug 2020 07:36:08 -0700 (PDT) Received: by sdaoden.eu (Postfix, from userid 1000) id 615CD16058; Wed, 5 Aug 2020 16:36:06 +0200 (CEST) Date: Wed, 05 Aug 2020 16:36:04 +0200 From: Steffen Nurpmeso To: Ben Schwartz Cc: ADD Mailing list , Steffen Nurpmeso Message-ID: <20200805143604.h2FWD%steffen@sdaoden.eu> In-Reply-To: References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> Mail-Followup-To: Ben Schwartz , ADD Mailing list , Steffen Nurpmeso User-Agent: s-nail v14.9.19-99-g19301483-dirty OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-schwartz-svcb-dns-00.txt 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 Aug 2020 14:36:11 -0000 [dropping the DNS only lists i am not subscribed to] Ben Schwartz wrote in : |Hi ADD and DPRIVE, | |I've noticed three recent drafts that propose to use the SVCB format: |draft-mglt-add-rdp, draft-tapril-ns2, and |draft-pauly-add-resolver-discovery. These drafts, across multiple I do not want to be counterproductive, having read only one of those drafts, and having read all of DNS except for zone transfer related RFCs >15 years ago in order to create a caching stub resolver, but i "like" DNS, and am fascinated of this protocol that is in use for such a long time, and still scales and is omnipresent. -Today- Yesterday i have reread RFC 6763 and RFC 2782 and really like all of it. Is there a "benefit in changing established practice". I never liked IDNA, i would have imposed a policy to rise the length limit by then, using UTF-8 (or UTF-7, maybe, as still in IMAP, though not have read the draft of v2 yet) and as of today i would presume all in-use name servers could serve those requests, aka even long domain names could be assigned all over the world. Its version 2 introduced the incompatibilities that ought to be avoided. I personally do not see an improvement in introducing yet another RR in order to support this. Maybe i should look in bind code or so and test whether it would be harder to return the favoured or desired set of RR combinations for a RR type or a question for a specific SRV. But even a clause that says "if that RR is provided HTTPS transport is a MUST" does not justify that for me. I.e., you could ask for "dnss://" and get A/AAAA for http[123]:// in combination also. Of course SVCB is more explicit. But o Address a set of long-standing issues due to HTTP(S) clients not implementing support for SRV records, as well as due to a limitation that a DNS name can not have both CNAME and NS RRs (as is the case for zone apex names)) draft-jennings-http-srv never made it. _https._tcp is no option therefore as of today. I really had to read the possibly one year plus IETF discussion history on why this did not make it. But i think the above is unfair, it misses the context. I could imagine they did not implement it because it is still unnecessary as of today in practice, there is /etc/service or an equivalent, and since port numbers are part of the standards the answer you get by getservbyname(3) aka getservent(3), as of today, is sufficient. It comes from BSD 4.3 or even BSD 4.2 (commit by Kirk McKusick dating 1985-05-15 says "manual page first distributed with 4.2BSD", "+.TH GETSERVENT 3N "9 February 1983", i did not look for code). And, wow!, this is not far from 40 years! And it still serves. Also, HTTP is often accompanied with hypertext aka HTML++, where URLs are a vivid part, so that special needs for port numbers etc. can simply be fed into the machinery via href=3D etc. etc. And i think almost everybody who uses the web ("normal users") for some time "has already seen" port numbers 80, 8080, and increasingly 443 "sometime". But especially the former two. So i do not get your thing above at all. If, with IPv6 and the IoT, the above does no longer SRV, then what is missing to SRV, port etc it can all carry along. o Provide an HSTS-like indication signaling for the duration of the DNS RR TTL that the HTTPS scheme should be used instead of HTTP (see Section 7.6). I mean that can very well be bundled with anything that needs to be implemented anew. But sure, non-S is leaving. ... 1. Issue parallel AAAA/A and SVCB queries for the name HOST. Maybe just another reason why this is not yet implemented widely for such omnipresent things like HTTP. But noone cares no more about increasing packet sizes etc., so "just bundling" and getting more in return without additional roundtrips is surely a nice thing, EDNS is also 20 years or more. Just like OCSP stapling etc., it is just increasingly used (one more thing _i_ have to do), whereas just a few years ago the additional cost of OCSP was the reason it was not implemented in a widely used OSS HTTP server (i use myself). The draft also talks about "anticipating protocols", therefore envisions simply replacing the established SRV with this new RR. You know, i do not like TXT, being explicit is better, but then again the TXT answers are standardized, so i guess that is ok. It surely can serve another defined format for SRV. ... For a different draft, i like the X.509 constraint option for the "MUD" way of RFC 8520, to resolve the "refrigerator" hang of mine. =46rom a user point of view i like the idea that all devices identify themselves "cryptographically save". Even if all light bulbs pass the very same client certificate along. I could imagine they contact my DHCP/DTLS server, and if i ok the certificate further connections are allowed to invoke a dhcpcd hook here, for example. If the constraints are so that really nothing more than an URL can be passed along, initiating "MUD" via DHCP hook i can imagine. Hard to believe the industry wants to flood the world with tiny devices which cannot do D?TLS handshakes aka present at least a X509 certificate. Here i personally would be fine with just using a subjectAltName addition or a defined nsComment content, these are available for a long time. I only wanted to add this. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Wed Aug 5 07:59:17 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 173A83A0A8E for ; Wed, 5 Aug 2020 07:59:17 -0700 (PDT) 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, 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 YDX3SC6aVKxS for ; Wed, 5 Aug 2020 07:59:15 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 AF9243A0A8C for ; Wed, 5 Aug 2020 07:59:15 -0700 (PDT) Received: by sdaoden.eu (Postfix, from userid 1000) id 1B6B116058; Wed, 5 Aug 2020 16:59:14 +0200 (CEST) Date: Wed, 05 Aug 2020 16:59:12 +0200 From: Steffen Nurpmeso To: ADD Mailing list Cc: Steffen Nurpmeso Message-ID: <20200805145912.Nubfs%steffen@sdaoden.eu> In-Reply-To: <20200805143604.h2FWD%steffen@sdaoden.eu> References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> <20200805143604.h2FWD%steffen@sdaoden.eu> Mail-Followup-To: ADD Mailing list , Steffen Nurpmeso User-Agent: s-nail v14.9.19-99-g19301483-dirty OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-schwartz-svcb-dns-00.txt 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 Aug 2020 14:59:17 -0000 P.S.: Steffen Nurpmeso wrote in <20200805143604.h2FWD%steffen@sdaoden.eu>: |[dropping the DNS only lists i am not subscribed to] .. |>From a user point of view i like the idea that all devices I wrote "^From", it was silently and unwantedly converted (from quoted-printable), and (needlessly) mangled via "From_"-quoting along the way. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Wed Aug 5 08:48:48 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 4D8A63A0BC1 for ; Wed, 5 Aug 2020 08:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 DByb2NQQ_TCc for ; Wed, 5 Aug 2020 08:48:44 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 9C47A3A0BBE for ; Wed, 5 Aug 2020 08:48:40 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id 3so6834493wmi.1 for ; Wed, 05 Aug 2020 08:48:40 -0700 (PDT) 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; bh=DIINBPeaE30b629gpI4rBEhY9h91zkltza6Ahk/480I=; b=bDChlUvgg5qIeNg/Kru+vcQXIx8b4D8QJifJS9OACKBamAMff7IUDpkUTnNfn0NQfv aGknb1rSTx4EFHefgzCq1OFMihqLtHh53KSvx/Qea9Oc/tJeGFXhUdMvOjP+YEls62lK TDF8SZmAEdG1KBBqpFRWd4J+E8RTjXAyz8Gp3X/7Ghff/bR53rwg2vx9CrJ0AnHgTtau lx9JSceGVe/N0zzHK8j9KhnoVE80xV7wD72xhj7/Qn7Ry4O6U0m2+Gf0dwBZhg/4yjCs tPs84jn3L4hZGx/pN6cARyB2gke4qLHJ499Pdkl2i68emUqJZjemfkk/qkQR4ivOJ6HN icWg== 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; bh=DIINBPeaE30b629gpI4rBEhY9h91zkltza6Ahk/480I=; b=Ku8HKv8871crnS6boSM89MkjpvCEn0BSkJeQSUoGXMWMUZ9HG37Dm4mKRSlbNAsFZi pr/N0SsywybBeKOo8Xg2fYXjz+Yvya0sYBBQHtD2o63FTv34hfN7Dq9UHhX7s5vQcQ1+ SxVzH0pYhy2alTPwOA21XQzdJblMFmsfJK8aF941icGlYJrzfHthyXUleO8/BDijclYT KKtaPhncmB7zMMJZ0axaSR0vV8pB4PKOP2f0SRqyiwlPqnmM03shPd07slWORAGbRHD7 T6ziDztibIfkn3eqCVdEicCG7cC8cFejalarbhmjQZmHbZYlm+y3FSGcGOoaE6q9OP84 ZQxg== X-Gm-Message-State: AOAM5316hCfoZKG6uDhc+hE0WwIKCw0cuo/SxvmLnKXlyxW15Bm5is6/ CpXl4OM2PqbGVikRs1AzCQE3eHAajwm3lIPWB4m2afMYfoQ= X-Google-Smtp-Source: ABdhPJwktLzaXTHUaXhB6snhj6rm1jnQ7BSSzDfa+uv9ez5RCP1WspiE9YvpjRBXT8QIoEaZ+WSigvRiXlTNkFt0H+o= X-Received: by 2002:a1c:4e17:: with SMTP id g23mr3755509wmh.42.1596642518862; Wed, 05 Aug 2020 08:48:38 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> <20200805143604.h2FWD%steffen@sdaoden.eu> In-Reply-To: <20200805143604.h2FWD%steffen@sdaoden.eu> From: Ben Schwartz Date: Wed, 5 Aug 2020 11:48:27 -0400 Message-ID: To: Ben Schwartz , ADD Mailing list , Steffen Nurpmeso Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000031cba005ac234eae" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-schwartz-svcb-dns-00.txt 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 Aug 2020 15:48:47 -0000 --00000000000031cba005ac234eae Content-Type: multipart/alternative; boundary="0000000000002bf0f405ac234e9f" --0000000000002bf0f405ac234e9f Content-Type: text/plain; charset="UTF-8" Thanks for your comments, Steffen. The primary list for discussing SVCB is DNSOP, so I would encourage you to direct most of your comments there. A few comments below. On Wed, Aug 5, 2020 at 10:36 AM Steffen Nurpmeso wrote: ... > I personally do not see an improvement in introducing yet another > RR in order to support this. I think the need for SVCB is already well-motivated by other use cases, so I see this the other way. Several drafts in ADD have proposed new RR types to convey this kind of information (in addition to those that suggest using SVCB in different ways). Reusing SVCB to convey DNS transport info might reduce the need for additional RR types. ... > Maybe i should look in bind code or > so and test whether it would be harder to return the favoured or > desired set of RR combinations for a RR type or a question for > a specific SRV. Note that SVCB implementation is already under way in BIND (thank you BIND authors!): https://gitlab.isc.org/isc-projects/bind9/-/issues/1132 ... > But even a clause that says "if that RR is > provided HTTPS transport is a MUST" does not justify that for me. > I.e., you could ask for "dnss://" and get A/AAAA for http[123]:// > in combination also. > I don't think using "dnss://" instead of "dns://" makes a significant difference here. Clients still need a way to discover metadata about the server, such as which protocols it offers and how to access them. --0000000000002bf0f405ac234e9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your comments, Steffen.=C2=A0 = The primary list for discussing SVCB is DNSOP, so I would encourage you to = direct most of your comments there.=C2=A0 A few comments below.

On Wed, Aug = 5, 2020 at 10:36 AM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
...
I pers= onally do not see an improvement in introducing yet another
RR in order to support this.

I think the ne= ed for SVCB is already well-motivated by other use cases, so I see this the= other way.=C2=A0 Several drafts in ADD have proposed new RR types to conve= y this kind of information (in addition to those that suggest using SVCB in= different ways).=C2=A0 Reusing SVCB to convey DNS transport info might red= uce the need for additional RR types.

.= ..
Maybe i should lo= ok in bind code or
so and test whether it would be harder to return the favoured or
desired set of RR combinations for a RR type or a question for
a specific SRV.

Note that SVCB implementati= on is already under way in BIND (thank you BIND authors!):=C2=A0https://gitlab.isc= .org/isc-projects/bind9/-/issues/1132
=C2=A0
..= .
But even a clause = that says "if that RR is
provided HTTPS transport is a MUST" does not justify that for me.
I.e., you could ask for "dnss://" and get A/AAAA for http[123]://=
in combination also.

I don't think = using "dnss://" instead of "dns://" makes a significant= difference here.=C2=A0 Clients still need a way to discover metadata about= the server, such as which protocols it offers and how to access them.
--0000000000002bf0f405ac234e9f-- --00000000000031cba005ac234eae Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCDNb1fpF0znciqTEhWpbIlm8qjN7qsmuFveDLANHo8CJTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA4MDUxNTQ4MzlaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAc9jSRqntAX1aI9+r8cygkh7B9n4MEg19p2z73NbHyOU0zVKH77DMeHPryZByvlFGSJflS6kn zsd1Z3rQKMP582t6qWNDdOOwviu5xG9nFIzFgo8NL9lowfWe3bAdb1avrM4zr+puk1YaSCh5aF0t BIDnQTt9F/iRi8m1OLa2lP+0nPE5vHUFu/rtkuyL0SctSaTw5p9UML/81jdqgLAcnVpStbWxXVaI XimbryTTTWgOc8+9g9uqUiRxLw+qOKbsfZuRxy3p4soF7CrYvAu7+CrwXFrekKGoxYXJO9ayqrkJ NxUkm6zN6F7jwiqiDZIOcnarqA1PhrYdXcm2RqKaDw== --00000000000031cba005ac234eae-- From nobody Wed Aug 5 09:36: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 6CB293A0CCD for ; Wed, 5 Aug 2020 09:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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=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 3sAuCamDY-xL for ; Wed, 5 Aug 2020 09:36:53 -0700 (PDT) Received: from mx0b-00176a04.pphosted.com (mx0b-00176a04.pphosted.com [67.231.157.49]) (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 001103A0CC4 for ; Wed, 5 Aug 2020 09:36:52 -0700 (PDT) Received: from pps.filterd (m0193501.ppops.net [127.0.0.1]) by m0193501.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 075GFnd3012113 for ; Wed, 5 Aug 2020 12:36:52 -0400 Received: from usecmgip002.mail.tfayd.com ([50.228.147.34]) by m0193501.ppops.net-00176a04. with ESMTP id 32n81u6mk0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 05 Aug 2020 12:36:51 -0400 IronPort-SDR: EFTXgpPm/CRsN5KZh911g+EGI8pU/nLmJxJppbUc9G9DLIvmCUX6mIudFu71tjuXYOgPdiq4uo yI3HaDFxQuNA== Received: from unknown (HELO ashemwp00006.mail.tfayd.com) ([100.126.24.30]) by USECMGIP002.mail.tfayd.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 05 Aug 2020 12:36:51 -0400 Received: from ashemwp00008.mail.tfayd.com (100.126.24.32) by ashemwp00007.mail.tfayd.com (100.126.24.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5; Wed, 5 Aug 2020 12:36:50 -0400 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (10.56.130.76) by ashemwp00008.mail.tfayd.com (100.126.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5 via Frontend Transport; Wed, 5 Aug 2020 12:36:50 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VXj1WFPUdadQiG+s8mZ4t2+r5sfghJgb3n6R9iEwjRdZh2H7acn0sEpFY4Y0CwQMV2DxpX+3MT9uW7KBmGzBKl5Axzmtc0Nw3KWkVzTXSEmQU8I6BvpNcpDLSxHhXiyMtygZLW/ebDRjl5oLdXUHfVU2cwz4IZj9U6P9q416Qyn2ouMbydPMSSdDzqKEA7Ll3sRSOi1huJ+SakzG8b8u5qA1mOR+cyadTE4Kvpp2+rp2YQWGRRy17wmzKYLKWUUPqq3yXMeSEQzOD0b2G90bpdg9Hpr7Z85+MuFW84cijMAGN6AJeekNzXhOGRewC7eryxHwSJuZLkxxXhQpzKdp5g== 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=yCdqdjCQE1JO0gWtg+lk/qe1AkU/kwmdRfi7z5JQ6q4=; b=bHr1Mep0wMBNMIy3a97BoXCliqQy3K/IkkPGdEtLBH5FZqNsch/9Rk9dg5edsj5RLadEgrpOf5cEY/dlGDHSdCgmcqLJ5ZLtqHiOlbh1WH/sM2kPw9/SKLpjB2GLyzHJZRsVwZVXTLpwPCeXAGRtzVjLpQ+iCqM0s+fSq20J/vggM+RLPYt+Me12GJOSAce5LIxgBwd2rrAA1eugZP5oSn3EJc8FrMPGVPeeEzZ1dsKPDgzUPiwO7sIWXH0ujH8lzlWPjh0ZrZ6kTBF6cPFK209WijrmqqWyDP4vmIDCJPRCGS7qPkxTdU4c1lXdgVqfNxgVZ4UQk5qwA/JPS04yIA== 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=yCdqdjCQE1JO0gWtg+lk/qe1AkU/kwmdRfi7z5JQ6q4=; b=tYlq5efXijb2IBhxyX+uWmFgIOEc0KweudAJ+c/L+A6zB1vtG8/hjhdocMfOUFy8BQOaYgsw9KCqYQ2D9l0lFiCCSjLdHVu7sUVEp7CrFSISNX3xf+UpQgDvhGZEQCBzdwmHsG2EKRNzH+/8GP08zEyqTfSSFtQdwvS9QU34YOg= Received: from BYAPR14MB3094.namprd14.prod.outlook.com (2603:10b6:a03:14d::30) by BY5PR14MB3495.namprd14.prod.outlook.com (2603:10b6:a03:1f1::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Wed, 5 Aug 2020 16:36:48 +0000 Received: from BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::e074:901e:d085:be5c]) by BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::e074:901e:d085:be5c%7]) with mapi id 15.20.3239.022; Wed, 5 Aug 2020 16:36:47 +0000 From: "Deen, Glenn (NBCUniversal)" To: ADD Mailing list Thread-Topic: IETF 108 Meeting Survey Thread-Index: AQHWa0achv2MPVtvWkuYrHe++XcYIw== Date: Wed, 5 Aug 2020 16:36:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nbcuni.com; x-originating-ip: [2605:e000:141b:121:dca5:32cf:14bd:6e4d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a818a644-45e6-4b88-5038-08d8395dbf62 x-ms-traffictypediagnostic: BY5PR14MB3495: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: o4BXt/gGtsLBCXrfrx3Fvf4XOwzoXQtHxHq2DMOslrLQVdr0H6olkL4KFlLGcMiuOZTaC+k+C0tUa1NGjA8UK7Ly6IgGCFcpJlMXsKRL6BBrVeUcUL4htmq0p01oiv5pol3EITRme2sWlnKq3ePcNbZs0tph9ekadr0M/2YPgfbz1fzrcW2RiR6W6c+k1zW7xj0XBJlPs6d1S2FalwAGx6qKZ1lTmLs7MEe8tiEFNop5GClmCejQ8wXypwTDpja+bVmef8pFRD/TWKTbvzKC2bZBEuYobMrFiccXfuqFA7et18UR3eOjMk3l1b2SQbzXMV5lz9TMrwC2Otllg8EP6ANkoLeYw9YVHh5UakerGuJ8Mv6t1xFSOI4HALgAS/W3isIf5SnFdsb/a02Z1gCDl8PEszbaLNmX5cm3jTr7L5zaIUvvQ/Mctf17DGUCPLeOP1bJU52XVg8Kb7qS7yizlw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR14MB3094.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(376002)(346002)(39860400002)(396003)(316002)(6916009)(86362001)(2616005)(66476007)(66946007)(66556008)(66446008)(64756008)(76116006)(71200400001)(6486002)(8936002)(8676002)(5660300002)(186003)(478600001)(2906002)(7116003)(6506007)(83380400001)(36756003)(166002)(33656002)(6512007)(966005)(4744005)(223384002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: vUmvpzZl2qNKYY737Dkpw/x6oACZMIJ5j4ggIFwZ10eYBBrPc/wnEBZ4m2M1+j0Ko5FATD6ySeYka6+CCiBaOUFHRWH2dti+LkS0QiIideg3hZcYtR4Ct3y+pB8ZYU0pwTEdJUl0AILnZVXX2ygLdoAwISo0saJb3gl6xgIzfzyvJcisi0DwGj+rehrg/B5zuvEaOa2R2iRxtkYbO7ykLC4N4PR68bei+uh/uMeq//0Ci1cm+l9aaARGvdw6ApXR3DWpwkZNnF7UVKkhEBNU+xR743OqyeU+b4TUWaRo3fWBAbrCdCn5wj2ZMBAqd9DG1MmBzhZigGrFUiA/+HaYS/3oh78LXGzzaz7+XU4UW/3Z2Maw1NAFVtFHnILeZGLF0+txDGjntmfDIGDCNHl7wdrXxV22BBAM1LAvTcLAWDzzWh0rCiTSNvs2dhfDPvgbzsBTGEqvrOegEwXT/r/Vkr8c99C3yXdeH+m/cbop7+ia5xBwqHuvwMTxGlU3FzAmvIcmsVjXvM57ooq5rsvxXlx9fYzoHDKYYlLjyWp0EPtSLG5IG/6J6xQKGW2fN1botVbn9J2Lh74WZx5ZdOAKlVBqIALGj9Dfl4lZUJ/irtAXwQ07NuFrAZRe+LfA9pc1/w8nbQyDtDEB254/5W11tT03f6DkB7KUkRubLWLI1Vsr0r7baKwqopsK6z0w5a8DFfSG5PQqP5phQeM7op0vlg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DB508679E0024D48BEABEFA912F5CD3Dnbcunicom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR14MB3094.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a818a644-45e6-4b88-5038-08d8395dbf62 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 16:36:47.7089 (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: 4Q83tpz3P0m+B08M4j2Wa6lTV3mbPjjchndgClsbQ2FzH3YcpYpwMfuX+acQbat/vNRbOcuFdSV7n9Jao+iLlA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR14MB3495 X-OriginatorOrg: nbcuni.com X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-05_13:2020-08-03, 2020-08-05 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 malwarescore=0 mlxscore=0 phishscore=0 mlxlogscore=999 clxscore=1015 impostorscore=0 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008050132 Archived-At: Subject: [Add] IETF 108 Meeting Survey 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 Aug 2020 16:36:54 -0000 --_000_DB508679E0024D48BEABEFA912F5CD3Dnbcunicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHRha2UgYSBtaW51dGUgdG8gZmlsbCBvdXQgdGhlIElFVEYgMTA4IG1lZXRpbmcgc3Vy dmV5Lg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogSUVURiBFeGVjdXRpdmUg RGlyZWN0b3IgPGV4ZWMtZGlyZWN0b3JAaWV0Zi5vcmc8bWFpbHRvOmV4ZWMtZGlyZWN0b3JAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogWzEwOGFsbF0gRmluYWwgcmVtaW5kZXI6IElFVEYgMTA4IG1lZXRp bmcgc3VydmV5DQpEYXRlOiBBdWd1c3QgNSwgMjAyMCBhdCA2OjMwOjE2IEFNIEVEVA0KVG86IDEw OGFsbEBpZXRmLm9yZzxtYWlsdG86MTA4YWxsQGlldGYub3JnPg0KDQoNClRoYW5rIHlvdSB2ZXJ5 IG11Y2ggdG8gdGhlIH4yMzAgcGVvcGxlIHdobyBoYXZlIGZpbGxlZCBpbiB0aGUgSUVURiAxMDgg bWVldGluZyBzdXJ2ZXkgYXMgdGhpcyBkYXRhIGlzIGNydWNpYWwgdG8gaGVscGluZyB1cyBwbGFu IGZ1dHVyZSBtZWV0aW5ncy4gIFdlIGNvdWxkIHN0aWxsIHVzZSBhbm90aGVyIDcwIG9yIHNvIHJl c3BvbnNlcyBhbmQgc28gdGhpcyBpcyBhIGZpbmFsIHJlbWluZGVyIHRvIHBsZWFzZSBoZWxwIHVz IGJ5IHRha2luZyBhIGZldyBtaW51dGVzIHRvIGNvbXBsZXRlIHRoZSBzdXJ2ZXk6DQoNCmh0dHBz Oi8vd3d3LnN1cnZleW1vbmtleS5jb20vci9UM1NMN0pGPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20v djMvX19odHRwczovd3d3LnN1cnZleW1vbmtleS5jb20vci9UM1NMN0pGX187ISFQSVplZVc1d3Nj eW5SUSE4bTdzV0FybUUtclR3NmlyZzRXWndKekJhLWJZb2xJOTNxS0JySTNvQkhLN29XWXlHblA0 ZVE2U0xrVkp6LVNPJD4NCg0KVGhhbmtzIGluIGFkdmFuY2UNCg0KLS0NCkpheSBEYWxleQ0KSUVU RiBFeGVjdXRpdmUgRGlyZWN0b3INCmV4ZWMtZGlyZWN0b3JAaWV0Zi5vcmc8bWFpbHRvOmV4ZWMt ZGlyZWN0b3JAaWV0Zi5vcmc+DQoNCg== --_000_DB508679E0024D48BEABEFA912F5CD3Dnbcunicom_ Content-Type: text/html; charset="utf-8" Content-ID: <867FF2F16BABD147826077AB9DF36A6E@namprd14.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIgMCA1IDMgMCAwIDAgMiAwIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2 M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpIZWx2ZXRpY2E7 DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpu b3JtYWw7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBw bGUtY29udmVydGVkLXNwYWNlO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDst d2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5QbGVhc2UgdGFrZSBhIG1p bnV0ZSB0byBmaWxsIG91dCB0aGUgSUVURiAxMDggbWVldGluZyBzdXJ2ZXkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNr Ij5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFu ZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjpibGFjayI+SUVURiBF eGVjdXRpdmUgRGlyZWN0b3IgJmx0OzxhIGhyZWY9Im1haWx0bzpleGVjLWRpcmVjdG9yQGlldGYu b3JnIiB0aXRsZT0ibWFpbHRvOmV4ZWMtZGlyZWN0b3JAaWV0Zi5vcmciPmV4ZWMtZGlyZWN0b3JA aWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOmJsYWNrIj5TdWJqZWN0OjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bMTA4YWxsXSBGaW5hbCByZW1p bmRlcjogSUVURiAxMDggbWVldGluZyBzdXJ2ZXk8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6YmxhY2siPkRh dGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7 O2NvbG9yOmJsYWNrIj5BdWd1c3QgNSwgMjAyMCBhdCA2OjMwOjE2IEFNIEVEVDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2Nv bG9yOmJsYWNrIj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh IE5ldWUmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzoxMDhhbGxAaWV0Zi5vcmci PjEwOGFsbEBpZXRmLm9yZzwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29s b3I6YmxhY2siPlRoYW5rIHlvdSB2ZXJ5IG11Y2ggdG8gdGhlIH4yMzAgcGVvcGxlIHdobyBoYXZl IGZpbGxlZCBpbiB0aGUgSUVURiAxMDggbWVldGluZyBzdXJ2ZXkgYXMgdGhpcyBkYXRhIGlzIGNy dWNpYWwgdG8gaGVscGluZyB1cyBwbGFuIGZ1dHVyZSBtZWV0aW5ncy4gJm5ic3A7V2UgY291bGQg c3RpbGwgdXNlIGFub3RoZXINCiA3MCBvciBzbyByZXNwb25zZXMgYW5kIHNvIHRoaXMgaXMgYSBm aW5hbCByZW1pbmRlciB0byBwbGVhc2UgaGVscCB1cyBieSB0YWtpbmcgYSBmZXcgbWludXRlcyB0 byBjb21wbGV0ZSB0aGUgc3VydmV5Ojxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwczovd3d3LnN1cnZleW1vbmtleS5jb20vci9UM1NMN0pGX187ISFQ SVplZVc1d3NjeW5SUSE4bTdzV0FybUUtclR3NmlyZzRXWndKekJhLWJZb2xJOTNxS0JySTNvQkhL N29XWXlHblA0ZVE2U0xrVkp6LVNPJCIgdGl0bGU9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovL3d3dy5zdXJ2ZXltb25rZXkuY29tL3IvVDNTTDdKRl9fOyEhUElaZWVXNXdzY3lu UlEhOG03c1dBcm1FLXJUdzZpcmc0V1p3SnpCYS1iWW9sSTkzcUtCckkzb0JISzdvV1l5R25QNGVR NlNMa1ZKei1TTyQiPmh0dHBzOi8vd3d3LnN1cnZleW1vbmtleS5jb20vci9UM1NMN0pGPC9hPjxi cj4NCjxicj4NClRoYW5rcyBpbiBhZHZhbmNlPGJyPg0KPGJyPg0KLS08c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KSmF5IERhbGV5PGJyPg0KSUVU RiBFeGVjdXRpdmUgRGlyZWN0b3I8YnI+DQo8YSBocmVmPSJtYWlsdG86ZXhlYy1kaXJlY3RvckBp ZXRmLm9yZyI+ZXhlYy1kaXJlY3RvckBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_DB508679E0024D48BEABEFA912F5CD3Dnbcunicom_-- From nobody Wed Aug 5 10:38: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 3E2D63A0E19 for ; Wed, 5 Aug 2020 10:38:57 -0700 (PDT) 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 0gRsHvmQlJQ4 for ; Wed, 5 Aug 2020 10:38:56 -0700 (PDT) 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 7C5F83A0E63 for ; Wed, 5 Aug 2020 10:38:55 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id b25so34297161qto.2 for ; Wed, 05 Aug 2020 10:38:55 -0700 (PDT) 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=hRaj3CJJV1E2rmfk49AeYbPvTa8ogfNHNZ/xSE2A7Qs=; b=XCQ11sLAQI2ItrHr8yHlLe3UFfzI84V85vj43X9RllAc9XvoIj3CfopYV/TvZJo1j3 CZQDuO6z0kIAF88/z21caNFqFtxh4kTZR48Q/2w5CdW2g5qCBgP7kb279wDftqXGjNx3 InymokXPSY/5EvQJYbcIjw7acG4D8RKNBcBO9xGm8cIi8ddC8pnaMTnemC5Rmfd4sNd+ DDXVKUDJs1jX1Q5fyejy965kF2fL0tn7GQ6rusdDTuATjaE52cyFTZb0TjVmXwC6iHgj IIwp+Y+47VeG52nqK4OHaMYg+U84GQwjvZjDW5HofFVDyRq5I2q6VJ3woGO5Brpx1EMy IVGA== 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=hRaj3CJJV1E2rmfk49AeYbPvTa8ogfNHNZ/xSE2A7Qs=; b=FpTH7KKIqciN9Dc47RDaCmpgOhuQPnYZ4CP3A1gIfJnq5qewrGMc2VP25QOmY4aWMa 57+eoViAAG2z+gfG6zLvMSkeKa6aBZKJ7lFukos59tro1L7aw3JkSbe5VBxPe5DnxTVn YarSeHO2vl0nR1iU5CHLBb7cwjpsCwgfj/5MdKTiwcs/CkisTLJoPmQ5y0MeRqgpSxBd Xd+8Y3qHiYrbyTh/UVjDCtlbS1uOJGNoyyA6bgDyLsNKUxD75IaGAypUz3ebNtT/PCTC nMzcglIplxeP+jxJ3Z3Ygs7HWkYiiKJA7DWqCZ3Sot/m2fCbcH/5+5gC02eUamgfL+Yk sIBA== X-Gm-Message-State: AOAM532vrS+kLTzo6GoXjTTtmSaNFm4scMKGmABRxVekvwErh1iNTs3R SWhRETZNPdDMgzqsbY4wU0ubydp3GueFqHlAlyi/RLHe X-Google-Smtp-Source: ABdhPJzeKAiTIgkAM7bdF3zBpIt0VqtzED8XowT3/0FD9vCciWyhAkAIdTDP2X93YbVxrdfVy1qFXme6getIowA+mb8= X-Received: by 2002:ac8:4d94:: with SMTP id a20mr4491213qtw.169.1596649134456; Wed, 05 Aug 2020 10:38:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Chris Box (BT)" Date: Wed, 5 Aug 2020 18:38:43 +0100 Message-ID: To: Wes Hardaker Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000007d881e05ac24d874" Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 17:38:57 -0000 --0000000000007d881e05ac24d874 Content-Type: text/plain; charset="UTF-8" Wes, I'm not especially in favour of pursuing "discover whether using a resolver X is acceptable". I think it would be better to let the client try. If it succeeds, great. If not (because the network is denying it), we should allow the network to explain why it is not succeeding. This is simply a usability improvement. Chris On Tue, 4 Aug 2020 at 23:23, Wes Hardaker wrote: > "Chris Box (BT)" writes: > > > What a good start to the thread. You've managed to turn my uncertain > grouping into > > something that looks a *lot* cleaner. > > > > > > So perhaps we only need one requirements draft, containing use cases > broken down > > like this. > > I suspect there is another case that most want to explicitly not pursue: > > Given a network, discover whether its use is acceptable according to the > its operators, the ISP you're connecting under, and laws within the region. > Functionally, use-application-dns.net is a mechanism for detecting ISP > policy, eg. > > -- > Wes Hardaker > USC/ISI > --0000000000007d881e05ac24d874 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Wes,


I'm not especially in favour= of pursuing "discover whether using a resolver X is acceptable".


I think it would be better to let the client try. If it succeeds, great. If not (because the network is denying it), we should allow the network to explain why it is not succeeding. This is simpl= y a usability improvement.


Chris


= On Tue, 4 Aug 2020 at 23:23, Wes Hardaker <wjhns1@hardakers.net> wrote:
"Chris Box (BT)" <chris.box.ietf@gmail.com= > writes:

> What a good start to the thread. You've managed to turn my uncerta= in grouping into
> something that looks a *lot* cleaner.


>
> So perhaps we only need one requirements draft, containing use cases b= roken down
> like this.

I suspect there is another case that most want to explicitly not pursue:
Given a network, discover whether its use is acceptable according to the its operators, the ISP you're connecting under, and laws within the reg= ion.
Functionally, use-application-dns.net is a mechanism for detecting= ISP
policy, eg.

--
Wes Hardaker
USC/ISI
--0000000000007d881e05ac24d874-- From nobody Wed Aug 5 10:42: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 4E6283A0EFE for ; Wed, 5 Aug 2020 10:42:01 -0700 (PDT) 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 lzLvOWkY407l for ; Wed, 5 Aug 2020 10:41:59 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 944893A0EFA for ; Wed, 5 Aug 2020 10:41:59 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id g26so42503951qka.3 for ; Wed, 05 Aug 2020 10:41:59 -0700 (PDT) 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=73JC8sQPU7OJxSnUzMBMJZXrGyYLWNFKHTI17r/ZBV4=; b=AaV8olTQecuryqxBeBqe/jV54d3iOSX2/wquZaFS7IcqE6mqLsNLcuErFRjsajR/NT RwUZv1L1QBockzEuABZqt7pS34MSbPdUjj9992Nbai4l2y1zyryjSEnVCBCrGAFJo28J C1l3sigarD1ywXU82Xiuerq/J4WzSEwqoOnzqyRUwx3gXoZkkQqqSIgwct5dppBo+fYp dfpAcUmqIp5SAG0c66kaOpEXWeWN7qjiq0WJnKsB2rKXH1H2j0ovpXpqG0tcnlInQyjc WryC0TtZp8sc1EoWoxd+9svFYjktVAJdg8jcgm9aJ/RgXi5ce8vxn2OA7RaAdPNXnSXQ zlzA== 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=73JC8sQPU7OJxSnUzMBMJZXrGyYLWNFKHTI17r/ZBV4=; b=Mba6DhS+Te0wgpUG5LIiVqNEUYB54UCCGUJDPREU/BjEUY8ZHxiwvbyIVl9WT8ZK1o lDlAm/zw3RggFT12Ybps+zv3kK1RIC5TJuFhZBY1ELxSjdVy6ixJyM1G+3FpLblk6RsC sRACp+jegDSjSxy27QXdfp+Hv1zTZ1xERqZc5vBgVQAL798Prz1sMG6Nctl9glwaSZ5g U0qDPHkOamncNpPrgT+vtjbFa2dF+JnP9RNlTqgNa7jfonEBQqRNcT07eYR0vuajvYTF XpCwx00tyenD/0Cy4XB9pnXNJ0lgnqmZemp7FbPc+193ENBY0jbs11yAxtkun5w7aYmE cA3w== X-Gm-Message-State: AOAM533aTUyzQjLv7Kxmz+o7g6toSPasUns9cmuIabeSkX9u80TEbk0X QpsIJ0opxAnKXSfzR/V3etSxaiLY1tgzhi3F4mKMyQxP X-Google-Smtp-Source: ABdhPJz8+jw3YPr0MDngW7Vk7lTPTqEoF11J8a1uDFWrnkIyH2QEaFOMTpvfgedPy5dcUtHo0nqpE7+SgU8wKmM9AzI= X-Received: by 2002:a05:620a:142:: with SMTP id e2mr4471744qkn.418.1596649318612; Wed, 05 Aug 2020 10:41:58 -0700 (PDT) MIME-Version: 1.0 References: <356083f6-0a16-4c05-926b-e13e5a195a3c@www.fastmail.com> In-Reply-To: <356083f6-0a16-4c05-926b-e13e5a195a3c@www.fastmail.com> From: "Chris Box (BT)" Date: Wed, 5 Aug 2020 18:41:47 +0100 Message-ID: To: Martin Thomson Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000077839b05ac24e31e" Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 17:42:01 -0000 --00000000000077839b05ac24e31e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Martin, Interesting points. Credit for the taxonomy should go to Tommy Pauly, with revisions by Neil. I agree that it is unnecessary to bake in an assumption that DHCP/RA/PPP/PCO must always return an IP address of a resolver before the process of 1a can be started. We could instead enhance DHCP/RA/PPP to return some richer set of data, such as the inclusion of an Explicit PvD in RA described by draft-pauly-add-resolver-discovery. Note that PCO (Protocol Configuration Options) is a 3GPP spec and so this working group cannot *directly* alter that. Could we generalise the requirement by using this wording, or similar? 1. Given information from the attached networks, and resolvers known from configuration, discover one or more associated/equivalent encrypted resolvers 1a: Discover encrypted resolvers that are equivalent to the resolver given out by DHCP/RA/PPP/PCO, regardless of whether this is a classic IP address or a richer set of information. I think this allows for 1aa and 1ab, and =CE=B1 and =CE=B2. In my view =CE= =B2 will always be needed as long as there are edge devices that only support issuing a Do53 IP address. Chris On Wed, 5 Aug 2020 at 04:37, Martin Thomson wrote: > Hi Chris, > > I think that this is a helpful simplification. I have a question on the > first arm of your taxonomy below. This is probably just tactical, but it > would be good to clarify. > > On Wed, Aug 5, 2020, at 03:47, Chris Box (BT) wrote: > > So perhaps we only need one requirements draft, containing use cases > > broken down like this. > > > > 1. Given a known resolver, discover one or more associated/equivalent > > encrypted resolvers > > Do we necessarily have to have knowledge of a resolver before starting > down this path? I say that because 1a ultimately involves the network > saying something about the resolver and you could do this one of two ways= : > > i) The network says "here is a resolver" and then you define a mechanism > to go from that information - which is probably just an IP address - to > encrypted resolver coordinates. > > ii) The network says "here are the coordinates for a resolver that > supports DoE". > > I can see how you might want the former if your view is that you want to > provide an upgrade path where the resolver is configured via unspecified > means (your 1b or 1c), but I don't think that is the dominant case. We > heard that >90% of people don't touch defaults, so it seems to me that > there are two avenues for investigation, which conveniently correspond to > your 1aa/1ab distinction: > > =CE=B1) enhance the mechanisms that people use to discover a resolver (DH= CP, > RA, PPP, whatever) > > =CE=B2) find a way to talk to the resolver and get its opinion > > You can imagine that a client with no opinion might do =CE=B1 then =CE=B2= . In those > deployments that include a forwarder as part of a gateway/router this > offers that device an opportunity to offer its opinion if it has been > updated. Absent that upgrade, there will be no DoE information presented= , > so clients might then try asking the resolver (using resolver-info.arpa a= nd > SVCB or whatever happens to be fashionable when we eventually decide). > > A client with an opinion about a resolver, but no information about DoE > might just do =CE=B2. > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000077839b05ac24e31e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Martin,

=C2=A0

Interesting poin= ts. Credit for the taxonomy should go to Tommy Pauly, with revisions by Neil.

=C2=A0

I agree that it is unnecessary to bake in an assumption that DHCP/RA/PPP/PCO must always return an IP address of a resolver before the process of 1a can be started. We could instead enhance DHCP/RA/PPP to return some richer set of data, such as the inclusion of an Explicit PvD in RA described by draft-pauly-add-resolver-discovery. Note that PCO (Protocol Configuration Options) is a 3GPP spec and so this working group cannot directly al= ter that.

=C2=A0

Could we general= ise the requirement by using this wording, or similar?

=C2=A0

1. = Given information from the attached networks, and resolvers known from configuration, discove= r one or more associated/equivalent encrypted resolvers

1a: Discover encrypted resolvers that are equivalent to the resolver given out = by DHCP/RA/PPP/PCO, regardless of whether this is a classic IP address or a ri= cher set of information.

=C2=A0

I think this all= ows for 1aa and 1ab, and =CE=B1 and =CE=B2. In my view =CE=B2 will always be needed as long as there are edge devices that only support issuin= g a Do53 IP address.


Chri= s



= On Wed, 5 Aug 2020 at 04:37, Martin Thomson <mt@lowentropy.net> wrote:
Hi Chris,

I think that this is a helpful simplification.=C2=A0 I have a question on t= he first arm of your taxonomy below.=C2=A0 This is probably just tactical, = but it would be good to clarify.

On Wed, Aug 5, 2020, at 03:47, Chris Box (BT) wrote:
> So perhaps we only need one requirements draft, containing use cases <= br> > broken down like this.
>
> 1. Given a known resolver, discover one or more associated/equivalent =
> encrypted resolvers

Do we necessarily have to have knowledge of a resolver before starting down= this path?=C2=A0 I say that because 1a ultimately involves the network say= ing something about the resolver and you could do this one of two ways:

i) The network says "here is a resolver" and then you define a me= chanism to go from that information - which is probably just an IP address = - to encrypted resolver coordinates.

ii) The network says "here are the coordinates for a resolver that sup= ports DoE".

I can see how you might want the former if your view is that you want to pr= ovide an upgrade path where the resolver is configured via unspecified mean= s (your 1b or 1c), but I don't think that is the dominant case.=C2=A0 W= e heard that >90% of people don't touch defaults, so it seems to me = that there are two avenues for investigation, which conveniently correspond= to your 1aa/1ab distinction:

=CE=B1) enhance the mechanisms that people use to discover a resolver (DHCP= , RA, PPP, whatever)

=CE=B2) find a way to talk to the resolver and get its opinion

You can imagine that a client with no opinion might do =CE=B1 then =CE=B2.= =C2=A0 In those deployments that include a forwarder as part of a gateway/r= outer this offers that device an opportunity to offer its opinion if it has= been updated.=C2=A0 Absent that upgrade, there will be no DoE information = presented, so clients might then try asking the resolver (using resolver-in= fo.arpa and SVCB or whatever happens to be fashionable when we eventually d= ecide).

A client with an opinion about a resolver, but no information about DoE mig= ht just do =CE=B2.

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000077839b05ac24e31e-- From nobody Wed Aug 5 10:46: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 B96693A0F20 for ; Wed, 5 Aug 2020 10:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.808 X-Spam-Level: X-Spam-Status: No, score=-8.808 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=PVqTDZ5Q; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=u36EB5fR 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 DT6MmkgwZI2L for ; Wed, 5 Aug 2020 10:45:58 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6390E3A0F1E for ; Wed, 5 Aug 2020 10:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8116; q=dns/txt; s=iport; t=1596649558; x=1597859158; h=from:to:subject:date:message-id:mime-version; bh=85/Mrk07pSXJ5IBZJa04a0zqqjTSALggm7B0iageVLs=; b=PVqTDZ5QxjfF+2zHT8Cq4oO13aUdmjKhVV+mh0zNWypkWwy7dvwl2VhZ SPxB3HiCsuzEzalbvbhtRWMy73sALRXBDd6PEBN+3wnl6SMUuLkbNUPT9 eSp2tPjGs1ii/DqjHHqwVnowNd5Z12JfcRG7UC4o8W+qeAI/7HMTCCDbx g=; X-Files: smime.p7s : 3980 IronPort-PHdr: =?us-ascii?q?9a23=3AL33NBxWXHSmGk97eMpO2EkBdGlfV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyBufNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFzfvnP06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlCgB97ypf/5ldJa1gglOBIy9RB28?= =?us-ascii?q?rLS8sCodxA5Uqh0mEU4RsglMDVQQHAQEBCQMBAScGAgQBAYRMAjGBdwIkNwY?= =?us-ascii?q?OAgMBAQsBAQUBAQECAQYEbYVcAQuGChsTAQE4EQEMRDAmAQQbBgwIgwWBfk0?= =?us-ascii?q?DHw8BDqkIAoE5iGF0gTSDAQEBBYURGIIHBwMGgTiBU4Edih4agUE/gVSFZwE?= =?us-ascii?q?DgV8rgx2CLZsYmwQKgmKEOIJbkxmffiGFMIxYnyoCBAIEBQIOAQEFgWkkgVd?= =?us-ascii?q?wFYMkUBcCDZIQilZ0TAl8jhkBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,438,1589241600"; d="p7s'?scan'208,217";a="798050327" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Aug 2020 17:45:56 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 075Hju17000844 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Aug 2020 17:45:56 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Aug 2020 12:45:56 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Aug 2020 13:45:55 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 5 Aug 2020 13:45:55 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c3PELPXppWp9bBBga2r6rIXPAnSuEmkEdZeV2AOYjHHLlnTG3oiegOVujJMLJBkoZ2RCL1dz+ZVoMUpvfAjWSyVPOnH66j/siLIkBbLGi/QBn0QVaiFqn9tLDxZv73ldlRkVDnE6NHiI/NpEJbPPuGFnz7FyIqQbB+lhfqRCdkWPXB49a1HG736JBfohHkyr8Y9YCFhO2asEgzeYQUnKFEOB2nflOUqTs6t5LVEzVF60XTLaxurogA8nlOui1DyAmBJFkRvYMcE7jKcqzadpjTY7px7kypYJXiTrMomAkoJ029+yECo38SLqawROPGQmum+juPakOcqicvOsU5OqJA== 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=TCJlXahbtVaTR48h6Gut4jm2MiGD9gNBn7um+8pLoY0=; b=NXkPiez4+kFO8jtx/cHzPNVdk/aL9h/rCqak+/5g0qhoV3tHW03pPLWx/+9A5ESxUmb0/rvviHWeav2JnVeeL4MInenEye7317UoWYu912F9Zbq5YKVy3nL1D+FnXtfGzvJ0IXhzAtgONh0TKYkKCwyJDFvBSH7gBqW9Bosr7zZQQLxdc6ofuVbN/jCEyDUKu5WFbaawOEshGuZ5HHcpu+EDYtFcIRdNslZ/ANmgdL5DUGxNCzpvqASMX1R2IlB9InoLqM1/sAIyY0WiU2lqW8uxYhQ8TBmSOw6iTkYCPw2oAOzeOzvI9oepelZzlCh9xzre15rXGgJijfQ0qPEOnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TCJlXahbtVaTR48h6Gut4jm2MiGD9gNBn7um+8pLoY0=; b=u36EB5fRoAuaEkhy6CBQXAAzCvY/apciEGkFLs+JoCW9AAkMp+dyic5wPtykFwZZYItLGuiWhwejSwJMHgFZp4JprD4P/Bf2tWmO2uKZ8kKGf5G1hBQTwa/+N4VIHT+nhn4V0mLTbN7//7yEKoMnAVlobYjD6TzS5D3JzGWjfr4= Received: from MN2PR11MB4760.namprd11.prod.outlook.com (2603:10b6:208:266::22) by BL0PR11MB2913.namprd11.prod.outlook.com (2603:10b6:208:79::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.21; Wed, 5 Aug 2020 17:45:53 +0000 Received: from MN2PR11MB4760.namprd11.prod.outlook.com ([fe80::cb0:4953:d19f:b3de]) by MN2PR11MB4760.namprd11.prod.outlook.com ([fe80::cb0:4953:d19f:b3de%2]) with mapi id 15.20.3239.022; Wed, 5 Aug 2020 17:45:53 +0000 From: "Vinny Parla (vparla)" To: "add@ietf.org" Thread-Topic: DoH - exfiltration in the news... Thread-Index: AdZrUD/inH7lPsVhSvOVSbCpUuylKg== Date: Wed, 5 Aug 2020 17:45:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 16179562-64f5-4dfd-7f05-08d8396766a6 x-ms-traffictypediagnostic: BL0PR11MB2913: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3044; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xLWHtEVe2C/EtBo13BZkgnmcTQxPFsIBR2y3FAxy/1S9f7VWYAVSIqHwBI51cDoEIeWg0+M4o6vB+zR1HRDSHc9jgil1QvnHIm8rYDpfOPGv8K/XHuVYoEFFKYM0ipnOrzAXAzqhUymiFLknxcqYvZ0PdVJLPU7lHpIF6LjNNZlfct/ExkssSHhrZLjEkWMixgiumMY2jL3WMVo+eceMaa1RJmZOK75Ev9HvY58Pnp0AIFFkW0q5ogDI+SUMd1XMJ/uLH2XGNd8tdnMxGLjj4JJfMo2dl9sADWDPtP3+HxF2oDFzO/Y6eXXKIxklL+3MK0R0+XaNFVszFCu9LKoRzPyFw3QbPnavLoQtLc7r/HJlcqoc9h4IJCKB3zsPTxH1AyESXbSr/WA5heFGYFlYIw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4760.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(346002)(376002)(366004)(39860400002)(33656002)(2906002)(66446008)(71200400001)(9686003)(66616009)(66556008)(76116006)(186003)(64756008)(26005)(55016002)(66476007)(99936003)(8936002)(66946007)(966005)(86362001)(558084003)(8676002)(52536014)(6506007)(478600001)(7696005)(6916009)(5660300002)(166002)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 1IvSTG2jrkF2tkF//xeq/DN//TTQTDUy7b9S9ikX+VCXJ4HI82G0toqX0l1KCzRb+j4aqggCWdFUaXEf5Ov62Ji35JL3pcFTsxL93SrlZxDhozzB1/4KR6vxLhbK8BmEJlqVD1GhKKyCldDEDSML50iLTREW9L0IfGfwMbN6V/9dZXvojNW23J5sx6iTObdDv9BAxSM+NroTH2QjljWudFNFntfwxnLztc9BG8YD/d84SRFsamoFHVm0KIrlUp5Ivbk43Z33aye0E/fM7U9ScvwoCIwo9nnN6PA1IWzh5KF3b0ZGquxm6kRUmrSoYnX3NA79hfGOBQnW/a84q0HHN2rL6DCDQvYjTAWSTUplq7bSIm01jXT9t7V6Rw38N/6Qq92UJx4WmIBMw5dKDp2gjDxk/7L0ggBcbd4pdM4/qgILIqkBwP3dbeg+MB9btnpmHZEPjQlGUKTm+GWQLna78JmqtFM8GL5Nbb1zwapFFgaTritqaV8eeMvkuIhX0lvvrQXFeqowyPz/wz840xoNFDA3Tp3H9MP8VxkcXfKahoqv/7cFk9RPzEI76ZvpphHj22oeDAncejpyu/BnuMrFoAp/PMp5Ac1xOsp9GOTXDZmoYSm0l1o7J4waRDDy/a5vQjwqv3uuEm0Y1Oi3FLS6fg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001A_01D66B2E.BBAA82F0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4760.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 16179562-64f5-4dfd-7f05-08d8396766a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 17:45:53.8541 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: q49imybZ7kZYWLpB0uzncAUrvSQUW88l5Z4/nvuIjOi4MeFxMbdzCELeuUZDZ+ZWjgcjl8kpoG0BnFcfBYEIZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2913 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: [Add] DoH - exfiltration in the news... 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 Aug 2020 17:46:00 -0000 ------=_NextPart_000_001A_01D66B2E.BBAA82F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001B_01D66B2E.BBAA82F0" ------=_NextPart_001_001B_01D66B2E.BBAA82F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit https://www.zdnet.com/article/iranian-hacker-group-becomes-first-known-apt-t o-weaponize-dns-over-https-doh/ ------=_NextPart_001_001B_01D66B2E.BBAA82F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

https://www.zdnet.com/article= /iranian-hacker-group-becomes-first-known-apt-to-weaponize-dns-over-https= -doh/

 

------=_NextPart_001_001B_01D66B2E.BBAA82F0-- ------=_NextPart_000_001A_01D66B2E.BBAA82F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXjCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBKEwggOJoAMCAQICCgGGGmG8CetC JFAwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTIwMDYwOTE4MTEzOFoXDTIyMDYwOTE4MjEzOFowgZYxHTAbBgNVBAMTFFZpbm55 IFBhcmxhICh2cGFybGEpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVz MRMwEQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHzAdBgkqhkiG9w0B CQEMEHZwYXJsYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg5zG6 WUz2eLCtkokcmka2wwjH6DXR8dfR2VqJ3szmqqmiZLHtOZQ7/3+/ztkZk0iM3yQQc2l9KsQ2jzHU rkOZpqMpYCv43rxL2uAM0gQfpIxWGoHN5L3kW7gVpXuPmgGgF6TpMI9vytRh1gl4SHJD8f9QTvTU JynVycwV0KCQfjrJ77AGHX+7+Jwt7vkY64UtJmM7gCoJj7CU7eO+PAJc2qAJMaljtK4XI6InXFPB 7meUpm8k1TBtUuOpe25WYdUcbeipNtqjTFDtYNtXSXwHn1JRWr14CMWI2iTUu69D6M5p8KxXMStS F197vWn7QrFJ1PaK366O/LgsHumVQxAHAgMBAAGjggFYMIIBVDAOBgNVHQ8BAf8EBAMCBPAwDAYD VR0TAQH/BAIwADB6BggrBgEFBQcBAQRuMGwwPAYIKwYBBQUHMAKGMGh0dHA6Ly93d3cuY2lzY28u Y29tL3NlY3VyaXR5L3BraS9jZXJ0cy9jZWNhLmNlcjAsBggrBgEFBQcwAYYgaHR0cDovL3BraWN2 cy5jaXNjby5jb20vcGtpL29jc3AwHwYDVR0jBBgwFoAUn5U2tI5d1UvDCsGnKZNDUQb9iVEwOgYD VR0fBDMwMTAvoC2gK4YpaHR0cDovL2Npc2NvY2VydHMuY2lzY28uY29tL2ZpbGUvY2VjYS5jcmww GwYDVR0RBBQwEoEQdnBhcmxhQGNpc2NvLmNvbTAdBgNVHQ4EFgQU77mvrtX1ZwgDCBrBz254abit a7kwHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJ0C qW6utEOTvSb85ZBZel2OgSpFDDjaLWIEceNr23m4NkhjweswzFPJY4nnKgD40Ryv5WVW4KdpmbZx NBZl4Ypd5XlwleoU9jHuSwp6kaYCEJ7YfOIKVBcF1rYclNL0J0nJ2/fnaxGoYylNfW99vu4UaqEl BWU66VkGfsg5hWPRg90fuge1zZhlwI2AE6xq7pV8C2302ag94ti465IhjnHswtA4Q+r39Tc+me1o b2s1g8WKyds2DPI0PAjWnNpsEvYYOXU8MeMv9p6jPbFG9uaCpt8kCGcYytt8FD285Rmq77FRMEBe ptFCTJh5yr5hIaMVoqBUydvZmQAYKnRX8zMxggLwMIIC7AIBATA6MCwxDjAMBgNVBAoTBUNpc2Nv MRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYaYbwJ60IkUDAJBgUrDgMCGgUAoIIBizAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA4MDUxNzQ1NTFaMCMG CSqGSIb3DQEJBDEWBBT11b+6pg03KpGFp6bh+d9ZYKchDTBJBgkrBgEEAYI3EAQxPDA6MCwxDjAM BgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYaYbwJ60IkUDBLBgsq hkiG9w0BCRACCzE8oDowLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVl IENBAgoBhhphvAnrQiRQMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAKA/bAAtkQAMpOCvEc0U1HIJGHYuB+UZQ6ptMz/TJcpy6bZM1UTHaf6+0T+H 7ZTsLl3CI4jwl3D1S+1ns/qj1UU9S/Yo2b3mVg4zvLz/ZYTMffGYOSneA1Ls6RbtIgK14dKQrLhZ cDG1XnR079ybMaSkllmu65SJ0s6b5wD7IJtiH1k9hCSnZHek5IKxYmkTIEE+ZyAKnww26QYiIREk d6QHO6GHy6uPVQmhC/UO3bnIOQvWzCbrQKIqNVq3P4yex6oJ6vcNDkqlYAhS6VRwtKgEiy/DwoKC /EhjDEVwc2BrJqytvPmSWmMYqjysk5AD/8Sbf5jiGwjEqUNDStapb+0AAAAAAAA= ------=_NextPart_000_001A_01D66B2E.BBAA82F0-- From nobody Wed Aug 5 11:31:23 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 0055F3A0E02 for ; Wed, 5 Aug 2020 11:31:22 -0700 (PDT) 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, 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 78HyQL-E1H_T for ; Wed, 5 Aug 2020 11:31:20 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DC43A0E00 for ; Wed, 5 Aug 2020 11:31:20 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-183.access.rits.tisf.net [24.104.150.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 51DBEC3F19; Wed, 5 Aug 2020 18:31:17 +0000 (UTC) From: Paul Vixie To: ADD Mailing list Cc: "Chris Box (BT)" Date: Wed, 05 Aug 2020 18:31:16 +0000 Message-ID: <8496364.PLfOY5O1xY@linux-9daj> Organization: none In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 18:31:22 -0000 On Wednesday, 5 August 2020 17:38:43 UTC Chris Box (BT) wrote: > Wes, > > > I'm not especially in favour of pursuing "discover whether using a resolver > X is acceptable". i differ, and am in favour of that model. > I think it would be better to let the client try. If it succeeds, great. If > not (because the network is denying it), we should allow the network to > explain why it is not succeeding. This is simply a usability improvement. there are two problems with this. first, some technologies (DoH for example) are intended to be unblockable. if the only signal of non-compliance with policy is going to be failure, then that signal will be unreliable. second, policy violations are actionable aberrations for many networks. if the operator of a privately owned edge network has to treat as urgent every use of non-approved accesses such as off-network RDNS use, that's too expensive. therefore i want a cooperating device to be able to learn the local network's policies, in case that device wants to comply with those policies. -- Paul From nobody Wed Aug 5 11:43: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 E2CBB3A0DDF for ; Wed, 5 Aug 2020 11:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=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 CfiTmgvYou7p for ; Wed, 5 Aug 2020 11:43:33 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650113.outbound.protection.outlook.com [40.107.65.113]) (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 1194B3A0DC7 for ; Wed, 5 Aug 2020 11:43:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KBXoxLolOBUqXNHCP4s0rFBrzN8PlFqIKwfBOPsGE7u3IiT9gYHG+jLw2OlNxyWgelQr0yWHgWX3wzFJ3gBzGez+62FLNX/QmE/Ix0iq/vZT9v0PMFDo33zMyKJUiVFAYPc1U+A3bniNt+1Cq+eoGozNpP9pzsa1/064f81te4cyyh+eqmSW4x0mubwDj2A2EPw3RmjoXiv7QUaAo7REb9+kKUlct7taSO+bLIEwvvj5OMce2tPxbl/Oh3dFq9dWaS3Lf4czAhPEK86nruF1RyAqbGh/l1fDp8AM9PwO4YwP73QexWXxKSAEmYSPvH85cwxShUyUdCpUoTCcu28gZQ== 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=yew2KDAYe6dmCOq4VLi2dQihzy2dfm9ncwMI1Vd4m8E=; b=I2mlKN0gsl5TTLmhsZxV3RlUFOTOLYK7pYxN8+Q0gb4XjORWTJS97Y0y7oBMVB9XuudZEBEf/rZqjyKDFoXfRFMI/o+Tnyzqs2CTIN5yp3f6RrA1v8AivjWSDIKEg9Gu/h3mUS/4RLnmg4YthLQB5vXKCG9XilHFK7PnOjzN1Ib+5uROqt+aFdXBTKJAaFHdI60fQt92BulJU24x5o0zya1hrMIXIgPuyf8HVoCmN45yZn4s8tFYkNR7MJnuoexSfAakMRWpT7IUoqVhD2IVr0wcZNVXQVaSXpL4MsTF2Ki1QQVS6OiIJsA0Tg/i60unc5QN2RDLfedlu8OQ4mr6FQ== 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=yew2KDAYe6dmCOq4VLi2dQihzy2dfm9ncwMI1Vd4m8E=; b=MS9DlUEVC6u9rbfX0dRuGsAKpmZ/X47Kts/Ay9iBvtzH7EB/93NOFnfJJO5hBraGO/BzmNzZ/mAH6hOZzPtTeHrMlmmgKmqbZ0u17vgs46NhWPt1yg0Cwv4ivrq4TLzR33dh2/Ru0fXl/JIjCcwm25CLoM0+AtO1SHHWF4l9PDE= Received: from CH2PR00MB0778.namprd00.prod.outlook.com (2603:10b6:610:6c::23) by CH2PR00MB0710.namprd00.prod.outlook.com (2603:10b6:610:a9::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3299.0; Wed, 5 Aug 2020 18:43:31 +0000 Received: from CH2PR00MB0778.namprd00.prod.outlook.com ([fe80::c66:75df:7c7:5871]) by CH2PR00MB0778.namprd00.prod.outlook.com ([fe80::c66:75df:7c7:5871%9]) with mapi id 15.20.3303.000; Wed, 5 Aug 2020 18:43:31 +0000 From: Tommy Jensen To: Paul Vixie , ADD Mailing list CC: "Chris Box (BT)" Thread-Topic: [EXTERNAL] Re: [Add] Requirements drafts Thread-Index: AQHWabV6hj8GI2410k+JCUla01tJrakoOxqAgABNQ6+AAUK+gIAADq8AgAABWDI= Date: Wed, 5 Aug 2020 18:43:30 +0000 Message-ID: References: , <8496364.PLfOY5O1xY@linux-9daj> In-Reply-To: <8496364.PLfOY5O1xY@linux-9daj> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-05T18:43:30.504Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: redbarn.org; dkim=none (message not signed) header.d=none;redbarn.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:a080:aff0:7c5f:5eef:6801:95d] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 24dc5c97-12f2-4e85-e232-08d8396f7344 x-ms-traffictypediagnostic: CH2PR00MB0710: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: E0ivrs3jZ03Me7Ea4jfFMkJoDLoDpx3yKEf7qTqRVt3JsrVHWSfevLarrhkAa7fL9FiCYZqujjKGZ4wxUA77hV+sixmzknNGUME3CnZcxYp1imyRGHyMnPPdCTCCynUPGe0Y3CLUj9KGGp+CGEZ0YKPsn76UthZKap2PdA2ESw4EgM7aWLaVXh1OaNvaRaiuslieoqW9M6cBJET60lS5D8ysyW5L7ZbArQVqVMr8pCAbSB4beoWauXf619xq6brrA9A0tI03ZqiTlNII2SijEU9fT40Ep0S97m9EA1G7jxt0Vm7X3e0akcIUTbpn0XIdLx8YFJHInn91lbcNrzwWbi3TZIFFm3+PT0NqgO+r20nXdRKtxV4xFUFSIJvg3tPX28LlJB+Ag17MMWqD2Wwnuw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0778.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(396003)(376002)(366004)(346002)(966005)(8676002)(5660300002)(478600001)(8936002)(7696005)(55016002)(9686003)(33656002)(19627405001)(53546011)(6506007)(52536014)(186003)(10290500003)(2906002)(316002)(66946007)(66476007)(66556008)(4326008)(91956017)(82950400001)(66446008)(64756008)(8990500004)(83380400001)(86362001)(71200400001)(166002)(110136005)(76116006)(82960400001)(66574015); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: dNbUC2ImAzFSUu5sLNf92o7jyfdOFKOY1lpXWP5PapJUncGEe3vdyLS8scaxTOfG5qoMoDih1L1ZXqwF1DPuGOZ/rVCAxQnXqVFw6KKzl45KhKV9Eda28kcFCwR2tTrolTw0lb/np2ZvgDRmHVTyfv+2tG6U7izw7d5DJ7IKKWBdbDQ9yi84XGHHizJPEOmeL3wDY1i4+2vrL2thdAdcxm7MTpd7KGOCIEDmEHz8UODLDlrDwio3VEddTHBA0IEs86m0icCnCUPxLalAAN5HD+HH9j2/6EbNaYMReOKw4hWH5Ic4/rnU2/0lrTXsgnx6Q17YsC7y2yPKu1g4lnaX6/yxHI3g285H93M+NJysanr0gSykFE6XqRHv+NFxUKD4SfQUNHncS2tI91SmC8388okOgt398icsb58mELOJ46MJ5f51YjXFE90O1ArLS+a771OoHWaruXrXtk0fdH+3Et4xNen3yhe2kXXJ2wO3zsoouHud6cZR3Y4MNSuDXDfwmuIJqWRyPJH0hl4DrLqY9FDB22+AO054Cn3ce4fyZp85juBYyKHpXNUq2e6GI7Ob/LKWKjT/fa/C6eucSoU2iHKrzbsMM3SEM2bnv9VKqfAbuQFCMRMJT81oUqHUQOw/8beU6OCU2KmcNhMiuXsyIrjPmboh3qN+IU3NxCimelD6VrGSDYEPWWBCev3qANQsm7iGrIw+hr0JP+gLIC2vrA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0778171CD198B05F6E4568C0FA4B0CH2PR00MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0778.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24dc5c97-12f2-4e85-e232-08d8396f7344 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 18:43:30.9747 (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: eQpbN9WlgLxtkpsF0Juls3rkeXubsLvwKkH7MIM6IKA6OCyCHGLEV0jWgMKKlFu/BJAoZRF6KEJJvVwE8qUv6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0710 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: Requirements drafts 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 Aug 2020 18:43:36 -0000 --_000_CH2PR00MB0778171CD198B05F6E4568C0FA4B0CH2PR00MB0778namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for bringing this up Paul, as I did go to the secdispatch list as re= commended during our 108 meeting chat. Their responses included "might dese= rve its own area" and "try reusing mechanisms like 802.11x" and a research = proposal and a recommendation of the IRTF instead of the IETF. Each respons= e is an example of how the problem is not specific to DNS. The takeaway being: I still believe the problem of networks communicating p= olicy securely to devices is beyond this WG's scope. This isn't a feature p= arity issue with classic DNS, as there's no such network to client communic= ation pre-DoH/DoT either. Networks have been able to recommend DNS servers = but could not indicate those servers were the only permissible servers to u= se. Thanks, Tommy Jensen =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The latest in Windows Internet Protocols: Native gRPC support: https://aka.ms/grpcblogpost DNS over HTTPS: https://aka.ms/dohblogpost ________________________________ From: Add on behalf of Paul Vixie Sent: Wednesday, August 5, 2020 11:31 AM To: ADD Mailing list Cc: Chris Box (BT) Subject: [EXTERNAL] Re: [Add] Requirements drafts On Wednesday, 5 August 2020 17:38:43 UTC Chris Box (BT) wrote: > Wes, > > > I'm not especially in favour of pursuing "discover whether using a resolv= er > X is acceptable". i differ, and am in favour of that model. > I think it would be better to let the client try. If it succeeds, great. = If > not (because the network is denying it), we should allow the network to > explain why it is not succeeding. This is simply a usability improvement. there are two problems with this. first, some technologies (DoH for example) are intended to be unblockable. = if the only signal of non-compliance with policy is going to be failure, then that signal will be unreliable. second, policy violations are actionable aberrations for many networks. if = the operator of a privately owned edge network has to treat as urgent every use= of non-approved accesses such as off-network RDNS use, that's too expensive. therefore i want a cooperating device to be able to learn the local network= 's policies, in case that device wants to comply with those policies. -- Paul -- 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%7Cf31f49cfb76b429a91e708d8396dc641%7C72f988bf86f141af91ab2d7cd011d= b47%7C1%7C0%7C637322490943879659&sdata=3D3zpsQYbTPjgpq5PhzYnuz42LMCKJfm= tc4g35T71vQ8o%3D&reserved=3D0 --_000_CH2PR00MB0778171CD198B05F6E4568C0FA4B0CH2PR00MB0778namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks for bringing this up Paul, as I did go to the secdispatch list as re= commended during our 108 meeting chat. Their responses included "might= deserve its own area" and "try reusing mechanisms like 802.11x&q= uot; and a research proposal and a recommendation of the IRTF instead of the IETF. Each response is an example of how the probl= em is not specific to DNS.

The takeaway being: I still believe the problem of networks communicating p= olicy securely to devices is beyond this WG's scope. This isn't a feature p= arity issue with classic DNS, as there's no such network to client communic= ation pre-DoH/DoT either. Networks have been able to recommend DNS servers but could not indicate those serve= rs were the only permissible servers to use. 

Thanks,=
Tommy Jensen
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The latest in Wi= ndows Internet Protocols:
  Native gR= PC support: https://aka.ms/grpcblogpost 
  DNS over = HTTPS: https://aka.ms/dohblogpost=  
From: Add <add-bounces@i= etf.org> on behalf of Paul Vixie <paul@redbarn.org>
Sent: Wednesday, August 5, 2020 11:31 AM
To: ADD Mailing list <add@ietf.org>
Cc: Chris Box (BT) <chris.box.ietf@gmail.com>
Subject: [EXTERNAL] Re: [Add] Requirements drafts
 
On Wednesday, 5 August 2020 17:38:43 UTC Chris Box= (BT) wrote:
> Wes,
>
>
> I'm not especially in favour of pursuing "discover whether using = a resolver
> X is acceptable".

i differ, and am in favour of that model.

> I think it would be better to let the client try. If it succeeds, grea= t. If
> not (because the network is denying it), we should allow the network t= o
> explain why it is not succeeding. This is simply a usability improveme= nt.

there are two problems with this.

first, some technologies (DoH for example) are intended to be unblockable. = if
the only signal of non-compliance with policy is going to be failure, then =
that signal will be unreliable.

second, policy violations are actionable aberrations for many networks. if = the
operator of a privately owned edge network has to treat as urgent every use= of
non-approved accesses such as off-network RDNS use, that's too expensive.
therefore i want a cooperating device to be able to learn the local network= 's
policies, in case that device wants to comply with those policies.

--
Paul


--
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%7Cf3= 1f49cfb76b429a91e708d8396dc641%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7= C637322490943879659&amp;sdata=3D3zpsQYbTPjgpq5PhzYnuz42LMCKJfmtc4g35T71= vQ8o%3D&amp;reserved=3D0
--_000_CH2PR00MB0778171CD198B05F6E4568C0FA4B0CH2PR00MB0778namp_-- From nobody Wed Aug 5 11:56: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 BA1563A0F4F for ; Wed, 5 Aug 2020 11:56:03 -0700 (PDT) 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, SPF_HELO_NONE=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 Re84q0OB0JPq for ; Wed, 5 Aug 2020 11:56:02 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA643A0F11 for ; Wed, 5 Aug 2020 11:55:59 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-183.access.rits.tisf.net [24.104.150.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 50328C3F19; Wed, 5 Aug 2020 18:55:59 +0000 (UTC) From: Paul Vixie To: ADD Mailing list Cc: "Chris Box (BT)" , Tommy Jensen Date: Wed, 05 Aug 2020 18:55:58 +0000 Message-ID: <4812731.v9b2bdM30L@linux-9daj> Organization: none In-Reply-To: References: <8496364.PLfOY5O1xY@linux-9daj> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Add] [EXTERNAL] Re: Requirements drafts 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 Aug 2020 18:56:10 -0000 On Wednesday, 5 August 2020 18:43:30 UTC Tommy Jensen wrote: > Thanks for bringing this up Paul, as I did go to the secdispatch list as > recommended during our 108 meeting chat. Their responses included "might > deserve its own area" and "try reusing mechanisms like 802.11x" and a > research proposal and a recommendation of the IRTF instead of the IETF. > Each response is an example of how the problem is not specific to DNS. i recommend greater care than what you heard. in the old (usenet) days, a common form of dismissal was "please move this discussion to a newsgroup i don't subscribe to". for something like dns autoconf, now that the consensus is that DHCP is not secure enough to be able to introduce such a vital service, we cannot afford to accidentally imply such dismissal, or accidentally heed it, or proceed in the absence of trustworthy policy guidance because it's off topic or will come too late. > The takeaway being: I still believe the problem of networks communicating > policy securely to devices is beyond this WG's scope. This isn't a feature > parity issue with classic DNS, as there's no such network to client > communication pre-DoH/DoT either. Networks have been able to recommend DNS > servers but could not indicate those servers were the only permissible > servers to use. if we could proceed on the basis that no such method is needed, then we would not have consensed that DHCP is inadequate for end-node DNS configuration. as i've expressed, i think an authentic DNS autoconfiguration method for end nodes could become the basis by which private-namespace DNS requests could be made to learn other policies. i don't mean that all of that is in-scope, but i do mean that if we build a foundation which could reasonably be used that way, it probably will be used that way. -- Paul From nobody Wed Aug 5 12:44: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 067DC3A0EE4 for ; Wed, 5 Aug 2020 12:44:10 -0700 (PDT) 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, 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=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 2GwwI2Ec7guW for ; Wed, 5 Aug 2020 12:44:08 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 CCA883A0EE2 for ; Wed, 5 Aug 2020 12:44:08 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id b14so41116652qkn.4 for ; Wed, 05 Aug 2020 12:44:08 -0700 (PDT) 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=QFU8SlI6HsXo7JsFOCg+UYFaKN3La+ziVZcKgVojlek=; b=iTnj4m97x+Zh/X7ZfIwJ6zNlZMKWKk4MQvUFd11/UU279HIf4ELLJedsS49NsVMICY TCR/8RqmoqWM04NJmAGuVPzfgALC7Y3Up0RAvAjxMq80X2iYSwZuWa5T06Ew02rx55qh xQg9Agy5zTX3mTluTdxqYw+XjELxbxK+tWNwA7UMulFq+auz2lwVNsgc3VP8oKwLNlRA 9xdD788CeuuCuy3MldnQ+UDHQWG+NpEbQd0M6cP7wbnkmpAtT5k4lRsLEkJEas0Ccp11 /uHIasP3xjzOs6G19HwkcOJeAnJcREBnNgFVvIcz0VrhxrHOtdk2QpgQpIXSUhy+cUPm 7jZA== 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=QFU8SlI6HsXo7JsFOCg+UYFaKN3La+ziVZcKgVojlek=; b=hAO46uNPYmNwSuvSbllwvp0xjq4Y5tyRNnfQjZFFkZdqqxmoMNYLWD0SWRpWplZRss BpP+cI8J17P4bD0KE5SV9VsyvYINLEc/ZjeiZ/8L4gz6yo67ZgkyEQUa0ZZsLeArnVhz 3DoZkcOQn+R4uGPH0+OlC49wMBEjE64SgtzbHxD3h+Qs+SDO6Ge3ZtnoyRxxlj8IGcpp 7yYCgwyp9kUqo6k6W5XuzCF+7nWC/V5RwqGZtWe1pmrM2f3dVdoFITZFHIEaRvovwQ5v yUVAAoM9g88a6nJX0z9JZHPEMGt1GwZX9/fXLtq2V4BHysdH0WuELfJdcwxQE7xL3FE8 oy7Q== X-Gm-Message-State: AOAM532nllZxSNwdUgDOurD27h2HirqXEAkLeA1zWz6NgzTN6YIIJFni HeZd2oA08fH4dlZIB5sNsyj7PQ== X-Google-Smtp-Source: ABdhPJzEflSK3bt0WcH4dvj57zGUfwD/loteLu85xIRFJSsHhZYapzQiRi96V7XOkV+HdFTM8kaUXw== X-Received: by 2002:a37:8286:: with SMTP id e128mr5098170qkd.101.1596656647796; Wed, 05 Aug 2020 12:44:07 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:343a:3af0:7ddd:fe26? ([2601:18b:300:36ee:343a:3af0:7ddd:fe26]) by smtp.gmail.com with ESMTPSA id q68sm2238643qke.123.2020.08.05.12.44.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2020 12:44:07 -0700 (PDT) From: Ted Lemon Message-Id: <97617F2E-3F2E-4FB0-851C-B85459A6CDEF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B7C5FEAC-1524-4D83-BA78-C3F020CE330B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 5 Aug 2020 15:44:05 -0400 In-Reply-To: <8496364.PLfOY5O1xY@linux-9daj> Cc: ADD Mailing list , "Chris Box (BT)" To: Paul Vixie References: <8496364.PLfOY5O1xY@linux-9daj> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 19:44:10 -0000 --Apple-Mail=_B7C5FEAC-1524-4D83-BA78-C3F020CE330B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 5, 2020, at 2:31 PM, Paul Vixie wrote: > therefore i want a cooperating device to be able to learn the local = network's=20 > policies, in case that device wants to comply with those policies. Forgetting for a moment about whether we can do it here, in principle, = how would you feel about a trust establishment ritual for managed = devices, which would then allow such devices to securely discover that = the network has a restrictive resolver policy? And devices that hadn=E2=80= =99t established trust would not trust such a policy announcement (and = possibly not discover it). --Apple-Mail=_B7C5FEAC-1524-4D83-BA78-C3F020CE330B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Aug 5, 2020, at 2:31 PM, Paul Vixie <paul@redbarn.org> = wrote:
therefore i = want a cooperating device to be able to learn the local network's 
policies, in = case that device wants to comply with those = policies.

Forgetting for a moment about whether we can do it here, in = principle, how would you feel about a trust establishment ritual for = managed devices, which would then allow such devices to securely = discover that the network has a restrictive resolver policy? And devices = that hadn=E2=80=99t established trust would not trust such a policy = announcement (and possibly not discover it).

= --Apple-Mail=_B7C5FEAC-1524-4D83-BA78-C3F020CE330B-- From nobody Wed Aug 5 15:07: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 6B5C23A046E for ; Wed, 5 Aug 2020 15:07:56 -0700 (PDT) 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, 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 lysA62Gw4Y4Z for ; Wed, 5 Aug 2020 15:07:53 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6223A044E for ; Wed, 5 Aug 2020 15:07:53 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-183.access.rits.tisf.net [24.104.150.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 1885EC3F19; Wed, 5 Aug 2020 22:07:51 +0000 (UTC) From: Paul Vixie To: Ted Lemon Cc: ADD Mailing list Date: Wed, 05 Aug 2020 22:07:50 +0000 Message-ID: <6975870.lmG34PBWiJ@linux-9daj> Organization: none In-Reply-To: <97617F2E-3F2E-4FB0-851C-B85459A6CDEF@fugue.com> References: <8496364.PLfOY5O1xY@linux-9daj> <97617F2E-3F2E-4FB0-851C-B85459A6CDEF@fugue.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 22:07:57 -0000 On Wednesday, 5 August 2020 19:44:05 UTC Ted Lemon wrote: > On Aug 5, 2020, at 2:31 PM, Paul Vixie wrote: > > therefore i want a cooperating device to be able to learn the local > > network's policies, in case that device wants to comply with those > > policies. > Forgetting for a moment about whether we can do it here, in principle, how > would you feel about a trust establishment ritual for managed devices, > which would then allow such devices to securely discover that the network > has a restrictive resolver policy? And devices that hadn=E2=80=99t establ= ished > trust would not trust such a policy announcement (and possibly not discov= er > it). i think that may be cutting it too fine. if we're going to keep using ARP t= o=20 find MAC addresses, and we're going to keep using DHCP to find gateways, an= d=20 we're not going to tell everybody to use a single host per broadcast domain= in=20 order to protect ARP and DHCP... then we can depend on policy information f= rom=20 the local broadcast domain to tell us what the network policy is. i wouldn't mind if bringing up a new device required pairing, like bluetoot= h,=20 with a shared secret (like "1111" in most cases), but i don't see how to ma= ke=20 that work for IoT which usually has no keyboard and hardly ever has a displ= ay.=20 to me that makes solutions along this axis of rotation largely undeployable. in other words our implicit threat model is either off-path attackers or on- path attackers outside our local network. we should make that explicit, and= =20 then go where that leads us. =2D-=20 Paul From nobody Wed Aug 5 16:07: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 675AC3A08CF for ; Wed, 5 Aug 2020 16:07:05 -0700 (PDT) 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, 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=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 6JkR9nlQjY-s for ; Wed, 5 Aug 2020 16:07:03 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 40DC73A08C1 for ; Wed, 5 Aug 2020 16:07:03 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id e5so20997445qth.5 for ; Wed, 05 Aug 2020 16:07:03 -0700 (PDT) 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=CTFo8CM9Qw7iqPvaa22wpjIWYVcHQMgUsB19KEU6Ldo=; b=KtRPPIErC3REkA53efdAbwbxAfLOpMSMSfaIjeSLlr0nMOSIn1Tl/JTI6mKMCWpg5r CipCGHoXDfoikYsFNU3LPQDR6fIINn/ofOjWpI+sEov1A30J6T7lRXlE4mrNdvrM8TgN BBeWp30V2z2kz9zGlRZabESN8T2YTL7MDmXdIqLx8CKNuZ1/MiNzUk8dASs0lPujOTJZ xTMDj3lfGF7Ah2PQ6JNHvvvPhptoK76s/PrcmPMwUslQAIWHcQlbmcVG93LikdjobxZO 376aSJIghnj3l8ExUlxGrKWhFJdjP0TLW2ZD4BeDwY96zM42/bOTmwtbim6w+B9Ru+Ar D4ZQ== 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=CTFo8CM9Qw7iqPvaa22wpjIWYVcHQMgUsB19KEU6Ldo=; b=TehfxSnSuFd5USvOUFZKlF/Wk/YI/Ngy33gx0oV++N3oCRZrWlLTxekHOGUAhLeAI7 L9gUHPcOIbLtAsyk5JT5i/RWDcTJz5yVpzLtCFjMotU4GoI6MJtTAnuYpt+vKnLQvEVM lM8Ouo3xyYMuapnSWEzwYX0LJbVY2d749fVlihXIi6x0GVLxte79EIE3vMT9E8J1rjl6 XD6ptMiPaHBf/GDaXX8HHF9eYZJGUiH87u6Yn726gxzeJAN8VxGS9QoMY2G/SnDV0A9L xCPz0uAEARznUArcxKM9y7K0W4xRGfxVfjHZ/AVppC+pnS21odyIWz+75jcKtp17o8it LGVA== X-Gm-Message-State: AOAM532ETb8uicnF5vWrTRxHYTxladRK8i/ATTYSp3pyW80pWRU9bAZE XaeK1KgOvczFGs2TSSq/wINCEIA02QGm9g== X-Google-Smtp-Source: ABdhPJyfrJEKyYmCMdvjieXgP7A673J0N7+TjzbvPxWM34x266WdFsM7XufWpT9uRuPl5RggD1iKuw== X-Received: by 2002:ac8:154:: with SMTP id f20mr5729383qtg.57.1596668821959; Wed, 05 Aug 2020 16:07:01 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:343a:3af0:7ddd:fe26? ([2601:18b:300:36ee:343a:3af0:7ddd:fe26]) by smtp.gmail.com with ESMTPSA id 71sm2612999qkk.125.2020.08.05.16.07.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2020 16:07:01 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CC5B110C-EB1D-4376-87CA-EF06025F2667" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 5 Aug 2020 19:06:59 -0400 In-Reply-To: <6975870.lmG34PBWiJ@linux-9daj> Cc: ADD Mailing list To: Paul Vixie References: <8496364.PLfOY5O1xY@linux-9daj> <97617F2E-3F2E-4FB0-851C-B85459A6CDEF@fugue.com> <6975870.lmG34PBWiJ@linux-9daj> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 23:07:05 -0000 --Apple-Mail=_CC5B110C-EB1D-4376-87CA-EF06025F2667 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 5, 2020, at 6:07 PM, Paul Vixie wrote: > i think that may be cutting it too fine. if we're going to keep using = ARP to=20 > find MAC addresses, and we're going to keep using DHCP to find = gateways, and=20 > we're not going to tell everybody to use a single host per broadcast = domain in=20 > order to protect ARP and DHCP... then we can depend on policy = information from=20 > the local broadcast domain to tell us what the network policy is. That trust model works fine when you have a desktop machine chained to a = fixed location with a trusted network. As soon as you have portable = devices, they can plug into networks that definitely cannot be trusted = to tell the truth. E.g., why would $GIANT_COFFEE_SHOP_CHAIN not just = tell me to turn off privacy because they can monetize my queries? = We=E2=80=99ve seen Verizon do exactly this with supercookies=E2=80=94this = is not supposition. If I can=E2=80=99t say =E2=80=9Ctrust Paul=E2=80=99s = network config information and don=E2=80=99t trust $GCSC=E2=80=99s,=E2=80=9D= then I can=E2=80=99t really use that information safely. I know you could argue that I just shouldn=E2=80=99t use $GCSC=E2=80=99s = network if I don=E2=80=99t want them turning off my privacy, but it=E2=80=99= s a decision that my machine has to make without consulting me, and even = if it did consult me I=E2=80=99d have no way to validate the assertion = that I was connecting to $GCSC=E2=80=99s network. So there=E2=80=99s no = my phone can tell that it=E2=80=99s actually connecting to $GCSC=E2=80=99s= network and not some imposter network. The only way it can tell if = it=E2=80=99s connecting to your network is if there=E2=80=99s a trust = establishment process and a way to authenticate the assertion of = trustworthiness. Importantly, this is mostly already a solved problem. It=E2=80=99s not a = trivial problem, but when I go to work, my phone knows I=E2=80=99m = connected to the work network and doesn=E2=80=99t set up the VPN. If my = work wanted to insist that I use their resolver, that=E2=80=99s an = option in the VPN profile, which would be active both when connected to = the VPN and when connected to the actual work network. This is much = more secure than what you=E2=80=99re asking for, because I get the same = protection whether I=E2=80=99m at work or at home or at $GCSC. Also, = very importantly, there is no way in the world that my employer would = allow $GCSC to insist on using their resolver, if they had a policy like = yours. They don=E2=80=99t, because my phone is assumed to be hard enough = to crack that resolver filtering is going to do more harm than good, but = in principle they could insist on resolver filtering wherever I connect, = regardless of local policy, because they have a VPN. > i wouldn't mind if bringing up a new device required pairing, like = bluetooth,=20 > with a shared secret (like "1111" in most cases), but i don't see how = to make=20 > that work for IoT which usually has no keyboard and hardly ever has a = display.=20 > to me that makes solutions along this axis of rotation largely = undeployable. Well, for example, the way it=E2=80=99s done for HomeKit is with a QR = code on the packaging, and a camera on the commissioning device (the = phone). Making this work for Wi-FI without using BLE as a bridge is = harder, but work is being done in that area. I think that ANIMA has = something that does that. > in other words our implicit threat model is either off-path attackers = or on- > path attackers outside our local network. we should make that = explicit, and=20 > then go where that leads us. The threat model I care about is on-path attackers. Off-path attacks are = addressed by a variety of mitigations, from DNSSEC to DoT to DoH. --Apple-Mail=_CC5B110C-EB1D-4376-87CA-EF06025F2667 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Aug 5, 2020, at 6:07 PM, Paul Vixie <paul@redbarn.org> = wrote:
i think that = may be cutting it too fine. if we're going to keep using ARP to 
find MAC = addresses, and we're going to keep using DHCP to find gateways, and 
we're not = going to tell everybody to use a single host per broadcast domain = in 
order to = protect ARP and DHCP... then we can depend on policy information = from 
the local = broadcast domain to tell us what the network policy is.

That = trust model works fine when you have a desktop machine chained to a = fixed location with a trusted network. As soon as you have portable = devices, they can plug into networks that definitely cannot be trusted = to tell the truth. E.g., why would $GIANT_COFFEE_SHOP_CHAIN not just = tell me to turn off privacy because they can monetize my queries? = We=E2=80=99ve seen Verizon do exactly this with supercookies=E2=80=94this = is not supposition. If I can=E2=80=99t say =E2=80=9Ctrust Paul=E2=80=99s = network config information and don=E2=80=99t trust $GCSC=E2=80=99s,=E2=80=9D= then I can=E2=80=99t really use that information safely.

I know you could argue that I just shouldn=E2=80=99t= use $GCSC=E2=80=99s network if I don=E2=80=99t want them turning off my = privacy, but it=E2=80=99s a decision that my machine has to make without = consulting me, and even if it did consult me I=E2=80=99d have no way to = validate the assertion that I was connecting to $GCSC=E2=80=99s network. =  So there=E2=80=99s no my phone can tell that it=E2=80=99s actually = connecting to $GCSC=E2=80=99s network and not some imposter network. The = only way it can tell if it=E2=80=99s connecting to your network is if = there=E2=80=99s a trust establishment process and a way to authenticate = the assertion of trustworthiness.

Importantly, this is mostly already a solved = problem. It=E2=80=99s not a trivial problem, but when I go to work, my = phone knows I=E2=80=99m connected to the work network and doesn=E2=80=99t = set up the VPN. If my work wanted to insist that I use their resolver, = that=E2=80=99s an option in the VPN profile, which would be active both = when connected to the VPN and when connected to the actual work network. =  This is much more secure than what you=E2=80=99re asking for, = because I get the same protection whether I=E2=80=99m at work or at home = or at $GCSC. Also, very importantly, there is no way in the world that = my employer would allow $GCSC to insist on using their resolver, if they = had a policy like yours. They don=E2=80=99t, because my phone is assumed = to be hard enough to crack that resolver filtering is going to do more = harm than good, but in principle they could insist on resolver filtering = wherever I connect, regardless of local policy, because they have a = VPN.

i wouldn't = mind if bringing up a new device required pairing, like bluetooth, 
with a shared = secret (like "1111" in most cases), but i don't see how to make 
that work for = IoT which usually has no keyboard and hardly ever has a display. 
to me that = makes solutions along this axis of rotation largely = undeployable.

Well, for = example, the way it=E2=80=99s done for HomeKit is with a QR code on the = packaging, and a camera on the commissioning device (the phone). =  Making this work for Wi-FI without using BLE as a bridge is = harder, but work is being done in that area.  I think that ANIMA = has something that does that.

in other words our implicit threat model is either off-path = attackers or on-
path attackers outside our local network. we should make that = explicit, and then go where = that leads us.

The threat model I care about is = on-path attackers. Off-path attacks are addressed by a variety of = mitigations, from DNSSEC to DoT to DoH.

= --Apple-Mail=_CC5B110C-EB1D-4376-87CA-EF06025F2667-- From nobody Wed Aug 5 18:45: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 1DDB53A0BC2 for ; Wed, 5 Aug 2020 18:45:04 -0700 (PDT) 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 5FgbJktvVi5n for ; Wed, 5 Aug 2020 18:45:02 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 541933A0BC0 for ; Wed, 5 Aug 2020 18:45:02 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id c6so4003136ilo.13 for ; Wed, 05 Aug 2020 18:45:02 -0700 (PDT) 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=bXHd998CivegRJ2mx0oUuRBdySI/4YRi5aywwK5HifM=; b=VosPT4XEewLRrFaDi3Yvtfy0KaPYnNaYbjv/+ioOpHc3+0fRIhTs8GFFitjZe6N2In mVGM2MfahZMVCa3LzBrHFLbd9MO74pj+FoQfB//rd5wuNFuv55+oUD4Ke2TvrdbWcB+F t9UzzCX905xjXYjtHnP9gMZ+Dc5SMWU5SKeEJyqC7dvTmwfenG81VUU2j00XPQcxNHdf B+5foK/Dp0qg1D2ay+/V1WSaDlRl9qtKGVaTr4+S6phG2L49jVK3etgX2ngxGXU6KJvN 4Ww/AVCHhqUL7ml6wHYke5KnGTQm8A/f1UXJfV+HxstrOL1NtmODCLxxGObQma+avMFH S8Pg== 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=bXHd998CivegRJ2mx0oUuRBdySI/4YRi5aywwK5HifM=; b=BLWH2+j0h8fXD6+m4JLetznM7epgbm9WHMrG4WKqMpwOp3/XXGeajm5oSIxCNJuf1d ggdD72hyDYwQ9jGMUU8OB5mbImWnL8lszH7Sn2Nvl+KL5Goq9WvCX9db7ypThiHv4K7V VEBp8mBmdA0KsKOxCKqKb02G0sgF/IeWnodPT/bkbyMKFS1XpHG3F8u1cONNnc/I2xIy kg7N0PrH6TDI2G3gLL5e4yTSpnejtVVpIB6LQRLYT9Gk7LUoZQBjHTyzuOPog87rDdWU GDjEbN/+vgMxrsWrf/EzG3LORCVFpXDpcLLICJ6O2nGTBV70F12h1OWUtzxYAHyNWkM7 glgw== X-Gm-Message-State: AOAM532ISSjC/+8cKMTgLqXXO54SJYmhPiNxwYOYHsLNioIQ5mwf9Gnr DhM8fCEP5hRXiUT0y/ZvMnJqQ/eZ7AIu6wk5AT/ARLoP X-Google-Smtp-Source: ABdhPJzvTr1YccD7KhEK7E1IhOAKpTHFttr66tfKKWMQv03W8X3L/xnWYMkjk9PNvf5tU7XY2/LxV0XI2Gou5dy63F0= X-Received: by 2002:a92:c904:: with SMTP id t4mr7589804ilp.257.1596678301403; Wed, 05 Aug 2020 18:45:01 -0700 (PDT) MIME-Version: 1.0 References: <8496364.PLfOY5O1xY@linux-9daj> <97617F2E-3F2E-4FB0-851C-B85459A6CDEF@fugue.com> <6975870.lmG34PBWiJ@linux-9daj> In-Reply-To: From: Rob Sayre Date: Wed, 5 Aug 2020 18:44:45 -0700 Message-ID: To: Ted Lemon Cc: Paul Vixie , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000f9cfd405ac2ba237" Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 01:45:04 -0000 --000000000000f9cfd405ac2ba237 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 5, 2020 at 4:07 PM Ted Lemon wrote: > > Importantly, this is mostly already a solved problem. It=E2=80=99s not a = trivial > problem, but when I go to work, my phone knows I=E2=80=99m connected to t= he work > network and doesn=E2=80=99t set up the VPN. > Yes. My Android phone connects to Google's VPN at all times < https://support.google.com/fi/answer/9040000?hl=3Den>. I'm sure there are similar features on many other devices. thanks, Rob --000000000000f9cfd405ac2ba237 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 5, 2020 at 4:07 PM Ted Lemon = <mellon@fugue.com> wrote:
=

Impor= tantly, this is mostly already a solved problem. It=E2=80=99s not a trivial= problem, but when I go to work, my phone knows I=E2=80=99m connected to th= e work network and doesn=E2=80=99t set up the VPN.=C2=A0

Yes. My Android phone connects to Google's VP= N at all times <https://support.google.com/fi/answer/9040000?hl=3Den>. I= 9;m sure there are similar features on many other devices.

<= /div>
thanks,
Rob

--000000000000f9cfd405ac2ba237-- From nobody Thu Aug 6 02:41: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 BE8193A10A6 for ; Thu, 6 Aug 2020 02:40:59 -0700 (PDT) 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, 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=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 YaAf6Hl23TxH for ; Thu, 6 Aug 2020 02:40:57 -0700 (PDT) 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 9F0503A10A2 for ; Thu, 6 Aug 2020 02:40:56 -0700 (PDT) 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)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPS id 129E76A26A; Thu, 6 Aug 2020 11:40:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1596706851; bh=NU+RAgMOHXTFf6Eo90pX3f5haK7Cvy10c9JZnNz4ciI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=48CXdRcTHxlngzYkBlrAKfFuadN2MW0BkkJQb4URzwjGTk5kFGsi1l1iUUqjN7sRG Aa/NSlFiOCcvdzYHdzTwIZmmyojZcyUOKfO5WmheZs9NGfgT0dmBUZrU/Vy2L5gip4 QRTnSlOAgTUIACkgAm6tp2JCycQWmrqJ0/k6EbvNNl2IObrurAPGA7Tw+EU52XfJFY CQo6+alDzHYjXm0MfomyqdZ9BBnMXTGYhpoOi3UbBowiZVXrTd6AlGag4Peps2kz6c QpICKMN31CgjvLlOUyk8rB3pv/7nBvxgEsLojrwoSrrLRLkoHbA2HILV27jJ7UHHH+ 35vSmtwK6c4zQ== 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 0125F3C0311; Thu, 6 Aug 2020 11:40:51 +0200 (CEST) Date: Thu, 6 Aug 2020 11:40:50 +0200 (CEST) From: Vittorio Bertola To: Ted Lemon , Paul Vixie Cc: ADD Mailing list Message-ID: <946837294.33.1596706850907@appsuite-gw1.open-xchange.com> In-Reply-To: References: <8496364.PLfOY5O1xY@linux-9daj> <97617F2E-3F2E-4FB0-851C-B85459A6CDEF@fugue.com> <6975870.lmG34PBWiJ@linux-9daj> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_31_1106592647.1596706850266" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev4 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] Requirements drafts 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 Aug 2020 09:41:00 -0000 ------=_Part_31_1106592647.1596706850266 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Il 06/08/2020 01:06 Ted Lemon ha scritto: > =20 > I know you could argue that I just shouldn=E2=80=99t use $GCSC=E2=80= =99s network if I don=E2=80=99t want them turning off my privacy, but it=E2= =80=99s a decision that my machine has to make without consulting me, >=20 Honestly, I think that the decision whether to trust some entity or not is = so complex, so personal, so depending on personal preferences, locations an= d case, so based on typically human factors like sympathy and prejudice, th= at it is not possible to build any human-centric system based on an assumpt= ion that machines make trust decisions in place of their human users. It is definitely possible to have machines support users in making those ch= oices, for example through reputation systems, choice delegation systems ("= I trust Mozilla so I want Mozilla to make these choices for me"), easy ways= to give general directions ("never trust any network run by a cafe"), but = I think we need a UX/policy architecture focused on empowering humans, and = then we need to build the technical tools that make its implementation poss= ible. If we do not do that, we end up with the risk of some giant device/software= maker pushing all users to only "trust" their own / their partners' networ= ks, and never connect to commercially rival networks - and become the gatek= eeper to Internet access. Incidentally, in the bucket of things that clients should be able to discov= er from a network in secure ways (wherever work will happen on it), let's p= ut also the basic piece of information of which network it is (i.e., recogn= ize if it's the same network that I already connected to in the past, via s= ome form of reliable unique identifier other than a self-advertised SSID) a= nd who owns it. We managed to authenticate websites, could we do the same w= ith networks? -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com= =20 Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_31_1106592647.1596706850266 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =20 =20
 
=20
=20
Il 06/08/2020 01:06 Ted Lemon <mellon@fugue.com> ha scritto:
=20
 
=20
I know you could argue that I just shouldn=E2=80=99t use $GCSC=E2=80=99= s network if I don=E2=80=99t want them turning off my privacy, but it=E2=80= =99s a decision that my machine has to make without consulting me,
=20
=20
Honestly, I think that the decision whether to trust some entity or not = is so complex, so personal, so depending on personal preferences, locations= and case, so based on typically human factors like sympathy and prejudice,= that it is not possible to build any human-centric system based on an assu= mption that machines make trust decisions in place of their human users.
=20
 
=20
It is definitely possible to have machines support users in making those= choices, for example through reputation systems, choice delegation systems= ("I trust Mozilla so I want Mozilla to make these choices for me"), easy w= ays to give general directions ("never trust any network run by a cafe"), b= ut I think we need a UX/policy architecture focused on empowering humans, a= nd then we need to build the technical tools that make its implementation p= ossible.
=20
 
=20
If we do not do that, we end up with the risk of some giant device/softw= are maker pushing all users to only "trust" their own / their partners' net= works, and never connect to commercially rival networks - and become the ga= tekeeper to Internet access.
=20
 
=20
Incidentally, in the bucket of things that clients should be able to dis= cover from a network in secure ways (wherever work will happen on it), let'= s put also the basic piece of information of which network it is (i.e., rec= ognize if it's the same network that I already connected to in the past, vi= a some form of reliable unique identifier other than a self-advertised SSID= ) and who owns it. We managed to authenticate websites, could we do the sam= e with networks?
=20
=20

--

=20 
Vittorio Bertola | Head of Policy & Innovation, Open=
-Xchange
vittorio.b=
ertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Ital=
y
=20
------=_Part_31_1106592647.1596706850266-- From nobody Thu Aug 6 07:17:43 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 B7BE63A077E for ; Thu, 6 Aug 2020 07:17:41 -0700 (PDT) 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, 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=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 nfOP68Y1QQTS for ; Thu, 6 Aug 2020 07:17:40 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 CC4303A0763 for ; Thu, 6 Aug 2020 07:17:39 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id b14so43337498qkn.4 for ; Thu, 06 Aug 2020 07:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=W4/W9xgyW2R1h7dPxmEaDLW+5P5l9UpX1pdrPmNq7tw=; b=B/6oFw4opq1g7dT72Q/wT5TN0XI6chc+XFiKtbzdcJNmUxEuEzYbyso0suodSBO4Jw u3/uBDYrNjj9HW5Ct9v3wd4dr+UrgtJC7WgIxNq97yOi+tAAdt1MwE3qlbMe2TEfbYeV +l30lAuKICl9gG5tPkJTd2DZeImEAsEhP+IFlrA0NZQUmB0tXs2QDkbRhtpFt6kZVHyF 6Fc0AFZvPsGr6ZhaW4RSXSHNrJgZYF1Pegmi76Wh07ziIZBTZ/S7D7c31DSTycgu9DTu Y1aP1SSW7NQlYBJuMRK0RFqbRt1ck6EyKbe41HR2Dmu9Aai0cjTJjecOxwBaTCvEu1SU Y47A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=W4/W9xgyW2R1h7dPxmEaDLW+5P5l9UpX1pdrPmNq7tw=; b=OOJkDmUsib1j06adoYrux3RRhb8m+560kxrNxx3ysmgU8wuE3q6Ydh7yp8kIjSRUkq qYXELafXbdR11J2O06ucPrX+N/h2w+AraBgFi8RgbKc0XdlfS+b44amA+KEo9+N4wFS5 h6ZhW4rQFq6OOPLgkZUfi20AsYuL3HL9W20iEeeKm6aUPRS2wLTeUIeBErXdZXS/3lFl 0WQo92JOHaM/cqNAgvQfXT3SOjfL4QTfGQSOIjoXeROMQaaH0Od2JI9dAVKsqk53W2PA aelwi72+uAFu4sKIN61/aQUjK5Q/qGe0pWwByO1dDIx3etaDsV958hnqOTlNvmLs9I/X 7XlQ== X-Gm-Message-State: AOAM531+GEJdZDGgsDu1r04oREAw9qLxvPqo7yx8ibAXOU0FzmO9Ihhw DdvmW8ObYMukQzUO7BMbB0wVE+2DL2rkxQ== X-Google-Smtp-Source: ABdhPJxL0btFmSucgR/23hVp4icWnumQgnr2Tymew0Vr5j2Ou1g/9PbaZdw5Ydpzx9ZMPdWuqsnjtQ== X-Received: by 2002:a37:5c43:: with SMTP id q64mr8565711qkb.409.1596723458572; Thu, 06 Aug 2020 07:17:38 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:f406:534a:70bb:f925? ([2601:18b:300:36ee:f406:534a:70bb:f925]) by smtp.gmail.com with ESMTPSA id m203sm3917992qke.114.2020.08.06.07.17.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2020 07:17:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3C3E1431-ECC5-4888-B29D-9CE92F6BC21A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Ted Lemon X-Priority: 3 In-Reply-To: <946837294.33.1596706850907@appsuite-gw1.open-xchange.com> Date: Thu, 6 Aug 2020 10:17:34 -0400 Cc: Paul Vixie , ADD Mailing list Message-Id: <02F4287E-1604-4F8C-89B3-B34F4F73BE82@fugue.com> References: <8496364.PLfOY5O1xY@linux-9daj> <97617F2E-3F2E-4FB0-851C-B85459A6CDEF@fugue.com> <6975870.lmG34PBWiJ@linux-9daj> <946837294.33.1596706850907@appsuite-gw1.open-xchange.com> To: Vittorio Bertola X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 14:17:42 -0000 --Apple-Mail=_3C3E1431-ECC5-4888-B29D-9CE92F6BC21A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 6, 2020, at 5:40 AM, Vittorio Bertola = wrote: > Honestly, I think that the decision whether to trust some entity or = not is so complex, so personal, so depending on personal preferences, = locations and case, so based on typically human factors like sympathy = and prejudice, that it is not possible to build any human-centric system = based on an assumption that machines make trust decisions in place of = their human users. It=E2=80=99s really important when talking about protocol development to = differentiate between the meaning of technical terms that are being used = and the natural language meaning of the same term. Trust has a lot of = meanings in english (and in other languages, I am sure). One of them is = the meaning that you are using here: the process by which we decide = whether or not to trust some entity, which has aspects of emotion, = aspects of logic, and so on. This is an important meaning of the word = trust, and it=E2=80=99s relevant here, but it=E2=80=99s not what I was = talking about. The type of trust you are explaining here is how I decide whether to = trust /Paul/. It is how I decide whether to trust /$GCSC/. It is how I = decide that I=E2=80=99m okay with my employer=E2=80=99s VPN. This is an = important part of the equation. But this is not what the term = =E2=80=9Cestablish trust=E2=80=9D is referring to. Trust establishment is something that is done /after/ you decide /who/ = to trust. Suppose I trust Paul. Okay, so I=E2=80=99m willing to use = Paul=E2=80=99s resolver. Trust establishment is how I /know/ that I am = using Paul=E2=80=99s resolver. This is what I was talking about here. If I can=E2=80=99t /know/ that it=E2=80=99s Paul=E2=80=99s resolver = I=E2=80=99m talking to, it doesn=E2=80=99t matter whether I trust Paul = or not. I still can=E2=80=99t trust the resolver, because it=E2=80=99s = just some random resolver. I have no way of knowing that it=E2=80=99s = Paul=E2=80=99s resolver. The other worries you mention in your message are all real worries, but = they are tangential to the trust establishment process. And they are = really hard to solve in the IETF. If we are concerned that Firefox might = misrepresent what they do so that we trust them when we shouldn=E2=80=99t,= or don=E2=80=99t realize that we are trusting them, this is something = that can really only be dealt with on the political level: it has to be = illegal or immoral for Firefox to do that, and there has to be some way = for us to tell that they are doing it. Happily, there are ways to do = this. Firefox is open source, for one thing, so we can just look at the = code. In the case of closed-source products, one of the ways we figure = out whether to trust is based on the legal assertions that are made in = the vendor=E2=80=99s privacy policy, and our understanding of the risk = that they undertake if they lie to us. And of course we also rely on = security researchers and market researchers to notice that they are = living up to their promises, or not. Again, these are all extremely important parts of the trust ecosystem, = and we as citizens should support government policies that have good = outcomes here, but the IETF can=E2=80=99t really be a part of that. All = the IETF can do is figure out (for example) how, technically, a browser = that is behaving in the interests of its users can securely establish = trust with a resolver that the user has decided to trust. --Apple-Mail=_3C3E1431-ECC5-4888-B29D-9CE92F6BC21A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Aug 6, 2020, at 5:40 AM, Vittorio Bertola <vittorio.bertola@open-xchange.com> = wrote:
Honestly, I think that the = decision whether to trust some entity or not is so complex, so personal, = so depending on personal preferences, locations and case, so based on = typically human factors like sympathy and prejudice, that it is not = possible to build any human-centric system based on an assumption that = machines make trust decisions in place of their human = users.

It=E2=80=99s really important when talking about protocol = development to differentiate between the meaning of technical terms that = are being used and the natural language meaning of the same term. Trust = has a lot of meanings in english (and in other languages, I am sure). = One of them is the meaning that you are using here: the process by which = we decide whether or not to trust some entity, which has aspects of = emotion, aspects of logic, and so on. This is an important meaning of = the word trust, and it=E2=80=99s relevant here, but it=E2=80=99s not = what I was talking about.

The type of trust you are explaining here is how I decide = whether to trust /Paul/.  It is how I decide whether to trust = /$GCSC/. It is how I decide that I=E2=80=99m okay with my employer=E2=80=99= s VPN. This is an important part of the equation. But this is not what = the term =E2=80=9Cestablish trust=E2=80=9D is referring to.

Trust establishment is = something that is done /after/ you decide /who/ to trust. Suppose I = trust Paul. Okay, so I=E2=80=99m willing to use Paul=E2=80=99s resolver. = Trust establishment is how I /know/ that I am using Paul=E2=80=99s = resolver. This is what I was talking about here.

If I can=E2=80=99t /know/ that it=E2=80=99= s Paul=E2=80=99s resolver I=E2=80=99m talking to, it doesn=E2=80=99t = matter whether I trust Paul or not. I still can=E2=80=99t trust the = resolver, because it=E2=80=99s just some random resolver. I have no way = of knowing that it=E2=80=99s Paul=E2=80=99s resolver.

The other worries you = mention in your message are all real worries, but they are tangential to = the trust establishment process.  And they are really hard to solve = in the IETF. If we are concerned that Firefox might misrepresent what = they do so that we trust them when we shouldn=E2=80=99t, or don=E2=80=99t = realize that we are trusting them, this is something that can really = only be dealt with on the political level: it has to be illegal or = immoral for Firefox to do that, and there has to be some way for us to = tell that they are doing it. Happily, there are ways to do this. Firefox = is open source, for one thing, so we can just look at the code. In the = case of closed-source products, one of the ways we figure out whether to = trust is based on the legal assertions that are made in the vendor=E2=80=99= s privacy policy, and our understanding of the risk that they undertake = if they lie to us. And of course we also rely on security researchers = and market researchers to notice that they are living up to their = promises, or not.

Again, these are all extremely important parts of the trust = ecosystem, and we as citizens should support government policies that = have good outcomes here, but the IETF can=E2=80=99t really be a part of = that. All the IETF can do is figure out (for example) how, technically, = a browser that is behaving in the interests of its users can securely = establish trust with a resolver that the user has decided to = trust.

= --Apple-Mail=_3C3E1431-ECC5-4888-B29D-9CE92F6BC21A-- From nobody Thu Aug 6 07:31: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 822F63A07E6 for ; Thu, 6 Aug 2020 07:31:17 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 R688Pr_Lpbbu for ; Thu, 6 Aug 2020 07:31:15 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 0F0793A07DB for ; Thu, 6 Aug 2020 07:31:14 -0700 (PDT) Received: by sdaoden.eu (Postfix, from userid 1000) id 6E81716056; Thu, 6 Aug 2020 16:31:13 +0200 (CEST) Date: Thu, 06 Aug 2020 16:31:12 +0200 From: Steffen Nurpmeso To: Ben Schwartz Cc: Ben Schwartz , ADD Mailing list , Steffen Nurpmeso Message-ID: <20200806143112.E66_t%steffen@sdaoden.eu> In-Reply-To: References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> <20200805143604.h2FWD%steffen@sdaoden.eu> Mail-Followup-To: Ben Schwartz , Ben Schwartz , ADD Mailing list , Steffen Nurpmeso User-Agent: s-nail v14.9.19-100-gd425f9da-dirty OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-schwartz-svcb-dns-00.txt 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 Aug 2020 14:31:17 -0000 Ben Schwartz wrote in : ... |I think the need for SVCB is already well-motivated by other use cases, so |I see this the other way. Several drafts in ADD have proposed new RR types |to convey this kind of information (in addition to those that suggest using |SVCB in different ways). Reusing SVCB to convey DNS transport info might |reduce the need for additional RR types. | |... | |> Maybe i should look in bind code or |> so and test whether it would be harder to return the favoured or |> desired set of RR combinations for a RR type or a question for |> a specific SRV. | |Note that SVCB implementation is already under way in BIND (thank you BIND |authors!): https://gitlab.isc.org/isc-projects/bind9/-/issues/1132 ..but interesting that supporting this requires adding contextual information to be passed along the call chain which was not necessary before. |... --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Thu Aug 6 10:04:31 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 B494B3A0D08 for ; Thu, 6 Aug 2020 10:04:29 -0700 (PDT) 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 Xrk_jDGTrXVe for ; Thu, 6 Aug 2020 10:04:28 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 429953A0D05 for ; Thu, 6 Aug 2020 10:04:28 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id j187so45546803qke.11 for ; Thu, 06 Aug 2020 10:04:28 -0700 (PDT) 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=26zHmJyUI0qrJcmxDD3bjZSuSreur8BPKoIP9iMErLs=; b=J2sYiOS3/HP/bh6lavL/JlqvAbj7LCJqx3OVgSZs9BovmGX2rrQtN5rP3paCUtAsXa qoB/rNc1SJqYTLDSNLed0P5/0SbwwcTcvsCh3nOLcB/hlT0cNfk/0/bOOtlw4gZzdAd/ x1slXlypesfe0eiWLnf4e/bm5UWe9wprB8dFGJNns0u/yWkfzXQgE97A6pWphbbmdDoQ elsKTGuUK+JxtBP1kUuzDpH9NwmBkBD7aK5jHa62FldXNFmn3Dt0FY6VBmh66kY3qhAf BavgF2oc/EMjyYR4lejI5pt92k7ZDwozB6ry5OtV4cetPXhRG4c84rOf0Z9GivG4OiQC hMGw== 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=26zHmJyUI0qrJcmxDD3bjZSuSreur8BPKoIP9iMErLs=; b=O+gTr6GHnQ26B0IaGJKFb4b0BsI9bGrWmY67/pBtZRWBrerI8357VEkfX8gEGGbk+s c1A3p2lHOWprv7L0CxtPfCq+rhN+h1/Nb5UpOg+k0kTMCe2qTFaLACly4YnJfayvdAnp KFbdM/EhXKDFFB8nFQqGB8WfDi/IT+0zjbbSrBrYR7yrRKK+J2dXgB17qBUwi7dlcF2i J/n4Vx2J9SwiofdpchIPR7UOx67h8bgEFoCIlSoou3d3UjlG2gRAbiH1Y5pSUUSZP+4x N/Ez/26ZRSe1b+d/EOMKsCXmRR/F1zilPzf6uD3ry5pZxnuY3B4itJgZLFMLt+w0titG vY5Q== X-Gm-Message-State: AOAM532mJfsAc/grLbJ08mHkFazDQGn5xZhlS7Fiv7nT9PRzq20kk0jm YrvBdASi1mj3oLAmbqX53KId7o02FqrRTITLEovhct2C7fQ= X-Google-Smtp-Source: ABdhPJyCWLyrewzaaku51ctpdCZ2xYVEW2/C/YKRWHbNjKRwE+GhQlDaRN7dije1haAlYqasoWLIx2UL+aisjqlNRVo= X-Received: by 2002:a37:2d07:: with SMTP id t7mr9558594qkh.255.1596733467207; Thu, 06 Aug 2020 10:04:27 -0700 (PDT) MIME-Version: 1.0 References: <8496364.PLfOY5O1xY@linux-9daj> <97617F2E-3F2E-4FB0-851C-B85459A6CDEF@fugue.com> <6975870.lmG34PBWiJ@linux-9daj> <946837294.33.1596706850907@appsuite-gw1.open-xchange.com> <02F4287E-1604-4F8C-89B3-B34F4F73BE82@fugue.com> In-Reply-To: <02F4287E-1604-4F8C-89B3-B34F4F73BE82@fugue.com> From: "Chris Box (BT)" Date: Thu, 6 Aug 2020 18:04:15 +0100 Message-ID: To: Ted Lemon Cc: Vittorio Bertola , ADD Mailing list , Paul Vixie Content-Type: multipart/alternative; boundary="0000000000001d2bee05ac387b71" Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 17:04:30 -0000 --0000000000001d2bee05ac387b71 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ted said: Making this work for Wi-FI without using BLE as a bridge is harder, but work is being done in that area. I think that ANIMA has something that does that Ted, were you thinking of BRSKI? https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-42 >From a quick look it does appear to be a "trust establishment" procedure. While I'm here I'll post the current iteration of the proposed requirements structure, in case anyone wants to make further comments on that. 1. Given information from the attached networks, and resolvers known from configuration, discover one or more associated/equivalent encrypted resolvers. 1a: Discover encrypted resolvers that are equivalent to the resolver given out by DHCP/RA/PPP/PCO, regardless of whether this is a classic IP address or a richer set of information. 1aa: Discovering encrypted resolvers behind forwarders, and using them directly (thus bypassing the forwarder). 1ab: Discovering and using encrypted DNS running on forwarders (note that this could involve interactions with the encrypted resolver =E2=80=9Cbehind= =E2=80=9D the forwarder). 1b: Discover encrypted resolvers that are equivalent to a manually-configured resolver, which may be a public Internet resolver. 1c: Discover encrypted resolvers that are equivalent to a VPN-configured DNS servers. 2. Discover an encrypted resolver that is applicable to a limited domain. 2a: Discover a mapping between a locally-hosted domain and an encrypted resolver. - Walled-garden content - Locally-cached content - Private enterprise names 2b: Discover a mapping between a public domain and an encrypted resolver. - Name hosted by CDN foo can use CDN foo=E2=80=99s resolver Chris --0000000000001d2bee05ac387b71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ted said:
Making this work for Wi-FI without using BLE as a bridge is harder, but=20 work is being done in that area.=C2=A0 I think that ANIMA has something tha= t=20 does that

From a quick look it does appear to be a "trust= establishment" procedure.

<= div>
While I'm here I'll post the current iteration o= f the proposed requirements structure, in case anyone wants to make further= comments on that.


1.=C2=A0 Given information from the attached networks, and resolvers known from configuration, discove= r one or more associated/equivalent encrypted resolvers.

1a:=C2=A0 Discover encrypted resolvers that are equivalent to the resolver given out = by DHCP/RA/PPP/PCO, regardless of whether this is a classic IP address or a ri= cher set of information.

1aa:=20 Discovering encrypted resolvers behind forwarders, and using them directly = (thus bypassing the forwarder).

1ab:=20 Discovering and using encrypted DNS running on forwarders (note that=20 this could involve interactions with the encrypted resolver =E2=80=9Cbehind= =E2=80=9D the forwarder).

= 1b: Discover encrypted resolvers that are equivalent to a manually-configured resolver, which may be a public Internet resolver.

= 1c: Discover encrypted resolvers that are equivalent to a VPN-configured DNS servers.


2. Discov= er an encrypted resolver that is applicable to a limited domain.

= 2a: Discover a mapping between a locally-hosted domain and an encrypted resolve= r.

= - Walled-garden content

= - Locally-cached content

= - Private enterprise names

= 2b: Discover a mapping between a public domain and an encrypted resolver.

= - Name hosted by CDN foo can use CDN foo=E2=80=99s resolver


Chris

--0000000000001d2bee05ac387b71-- From nobody Thu Aug 6 10:12: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 3316F3A0D26 for ; Thu, 6 Aug 2020 10:12:07 -0700 (PDT) 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, 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=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 pMleIXSEY_Wv for ; Thu, 6 Aug 2020 10:12:05 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 6EE163A0D28 for ; Thu, 6 Aug 2020 10:12:04 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id j187so45570906qke.11 for ; Thu, 06 Aug 2020 10:12:04 -0700 (PDT) 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=xf+Ou9C8WULpE61Ilr5j1FAgnhP4qiT8253BH4o8H9s=; b=UNrn9juVpn0Vs1+TiRVYfF6T1pihH11AJj8xUaC8xkZ/NxTtLbJLUFXuHzFXPJXqJL yKNrY12F0qeSmKarcl4ftIozMACmJE/EgM43zfamRY2YIUJgLgufOA9L1heGgun2rdcz slZT+4CFyfSbwjqDfnP5/uy2ZAl1rEBVfSLyeCoInkB2MlRLbLuaAignhtjjVY6ZYQtW vod04OlJxP2WBk5LlzJzDFTHac5gv5HFQd1GghDZYZH0ijJnXDS1qr6BkE9mqRR9NLm4 kzHLv8SAgUR9PmBro2WwpBKwBBH8Wxg0P57UUY5eUr4fTpo0H7LJrgtUplsuomsRqDL9 DgDw== 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=xf+Ou9C8WULpE61Ilr5j1FAgnhP4qiT8253BH4o8H9s=; b=enD7y49vkkQCB9a3HuQ0P19jMmmseihrMyCb7ND0aq0iC7yeYPuwJh0HiZWrgMF8y3 0GAb7ROoYUDCAABqJ7+V8k2nMl7sWL9NVqqWKeXqEWBH5vQyQ493kIwr3QPoQ99cmVPz g3C/h/6DgYhM7QPXW/BvvxnWZvUO7gjvZzfehcUG4sS/ou55I3ncA2zu9yd8BYEumZTM qnvXXirwFSzYDiYhk57sJw6CrVfHmS5s75NasGji1RTo9RVxLLCAN0zjhproHElnDr9/ sqglIe+oiJo/hmDIvduoV1qevTMwZgjeiwA1+shi6oJo/tbpKhxSYQHZwZzsD+YlH47B dcMA== X-Gm-Message-State: AOAM531ESHxoJ4fc56cKbjDPM2CRCCoXL+PZPZx4KH+22rzWdl6uuKR7 AQz+TfAIcSAVEBJ61+Q7P3aX6ZDSTwS4DQ== X-Google-Smtp-Source: ABdhPJxVNcxpodz/kSkTZV9XXUbAtjyCgdwOQ+dZmvwDAD9AFczeuAMevbi0QfuTn7phGZCRPqZpQQ== X-Received: by 2002:a37:4717:: with SMTP id u23mr9732966qka.280.1596733923566; Thu, 06 Aug 2020 10:12:03 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:24c5:8a64:803:130f? ([2601:18b:300:36ee:24c5:8a64:803:130f]) by smtp.gmail.com with ESMTPSA id m66sm4684586qkf.86.2020.08.06.10.12.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2020 10:12:03 -0700 (PDT) From: Ted Lemon Message-Id: <97DC2263-FCB6-452B-9D62-BA72B6746D2D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8FA9E49A-05A2-4BDC-B0DA-4970A804F251" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 6 Aug 2020 13:12:01 -0400 In-Reply-To: Cc: Vittorio Bertola , ADD Mailing list , Paul Vixie To: "Chris Box (BT)" References: <8496364.PLfOY5O1xY@linux-9daj> <97617F2E-3F2E-4FB0-851C-B85459A6CDEF@fugue.com> <6975870.lmG34PBWiJ@linux-9daj> <946837294.33.1596706850907@appsuite-gw1.open-xchange.com> <02F4287E-1604-4F8C-89B3-B34F4F73BE82@fugue.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 17:12:07 -0000 --Apple-Mail=_8FA9E49A-05A2-4BDC-B0DA-4970A804F251 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 6, 2020, at 1:04 PM, Chris Box (BT) = wrote: > Ted, were you thinking of BRSKI? = https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-42 = =20= Yes. --Apple-Mail=_8FA9E49A-05A2-4BDC-B0DA-4970A804F251 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Aug 6, 2020, at 1:04 PM, Chris Box (BT) <chris.box.ietf@gmail.com> wrote:
Yes.

= --Apple-Mail=_8FA9E49A-05A2-4BDC-B0DA-4970A804F251-- From nobody Thu Aug 6 11:16:27 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 81AB23A0DD7 for ; Thu, 6 Aug 2020 11:16:19 -0700 (PDT) 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=comcast.com header.b=a1zauajj; dkim=pass (2048-bit key) header.d=comcast.com header.b=ETvPGMEL; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=nFMWDrOq 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 O-Qt2kgMmeJe for ; Thu, 6 Aug 2020 11:16:17 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.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 91B703A0DA4 for ; Thu, 6 Aug 2020 11:16:17 -0700 (PDT) Received: from pps.filterd (m0156891.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 076IA3jG015341 for ; Thu, 6 Aug 2020 14:16:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : mime-version; s=20190412; bh=MnNfIqxA4eEnOmNV1ENcQj8yaO0PA2bBVj5H1DtfUeA=; b=a1zauajjQPtQ+VvSWYoz7oPr9zETiVxyS7/vQM/nDc1cxgP7LRVAQW5IReCwoczZ/+00 Qo3XDH7v1dMPc8gaAu3n00s1DBS484xzrnG+k/1t0nSBTMpEGfCWdm+vaTYF19Bnx9uc Lm6w8s3Y+h2SA7DNuQRrE9aVoydJ851fbtkmG4RJcY1qLBw6oakCGa8TfxkqTcgMODua SZ8BUqhDuC+KWiNkKzFL6Tm9t0M+ojJjhiHTzf2nI05m6v7lxYYaYScAl5NRfO+ANJ3U c7f83WzioCfbluqvTWQj2E8uF4CKbRXpbo9QIe3kFD0T0zQr/5JElcbf1qyp/1VvY+dS Bw== Received: from pacdcmhout02.cable.comcast.com (pacdcmhout02.cable.comcast.com [68.87.96.15]) by mx0a-00143702.pphosted.com with ESMTP id 32qc1wwbvj-38 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 06 Aug 2020 14:16:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1596737775; x=2460651375; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MnNfIqxA4eEnOmNV1ENcQj8yaO0PA2bBVj5H1DtfUeA=; b=ETvPGMELBYuOyfb5CJw+0432UiaU06ABVbIFw7TOWoQk8FmZzAip1OQNTbi+MFEq G+bCTNX8O3whkkhZUz85NrOiHwI935fvZqJio3DYS5jhQN1MwA0dpl1JTJ7kki4q 3UMqrTVUVnD1+ZWh4nD2mfc4bNMR13EvM3l07ZeMECCIDdqbQtKcG8ahMqWH6HJc fLoOv2gf7usL0+Nrr6OaFufpbrSHnX3QhudUCnlSvLM7Utt1REPMZBpgkF/hQh9W LPZRUBwFKnmn+uYGCEg2weaB0UfK8e1KpPsrV3/5T7Ic112u9nvcH8G7wkcrGir7 QvTCrGsuJ10NKms3kQZvbw==; X-AuditID: 4457600f-f27ff70000005543-c6-5f2c48ef064e Received: from PACDCEX46.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by pacdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id BF.5D.21827.FE84C2F5; Thu, 6 Aug 2020 14:16:15 -0400 (EDT) Received: from PACDCEX12.cable.comcast.com (24.40.1.135) by PACDCEX46.cable.comcast.com (24.40.2.145) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Aug 2020 14:16:14 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX12.cable.comcast.com (24.40.1.135) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 6 Aug 2020 14:16:14 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.176) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Aug 2020 14:16:08 -0400 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BYAPR11MB3304.namprd11.prod.outlook.com (2603:10b6:a03:7a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.19; Thu, 6 Aug 2020 18:16:06 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6%7]) with mapi id 15.20.3261.019; Thu, 6 Aug 2020 18:16:06 +0000 From: "Deen, Glenn" To: ADD Mailing list Thread-Topic: September Interim time slot doodle. Thread-Index: AQHWbB2n8u4f9x7fIk+1OjX6lqKokQ== Date: Thu, 6 Aug 2020 18:16:06 +0000 Message-ID: <88B4CDAC-F115-4E93-BFBE-B7E8C6F39093@comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:dca5:32cf:14bd:6e4d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 01f8918a-e61e-4ff6-f0a4-08d83a34c995 x-ms-traffictypediagnostic: BYAPR11MB3304: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qh67sa1HYjskpCG/J0kAE2oQSxEc3GR9Eb6Nl3EetT0LTPK5bYjaLndv6ItMltR6edG/Tm9If6DoLSblcO4Ufr02F3BOChjy740I2FMLOVrrUzzpkYXF6r2SygY2V2JeGOeqE4QCNan4czEMika+yP7bEjFqxJEB+PKhqaSv8VOtGTrfi36MQx89IFTFsQckCVpNzyZT/o0KtXNaeA1D+gHIx8gJQiSsVIq8t658tdLyfWl/3NzW28qfDGYDbbUoFPIGEwS9IuYorLJy6Sejg6JqZgji1X2r3oum7GYdZ2gbCYa9Xw9F6s8OShmlTAkdavUfJvsa3MWpn+P9U+D8Wc7bJj6z/xnFcUjSAo6vr/gbM6JIOLP21XanqcGdG3J5tRsSqlGH0+cdNwQDeVRjTA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(136003)(366004)(346002)(396003)(86362001)(6506007)(66556008)(8936002)(66476007)(6512007)(478600001)(4744005)(64756008)(66946007)(6916009)(76116006)(66446008)(33656002)(316002)(71200400001)(8676002)(966005)(2616005)(5660300002)(166002)(36756003)(2906002)(6486002)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 7Hb1nwvrSKjxre2tA1bLGGFhceLjGn+EgzKeQZJjmNW9sHDfi89sUJNzkOIZ/jrniIAaKq2KzgxtWre6FmXTTMl47kf03EYLlQ101B+NQURz1jMJzAxLtf4Ii/gTGgyJIyj8okfaMSS9ac4BzzB2kkfFMVP3MkJqzlcISVLmnJuwZ5O7rhhC9lajFGWtQH2NmMOcJAPSGdboYFnQgxjG0jyiheGl5QvmGSIkYr7hXl3dQ2Wae/wywCa16N2bqF5lucxzoI8DksV9Hwkyg4esCdIyBSzzLt7QgUWYzRTiC6Hr1aWYu/eQZu5lQVQ16UQBw4vRHzKSsJDHby6VxhcYBhux9PPFdkt81IBQj4A1rIoVvlU21er8Onfr6JYoKQL0bXcRsSq3CTrKpYX3nzGVx2nUSMkZ+HLkxfteKnyTGUy/QDlOGGdlhxmKdrydL7qHeM8r3qw6G7ly87ZLF93c2n3oIkbRfANFsM02W1flfLr8GVLi6oV3xxXd6dQZNV/QbhXs5O+6jpCoAyR6fEtXvZQT4eGcySvmBhRBUPfIXTm/6/cEO8JoBSOMs6bcGrYo61JIcJ4FBjV9+gPgVw7W3PwPNhOxnBv8tgDSS/utAnrRKS17dqDXDLAWbcupG764mS/u0IXhvFuvssybTmb09p9AAwxRHZSVkT2PvSTlODDIRkEuiZnlRPTWcVuxCNoUgUgbWm7dkTnnnq5AO3/M1w== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BLkZEv593YwPi1l95NThNdE2KnRZ+y8oBPyUFv4jAH0j72rdbw4R6Uo2mafsc5hc85hHwPUBpHs/RfWIFWoxHnoHkvv2hQ7aMia4VAhGs7f/9kVUdxxONapVdWaf4S8XNXU6eUsHhWFh+JYCojcgQM7hEUb5jCOKPliPsBjhr43zy798OqR54YtMvEEvzV4EDY7K2BDJNZx7q6q5TrAjRodUN002JpO5tH4ZZETI8Et6247EUcZU1AU1AcqmxYn7eP+EREG66mWiUNs7T/DlZjgjpczXvX2o3tUyvhg0LV/duY7axZcwDB3xenkamM9LCBHl5P2tNQJTRdQ3xM9R+Q== 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=q/acN7JVW1/MTbIuFfduDiJI6da21rHT2MYhudaamTU=; b=iyJ4htR+rh4GyHcj8aU0gcDxn+ILkmxd/SjFeETan2quD0Z6TltM68BJ84mIV1ZZBZs/Qa4kOgjmCG6fxGmtWFG6xsZcO0kxuD/bPMExGugSkVdEHFM7vUz7WM37TTbIgfPXVGdcOyXUm1YW3GJ6qwY0GnduE5pykWpKtlS3BIixEsP4vVXiKwul21yjsAR0vo/5MprsJ4mZYpb0Uq84AnfA2ixmjpEfi8QzwG0/YvDP6qqBNUtzTo+82IqmHymPbIyOdDvRK93tkyXuzim7yirmBZkxYUIKve2PvR1IKGOHM3Yh31a5WsBvaNTEYFu/nZkbNbahE2jD4qC1T96A/A== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q/acN7JVW1/MTbIuFfduDiJI6da21rHT2MYhudaamTU=; b=nFMWDrOq7ZhBqVC+aNUM0ojiD3wOio7IyRXXK3lY2/nXTVQiOHqN1f8jLbTPz6sKwlsZqb7U13qqbr8Z6OsYaRgNMfukI3U60dyGypPR+B4vNlOGnDPIZlZCQEmVpbRmuU2nYf2pNqG1aL9RtDD4NvbelhnErU+ur/qQuAu6zME= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 01f8918a-e61e-4ff6-f0a4-08d83a34c995 x-ms-exchange-crosstenant-originalarrivaltime: 06 Aug 2020 18:16:06.5993 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: KRUDaKnSeI938eUaZcB4s66iwCcxcLb4RYTavYxo+KG+zP1ccVgH5RNUejSHWPffUq7FOMDD0TkZNu1/EV5W1abuoV+P2Y3kQtqR+2GRN10= x-ms-exchange-transport-crosstenantheadersstamped: BYAPR11MB3304 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_88B4CDACF1154E93BFBEB7E8C6F39093comcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsXiEq4ko/veQyfeYNc1JYv/p9exOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/um64wFS60r9i7cx9TAeMayi5GTQ0LAROLJ7GbWLkYuDiGB I0wSzya9h3J2Mkqcf7mFCcK5wijxbtJzKOcoo8S6rjdQziImideHLjFCOA8ZJY4cAunh4GAT 0JHYttkeZImIgLLE0rvbmUBsYaDw9XV3mCDihhJbH58DKxcR0JO4c9IBJMwioCLR8HIFC4jN K2AnMW1fGzOIzSggJvH91BqwVmYBcYlbT+YzQfwgILFkz3lmCFtU4uXjf6wgtqiAvsS99Z9Z QE5jFOhilHjVdYARoshK4uLer1DNshKX5ndDxX0lPt9ph4prSdw7tZUdws6W6FrQBhVXk/j8 9ArUMjmJVb0PWSBsGYkHN7azgSyTENjNLHFwyU1mCOcOs8SfCfsZIZw/rBKftu9iB3lZAujP f4cqJzAazkLyEYSdJHHs3DzmWeAQEJQ4OfMJyyygDmYBTYn1u/QhShQlpnQ/ZIewNSRa58yF sj0kXt1YyI6sZgEjxypGbjMLPQtzPUszPUPTTYzghJPAv4Px6HSPQ4wCHIxKPLy8zjrxQqyJ ZcWVuYcYJTiYlUR4s15oxwvxpiRWVqUW5ccXleakFh9ilOZgURLn7b/6Ik5IID2xJDU7NbUg tQgmy8TBKdXAGPlIy1tcakUy//SDgefSGzQ2JT1uC8utOJ18LjOzyvTzG6NGH3Wj5V+eb8t8 JTf7rYa5o5nMla8J6V8nJT31kFQs+S8s6MIjsG3DKr/AtQemM9ousNZNsjDd/f3ewRX/53Nd 9rJxUlbne5kec82o/5jhr2NPDabUVIe9Wz5HtHWKLoPdF6V9SizFGYmGWsxFxYkA9YhIojQD AAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-06_14:2020-08-06, 2020-08-06 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Add] September Interim time slot doodle. 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 Aug 2020 18:16:25 -0000 --_000_88B4CDACF1154E93BFBEB7E8C6F39093comcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQURELA0KDQpCYXNlZCBvbiB0aGUgcHJldmlvdXMgcG9sbCBUaHVyc2RheSBTZXB0IDEwIGFu ZCBUdWVzZGF5IFNlcHQgMTUgd2VyZSB0aGUgImJlc3QiIGRheXMgb3IgcGVyaGFwcyDigJxsZWFz dOKAnSB3b3JzdCBkYXlzLCByZWNvZ25pemluZyB0aGF0IG5vIG9uZSBkYXkgd29ya2VkIGZvciBl dmVyeW9uZS4NCg0KV2UgYXJlIHBsYW5uaW5nIGZvciAyIHdvcmtpbmcgc2Vzc2lvbnMgb2YgMi41 IGhvdXJzIGVhY2ggYWNyb3NzIDIgZGF5cyBpbiBTZXB0ZW1iZXIuDQoNClNjaGVkdWxpbmcgc2Vz c2lvbnMgZm9yIHN1Y2ggYSBsYXJnZSBudW1iZXIgb2YgcGVvcGxlIGFjcm9zcyB0aW1lIHpvbmVz IGlzIHZlcnkgZGlmZmljdWx0IGFuZCBpdCdzIGxpa2VseSBzb21lIHBlb3BsZSB3b24ndCBiZSBh YmxlIHRvIGF0dGVuZCBib3RoLCAgdG8gaGVscCB0aGUgc2Vzc2lvbnMgd2lsbCBiZSByZWNvcmRl ZCBmb3IgdGhvc2Ugd2hvIGNhbm5vdCBhdHRlbmQuDQoNClBsZWFzZSBmaWxsIG91dCB0aGlzIG5l dyBkb29kbGUgcG9sbCAoYXQgdGhlIGVuZCBvZiB0aGlzIG5vdGUpIHRvIGZpbmQgdGhlIHRpbWUg c2xvdHMgZm9yIDIgc2Vzc2lvbnMgYWNyb3NzIHRob3NlIDIgZGF5cy4NCg0KSW4gc3Bpcml0IG9m IHNoYXJpbmcgdGhlIHBhaW4gc29tZSBvcHRpb25zIGFyZSBiZXR0ZXIgZm9yIHRoZSBVUyBhbmQg b3B0aW9ucyB0aGF0IGFyZSBiZXR0ZXIgZm9yIHRoZSBVSyBhbmQgRXVyb3BlLCBhbmQgc29tZSBh cmUgYSBibGVuZCBvZiB0aGUgMi4gSW4gdGhlIHNwaXJ0IG9mIHNoYXJlIHRoZSBwYWluLCBwbGVh c2Ugc2VsZWN0IEFMTCBjaG9pY2VzIHRoYXQgeW91IGNhbiByZWFzb25hYmx5IGF0dGVuZCBhbmQg bm90IGp1c3QgdGhvc2UgdGhhdCBhcmUgY29udmVuaWVudC4NCg0KRG9vZGxlIHBvbGwgbGluazog IGh0dHBzOi8vZG9vZGxlLmNvbS9wb2xsL2NzNGJ5Y2k4dThjNG40cnUNCg0KVGhhbmtzLA0KQURE IENoYWlycyAtIEdsZW5uIERlZW4sIERhdmlkIExhd3JlbmNlDQoNCg0K --_000_88B4CDACF1154E93BFBEB7E8C6F39093comcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <86DDFF0FBBB11C4D99A4D9B5D9EFF675@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFt aWx5OkhlbHZldGljYTsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7YmFja2dy b3VuZDp3aGl0ZSI+SGkgQURELDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+QmFzZWQgb24gdGhlIHByZXZpb3VzIHBvbGwg VGh1cnNkYXkgU2VwdCAxMCBhbmQgVHVlc2RheSBTZXB0IDE1IHdlcmUgdGhlICZxdW90O2Jlc3Qm cXVvdDsgZGF5cyBvciBwZXJoYXBzIOKAnGxlYXN04oCdIHdvcnN0IGRheXMsIHJlY29nbml6aW5n IHRoYXQgbm8gb25lIGRheSB3b3JrZWQgZm9yIGV2ZXJ5b25lLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO2JhY2tn cm91bmQ6d2hpdGUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5XZSBhcmUg cGxhbm5pbmcgZm9yIDIgd29ya2luZyBzZXNzaW9ucyBvZiAyLjUgaG91cnMgZWFjaCBhY3Jvc3Mg MiBkYXlzIGluIFNlcHRlbWJlci4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+U2NoZWR1bGluZyBzZXNzaW9ucyBmb3Ig c3VjaCBhIGxhcmdlIG51bWJlciBvZiBwZW9wbGUgYWNyb3NzIHRpbWUgem9uZXMgaXMgdmVyeSBk aWZmaWN1bHQgYW5kIGl0J3MgbGlrZWx5IHNvbWUgcGVvcGxlIHdvbid0IGJlIGFibGUgdG8gYXR0 ZW5kIGJvdGgsICZuYnNwO3RvIGhlbHAgdGhlIHNlc3Npb25zIHdpbGwgYmUgcmVjb3JkZWQgZm9y IHRob3NlDQogd2hvIGNhbm5vdCBhdHRlbmQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRl Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+UGxlYXNlIGZpbGwgb3V0IHRo aXMgbmV3IGRvb2RsZSBwb2xsIChhdCB0aGUgZW5kIG9mIHRoaXMgbm90ZSkgdG8gZmluZCB0aGUg dGltZSBzbG90cyBmb3IgMiBzZXNzaW9ucyBhY3Jvc3MgdGhvc2UgMiBkYXlzLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrO2JhY2tncm91bmQ6d2hpdGUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRl Ij5JbiBzcGlyaXQgb2Ygc2hhcmluZyB0aGUgcGFpbiBzb21lIG9wdGlvbnMgYXJlIGJldHRlciBm b3IgdGhlIFVTIGFuZCBvcHRpb25zIHRoYXQgYXJlIGJldHRlciBmb3IgdGhlIFVLIGFuZCBFdXJv cGUsIGFuZCBzb21lIGFyZSBhIGJsZW5kIG9mIHRoZSAyLiBJbiB0aGUgc3BpcnQgb2Ygc2hhcmUg dGhlIHBhaW4sIHBsZWFzZSBzZWxlY3QNCiBBTEwgY2hvaWNlcyB0aGF0IHlvdSBjYW4gcmVhc29u YWJseSBhdHRlbmQgYW5kIG5vdCBqdXN0IHRob3NlIHRoYXQgYXJlIGNvbnZlbmllbnQuICZuYnNw OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjpibGFjayI+RG9vZGxlIHBvbGwgbGluazombmJzcDsNCjxhIGhyZWY9Imh0dHBz Oi8vZG9vZGxlLmNvbS9wb2xsL2NzNGJ5Y2k4dThjNG40cnUiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+aHR0cHM6Ly9kb29kbGUuY29tL3BvbGwvY3M0YnljaTh1OGM0bjRydTwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3Jv dW5kOndoaXRlIj5UaGFua3MsIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5BREQgQ2hh aXJzIC0gR2xlbm4gRGVlbiwgRGF2aWQgTGF3cmVuY2U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_88B4CDACF1154E93BFBEB7E8C6F39093comcastcom_-- From nobody Fri Aug 7 00:34: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 1F94C3A0CC3 for ; Fri, 7 Aug 2020 00:34:05 -0700 (PDT) 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, 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 KBYv60IYQPVk for ; Fri, 7 Aug 2020 00:34:03 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92873A0CC0 for ; Fri, 7 Aug 2020 00:34:03 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-161.access.rits.tisf.net [24.104.150.161]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 853E2C3F19; Fri, 7 Aug 2020 07:34:01 +0000 (UTC) From: Paul Vixie To: Ted Lemon Cc: ADD Mailing list Date: Fri, 07 Aug 2020 07:34:00 +0000 Message-ID: <2736542.fsHRET1YXo@linux-9daj> Organization: none In-Reply-To: References: <6975870.lmG34PBWiJ@linux-9daj> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Add] Requirements drafts 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: Fri, 07 Aug 2020 07:34:05 -0000 On Wednesday, 5 August 2020 23:06:59 UTC Ted Lemon wrote: > On Aug 5, 2020, at 6:07 PM, Paul Vixie wrote: > > i think that may be cutting it too fine. if we're going to keep using ARP > > to find MAC addresses, and we're going to keep using DHCP to find > > gateways, and we're not going to tell everybody to use a single host per > > broadcast domain in order to protect ARP and DHCP... then we can depend > > on policy information from the local broadcast domain to tell us what the > > network policy is. > > That trust model works fine when you have a desktop machine chained to a > fixed location with a trusted network. As soon as you have portable > devices, they can plug into networks that definitely cannot be trusted to > tell the truth. E.g., why would $GIANT_COFFEE_SHOP_CHAIN not just tell me > to turn off privacy because they can monetize my queries? ... you have ignored what i've said, and changed the subject, and attacked a straw man. i beg you to end that pattern of behaviour. the topic under discussion is: > therefore i want a cooperating device to be able to learn the local > network's policies, in case that device wants to comply with those > policies. this has nothing to do with truth or trust. i believe that the same entity who tells me what my gateway is, and who controls the population who can see and answer DHCP and ARP requests and perhaps forge answers to them, can tell me their RDNS policy. separately from that i will decide whether i believe it, or agree with it. but, if i proceed in abberance to that policy, i'll know that i might be considered an attacker, and defended against. that is all this is about. please do not argue against anything i have not said. it's very distracting. -- Paul From nobody Fri Aug 7 03:52: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 A6F763A0F3C for ; Fri, 7 Aug 2020 03:52:55 -0700 (PDT) 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 S5toJbEdu4DC for ; Fri, 7 Aug 2020 03:52:54 -0700 (PDT) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 4AB853A0F3B for ; Fri, 7 Aug 2020 03:52:54 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id cs12so526638qvb.2 for ; Fri, 07 Aug 2020 03:52:54 -0700 (PDT) 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=azImydT2c76xZqGU1enfJQmpBnwjaJzxNmShFtn40O0=; b=c+RVi9utuRPgMBk5UXn8KsO4MU7bTjpFW+MreJTfTzQDSYDc3Gy1B8J6VV9gib3hoC IfnafQ3r1LkSHLWp9ng6INtvgwzXP1SeA9fsQPUMKthhwem70o4sI76DmQlNHThwbrOZ 9wizxkS5bqWIJbrgxLI1AtkQugenGOIKvcE+aCkr3KdWEDqW0MBg1/Rlos45GSxp+jO0 mlqWAjksU5nGJsj/G3vQO7qx15My7PJLYyBXsrVVhFRgP9hkbfHsX5Q3IWgAik7ubwYw jjsCqvMz2wzB4dpHvsQFy+vt0QaBFu4zWVEJyvaTdXQHfx3+GgYt/ti+wQeCqqbyOolA O38w== 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=azImydT2c76xZqGU1enfJQmpBnwjaJzxNmShFtn40O0=; b=brK4pJuTMi104KMcg1EL143HrxpN5Pe99QBbxzfwdDb1C+Hf6vNytkxI6zhTF/lkoV IMENE+8MCCxTqvhpQ/cs0fkR8bG5bXbO1tcP7OCug7vtMQFNFZDOWaWlXcsK5wSMXx3h L675WvFFI2E2s5VPYkFy5ZL5K/SKY9XIJA03ySuRlVuyoUo9QeOkTaG6Q0gTGYFJOQVm 46M7/yUyTV2Hk8ybttICLWwuXfF2tRXX1A/hiFn21c49GIhma6vGzCaEVy+X1m9+q4eU wJHq2Qv3PMI8/ZJbeMSbf5rySRU0hS8HXike6XBNr8NcN5lV5yOrnjOT5jAyBjOak3V7 vzuQ== X-Gm-Message-State: AOAM533bFSBwjV9HEePewUzzbnvsOz60sd0v87/ooH7/FRJWqS7Wp7Dw +vtc+NspYoCtK5Mrat5flMmYQYqbZxnv0TNqGec= X-Google-Smtp-Source: ABdhPJwV68RZ2aXcJyKbaA81t7zRtYPfUuBW6yFecdzP3/nmI5Xuavb8s34+1mzAtUBA9Nyr1B+h/6J7c/LTSOoBrfM= X-Received: by 2002:ad4:510b:: with SMTP id g11mr13551623qvp.20.1596797573256; Fri, 07 Aug 2020 03:52:53 -0700 (PDT) MIME-Version: 1.0 References: <88B4CDAC-F115-4E93-BFBE-B7E8C6F39093@comcast.com> In-Reply-To: <88B4CDAC-F115-4E93-BFBE-B7E8C6F39093@comcast.com> From: "Chris Box (BT)" Date: Fri, 7 Aug 2020 11:52:42 +0100 Message-ID: To: "Deen, Glenn" Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000021da9005ac4768f0" Archived-At: Subject: Re: [Add] September Interim time slot doodle. 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: Fri, 07 Aug 2020 10:52:56 -0000 --00000000000021da9005ac4768f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gleen I was about to complete this when I realised there's probably a systematic typo across the options. The poll asks for "Tue Sept 13" but based on your email I think you mean Tue Sept 15. I'll complete it on that basis; hopefully everyone else has too. Chris On Thu, 6 Aug 2020 at 19:16, Deen, Glenn wrote: > Hi ADD, > > > > Based on the previous poll Thursday Sept 10 and Tuesday Sept 15 were the > "best" days or perhaps =E2=80=9Cleast=E2=80=9D worst days, recognizing th= at no one day > worked for everyone. > > > > We are planning for 2 working sessions of 2.5 hours each across 2 days in > September. > > > > Scheduling sessions for such a large number of people across time zones i= s > very difficult and it's likely some people won't be able to attend both, > to help the sessions will be recorded for those who cannot attend. > > > > Please fill out this new doodle poll (at the end of this note) to find th= e > time slots for 2 sessions across those 2 days. > > > > In spirit of sharing the pain some options are better for the US and > options that are better for the UK and Europe, and some are a blend of th= e > 2. In the spirt of share the pain, please select ALL choices that you can > reasonably attend and not just those that are convenient. > > > > Doodle poll link: https://doodle.com/poll/cs4byci8u8c4n4ru > > > > Thanks, > > ADD Chairs - Glenn Deen, David Lawrence > > > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000021da9005ac4768f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gleen I was about to complete this when I realised th= ere's probably a systematic typo across the options. The poll asks for = "Tue Sept 13" but based on your email I think you mean Tue Sept 1= 5. I'll complete it on that basis; hopefully everyone else has too.
=

Chris

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, 6 Aug 2020 at 19:16, Deen, Gle= nn <Glenn_Deen@comcast.com= > wrote:

Hi ADD,

=C2=A0

Based on the previous poll Thursday Sept 10 and Tuesday S= ept 15 were the "best" days or perhaps =E2=80=9Cleast=E2=80=9D wo= rst days, recognizing that no one day worked for everyone.

=C2=A0

We are planning for 2 working sessions of 2.5 hours each = across 2 days in September.

=C2=A0

Scheduling sessions for such a large number of people acr= oss time zones is very difficult and it's likely some people won't = be able to attend both, =C2=A0to help the sessions will be recorded for tho= se who cannot attend.

=C2=A0

Please fill out this new doodle poll (at the end of this = note) to find the time slots for 2 sessions across those 2 days.

=C2=A0

In spirit of sharing the pain some options are better for= the US and options that are better for the UK and Europe, and some are a b= lend of the 2. In the spirt of share the pain, please select ALL choices that you can reasonably attend and not just those that are con= venient. =C2=A0=C2=A0

=C2=A0

Doodle po= ll link:=C2=A0 https://doodle.com/poll/cs4byci8u8c4n4ru=

= =C2=A0

Thanks,

ADD Chairs - Glenn Deen, David Lawrence

=C2=A0

=C2=A0

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000021da9005ac4768f0-- From nobody Fri Aug 7 06:27: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 5E2113A07E3 for ; Fri, 7 Aug 2020 06:27:38 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 dRNPqf6_JccA for ; Fri, 7 Aug 2020 06:27:37 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.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 186883A0745 for ; Fri, 7 Aug 2020 06:27:37 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 077DMRZq048823; Fri, 7 Aug 2020 09:27:35 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 32rfwr608b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Aug 2020 09:27:35 -0400 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 077DRXVW014166; Fri, 7 Aug 2020 09:27:34 -0400 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 077DRROo014050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Aug 2020 09:27:28 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id ED1294009E6B; Fri, 7 Aug 2020 13:27:27 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (unknown [135.50.89.109]) by zlp30486.vci.att.com (Service) with ESMTPS id D51534009E62; Fri, 7 Aug 2020 13:27:27 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Fri, 7 Aug 2020 09:27:15 -0400 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.004; Fri, 7 Aug 2020 09:27:15 -0400 From: "STARK, BARBARA H" To: "'Paul Vixie'" , "'Ted Lemon'" CC: "'ADD Mailing list'" Thread-Topic: [Add] Requirements drafts Thread-Index: AQHWZ2EKhFF3geHTa0CdMTHqSdgfbakm3yCAgAGjsYCAAAo2c4ABhcuAgAAOrwCAABRYgIAAKCoAgAAQh4CAAh/9AIAAFdIg Date: Fri, 7 Aug 2020 13:27:15 +0000 Message-ID: <7a244a97f0954a889518cabb797c4ed3@att.com> References: <6975870.lmG34PBWiJ@linux-9daj> <2736542.fsHRET1YXo@linux-9daj> In-Reply-To: <2736542.fsHRET1YXo@linux-9daj> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.90.142] x-tm-snts-smtp: BE1F7690EE558BC1F3D8FEE1ED23708E56DF5A086C5B2944F7C2CFA7331BD4032 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-07_09:2020-08-06, 2020-08-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 clxscore=1015 bulkscore=0 adultscore=0 spamscore=0 mlxlogscore=999 impostorscore=0 mlxscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008070094 Archived-At: Subject: Re: [Add] Requirements drafts 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: Fri, 07 Aug 2020 13:27:38 -0000 > From: Paul Vixie > Sent: Friday, August 07, 2020 2:34 AM > To: Ted Lemon > Cc: ADD Mailing list > Subject: Re: [Add] Requirements drafts >=20 > On Wednesday, 5 August 2020 23:06:59 UTC Ted Lemon wrote: > > On Aug 5, 2020, at 6:07 PM, Paul Vixie wrote: > > > i think that may be cutting it too fine. if we're going to keep using= ARP > > > to find MAC addresses, and we're going to keep using DHCP to find > > > gateways, and we're not going to tell everybody to use a single host = per > > > broadcast domain in order to protect ARP and DHCP... then we can > depend > > > on policy information from the local broadcast domain to tell us what= the > > > network policy is. > > > > That trust model works fine when you have a desktop machine chained to > a > > fixed location with a trusted network. As soon as you have portable > > devices, they can plug into networks that definitely cannot be trusted = to > > tell the truth. E.g., why would $GIANT_COFFEE_SHOP_CHAIN not just tell > me > > to turn off privacy because they can monetize my queries? ... >=20 > you have ignored what i've said, and changed the subject, and attacked a > straw > man. i beg you to end that pattern of behaviour. the topic under discussi= on > is: >=20 > > therefore i want a cooperating device to be able to learn the local > > network's policies, in case that device wants to comply with those > > policies. >=20 > this has nothing to do with truth or trust. i believe that the same entit= y who > tells me what my gateway is, and who controls the population who can see > and > answer DHCP and ARP requests and perhaps forge answers to them, can tell > me > their RDNS policy. >=20 > separately from that i will decide whether i believe it, or agree with it= . > but, if i proceed in abberance to that policy, i'll know that i might be > considered an attacker, and defended against. that is all this is about. >=20 > please do not argue against anything i have not said. it's very distracti= ng. I'd been working on a lengthy reply to Ted that said something similar (tho= ugh suggesting that perhaps he didn't seem to quite understand the point be= ing made rather than an intentional misinterpretation -- because Ted is a v= ery nice and rational person and it's so darned easy not to read emailed wo= rds correctly). FWIW, I think Paul and I are on the same page with what we'd like to see. T= his isn't about mandating any sort of client behavior in response to a netw= ork saying the network has a policy to require use of DNS servers it advert= ises. The network has to assume there are clients that will ignore the poli= cy statement; therefore, mandating client behavior is futile. But if there = is a well-known means for the network to express this, then people/coders w= ho *want* to can write code or configure devices that react to such a polic= y statement in a way that makes sense for them. I also believe that all cof= fee shops should have the right to set policies for use of their networks. = If I don't like the policy, I can choose not to use the network or only use= it for limited purposes where I don't care about privacy (e.g., searching = for nearby tourist attractions). BTW, my employer has a strict policy again= st using coffee shop networks (or bringing/using company devices in certain= foreign countries) -- even though the company devices require a VPN to do = just about anything. I truly doubt that being able to use DoH or securely d= iscover DNS server info in the coffee shop or foreign country would change = this company policy. Barbara From nobody Fri Aug 7 08:07: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 7CD8C3A0ABA for ; Fri, 7 Aug 2020 08:07:36 -0700 (PDT) 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, 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=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 z6_YOdjl2PvT for ; Fri, 7 Aug 2020 08:07:34 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 858493A0ADF for ; Fri, 7 Aug 2020 08:07:34 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id m7so1956354qki.12 for ; Fri, 07 Aug 2020 08:07:34 -0700 (PDT) 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=hOFiZ3FTnZ/pclvPbFcLnII1/8xbqN9cniHndGidjYI=; b=2D4xsuerPBum2Bdx5ZKYTNsEWr5Amp6c8yARJRP3IG9R7YMwomGCNbUk8u6Ybbg4F3 iwecv0SwlaTsURevmUoWUFgFcHh7rqUn0aOBw5OdweaAQXA11Uem6422tOJrHgtwZyZv RZVdi1AM0F1U7JuVYI8QlTTKtEPEH+FVTF7ee2BJrfzErwEkrhF3PciE+3nB1+1xnClY uVPFUj+pOhRdYIXaeLyFH80cAZ5SUrYGfgMG79/y5LdDWJyt14FeM0DWeizNaYU5qp4c jDmVt7KQBOOhTj6Kb5cBiMnmjrLc4XHh/yXdAdFKjdQueiB94UBwkpqCjITS6r5d1BA0 77ig== 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=hOFiZ3FTnZ/pclvPbFcLnII1/8xbqN9cniHndGidjYI=; b=YBUHAcbOPpKG13L0gYvxTKq2L1tqpVtRQEu8Xoc6wD7NTU5bUKUz/MadiTkYsnsy35 /RtExMLb2uZLh0U3wC8lDi9aFFuC4thL05XtcM5/LIY/p7/O5WLQIvUgKtWOVW4WPKMe JoGJ63Nh5ttihncyMzqtK1EzQTqh5fbtOoiZIQOot91q3V8ju/thZ5cPYlXbLshm41RA 8JhxFc6IB+chaqd9w5Tsa1mCbtXEFZguopZ1pAi3pY47JW2xGuG+wM5aHmBZyrgWcrJb kC1D7iIAM+qHLc5Nd+kv8tgEvrrmXGYInzRkioYSBuM7a8o1C9gvx1uL9yvanlwJyh7Z ehIQ== X-Gm-Message-State: AOAM5307m59vitqcpRRZceQK80eF8WTYNdqOcRjZgVsdwhGuogSi8Ox7 3ux8dqvfBpcQ8BNitX+vJrLeHg== X-Google-Smtp-Source: ABdhPJwFU4EcDSXaarOyfYCz+QLjdvXEI41y0JX93sQbkkaTMXB7U9t1/bpmc2xk/G0+tUgdc/8y4g== X-Received: by 2002:ae9:ef8d:: with SMTP id d135mr14262943qkg.477.1596812853322; Fri, 07 Aug 2020 08:07:33 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:48f5:aed2:5246:8aa5? ([2601:18b:300:36ee:48f5:aed2:5246:8aa5]) by smtp.gmail.com with ESMTPSA id d46sm8362964qtk.37.2020.08.07.08.07.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2020 08:07:32 -0700 (PDT) From: Ted Lemon Message-Id: <67FFA539-EEC2-4F2A-B1F4-9118E4026E2C@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_882C4225-88D5-42BA-B82B-84E1E6FBD700" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 7 Aug 2020 11:07:31 -0400 In-Reply-To: <2736542.fsHRET1YXo@linux-9daj> Cc: ADD Mailing list To: Paul Vixie References: <6975870.lmG34PBWiJ@linux-9daj> <2736542.fsHRET1YXo@linux-9daj> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Add] Requirements drafts 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: Fri, 07 Aug 2020 15:07:37 -0000 --Apple-Mail=_882C4225-88D5-42BA-B82B-84E1E6FBD700 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 7, 2020, at 3:34 AM, Paul Vixie wrote: > you have ignored what i've said, and changed the subject, and attacked = a straw=20 > man. i beg you to end that pattern of behaviour. the topic under = discussion=20 > is: I could ask you the same. Imagine that we are in a room on the second = floor of a building, and there are some apples in the room that are = taking up space. To free up space, you propose that we put the apples = outside the window. I object that if you put the apples outside the = window, they will fall and be bruised, and thus rendered useless. And = you say =E2=80=9Cstop putting words in my mouth=E2=80=94I never said = that the apples should fall=E2=80=94I just said to put them out the = window.=E2=80=9D This is what this conversation feels like from my perspective. When you establish a way for the network to say =E2=80=9Cif you want to = use the network, you must disable the security that is presently enabled = on your device,=E2=80=9D you create an attack surface. You are saying = =E2=80=9Cdon=E2=80=99t worry, I=E2=80=99m not talking about creating an = attack surface=E2=80=94I just want to be able to tell the user they=E2=80=99= ve been blocked because their device=E2=80=99s security stance is not = permitted here.=E2=80=9D This is like saying that if you put the apples = out the window, they won=E2=80=99t fall: you=E2=80=99re denying that = there is a connection between saying =E2=80=9Cyou=E2=80=99re not winning = because you are using a secure and private DNS protocol=E2=80=9D and the = user disabling their secure and private DNS protocol so that they can = win. Now, it may be that you believe that this doesn=E2=80=99t create an = attack surface, and so we don=E2=80=99t have to do anything to address = that. You may even be right. But the reason we keep going around on this = is that it=E2=80=99s dead obvious to me that you are creating an attack = surface, and so I naturally start thinking about how to mitigate it so = that you can get what you want, and I can not put an attack surface in = my devices. I=E2=80=99m engaging with you because I want to help you get = what you say you want, not because I=E2=80=99m unreasonably trying to = thwart you. Making me out to be unreasonable and a villain when I do this is not = cool. If I=E2=80=99m wrong, convince me I=E2=80=99m wrong. Don=E2=80=99t = tell me to shut up. --Apple-Mail=_882C4225-88D5-42BA-B82B-84E1E6FBD700 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Aug 7, 2020, at 3:34 AM, Paul Vixie <paul@redbarn.org> = wrote:
you have = ignored what i've said, and changed the subject, and attacked a = straw 
man. i beg = you to end that pattern of behaviour. the topic under discussion 
is:

I = could ask you the same.  Imagine that we are in a room on the = second floor of a building, and there are some apples in the room that = are taking up space. To free up space, you propose that we put the = apples outside the window. I object that if you put the apples outside = the window, they will fall and be bruised, and thus rendered useless. = And you say =E2=80=9Cstop putting words in my mouth=E2=80=94I never said = that the apples should fall=E2=80=94I just said to put them out the = window.=E2=80=9D

This is what this = conversation feels like from my perspective.

When you establish a way for the network to say = =E2=80=9Cif you want to use the network, you must disable the security = that is presently enabled on your device,=E2=80=9D you create an attack = surface. You are saying =E2=80=9Cdon=E2=80=99t worry, I=E2=80=99m not = talking about creating an attack surface=E2=80=94I just want to be able = to tell the user they=E2=80=99ve been blocked because their device=E2=80=99= s security stance is not permitted here.=E2=80=9D  This is like = saying that if you put the apples out the window, they won=E2=80=99t = fall: you=E2=80=99re denying that there is a connection between saying = =E2=80=9Cyou=E2=80=99re not winning because you are using a secure and = private DNS protocol=E2=80=9D and the user disabling their secure and = private DNS protocol so that they can win.

Now, it may be that you believe that this = doesn=E2=80=99t create an attack surface, and so we don=E2=80=99t have = to do anything to address that. You may even be right. But the reason we = keep going around on this is that it=E2=80=99s dead obvious to me that = you are creating an attack surface, and so I naturally start thinking = about how to mitigate it so that you can get what you want, and I can = not put an attack surface in my devices. I=E2=80=99m engaging with you = because I want to help you get what you say you want, not because I=E2=80=99= m unreasonably trying to thwart you.

Making me out to be unreasonable and a villain = when I do this is not cool.  If I=E2=80=99m wrong, convince me = I=E2=80=99m wrong. Don=E2=80=99t tell me to shut up.

= --Apple-Mail=_882C4225-88D5-42BA-B82B-84E1E6FBD700-- From nobody Fri Aug 7 08:39:48 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 EA7F23A073E for ; Fri, 7 Aug 2020 08:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 18SfVfqXdxLQ for ; Fri, 7 Aug 2020 08:39:45 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 CA6283A058F for ; Fri, 7 Aug 2020 08:39:44 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id 184so2272828wmb.0 for ; Fri, 07 Aug 2020 08:39:44 -0700 (PDT) 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=lK/2coTsjWe2ejiEAFR3GMi/Soi0KZ6o3slxEGTiP58=; b=Gm216iKKfMBE8lTl44P0DznnmgOnsWLMUHVHy8z5e4SXdE5XN9BEwgph5blL4tXIfY EcEQLE6vCvyj7Ft6Hrcp9kGGRDSzx241MT9bcXT2Nlx6Q69UAYbTOrWrIdBnYZjVgtvp yUZXUwQzmG2eY+zfWMLBylz0LeHAmJUpT8AfEydWM2nZ2hUl4Ra59xAPj6HJjbCcOK0l L+kFuKn7zI6NC27HYlzGRwZcN7xEgdVNRvk9yxAPuKRuN/vkvopiPXGk0DhGwak/yyw6 NaFGzSvuxpoPDfH3xIS+pdvTMdHl5sMcg2ZA/tQrLDVyQKjDl4uWEBTGdc8nDoshxv6X dBwA== 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=lK/2coTsjWe2ejiEAFR3GMi/Soi0KZ6o3slxEGTiP58=; b=XwbNwigY6bBkEMXxMMz9oqOhFVBjQGpBS/PqwmutlucjpB6XzAlYkqA5iFoqJTDxzA OYS3Orynus3d4LEL9Rrcxd9V3QcaQzTzWKpEpyxQXcoB1mo2KI9hGkCeQnEMDbHdljbf nkbQvtkOqMoaLQnjgVzJilSc8aJjZUlb0aLq2/hvq2LlP4cHfL098PT5efL4akUVdRZB G43xOcFQezo4k7I1Z9p9P4lsa2jclpWQj8X+I++Lz8qIy5Jz03lfsijU8OgBl4Aqy0DE 8x5g6yzqB/CJunc8h9gK6uy5LyRHdyXIa6k1k0ZzGdIuzgfxPsNQ0W4TJ8/BhajXTimu umuA== X-Gm-Message-State: AOAM530+l0tJFHSoKzsaDfLBTeD4e6+edjmbs0cWr4wrBYxOv0X5cL1a 5a4C/cGNCdrt26BWGQtAo23cpHQ1yZlSxEenzWkEnkEN X-Google-Smtp-Source: ABdhPJwBfAh+ypAhB78X+yVz7Xb8109aGpgTX49b4BsH/mZx2/LvHyBmWzM0cRvXJpFeEXmE2drdAAQv9QfbfMN7Has= X-Received: by 2002:a1c:a553:: with SMTP id o80mr13076888wme.50.1596814782983; Fri, 07 Aug 2020 08:39:42 -0700 (PDT) MIME-Version: 1.0 References: <6975870.lmG34PBWiJ@linux-9daj> <2736542.fsHRET1YXo@linux-9daj> <67FFA539-EEC2-4F2A-B1F4-9118E4026E2C@fugue.com> In-Reply-To: <67FFA539-EEC2-4F2A-B1F4-9118E4026E2C@fugue.com> From: Eric Orth Date: Fri, 7 Aug 2020 11:39:31 -0400 Message-ID: To: Ted Lemon Cc: Paul Vixie , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000e9ee7305ac4b6931" Archived-At: Subject: Re: [Add] Requirements drafts 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: Fri, 07 Aug 2020 15:39:47 -0000 --000000000000e9ee7305ac4b6931 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mechanisms to communicate information do not create attack surfaces. Clients trusting and changing behavior based on communicated information has the potential to create attack surfaces. How much clients trust info or how they change their behavior is policy and out-of-scope for this WG. Therefore, as long as a critical mass of client implementors can think of reasons to want mechanisms for the network to communicate preferences, it would be completely appropriate to produce relevant RFCs, as long as security considerations give strong reminders of the potential dangers of untrusted use. More specifically, we've seen some proposals for adding DNS-specific information such as DoH URLs to already-existing mechanisms such as DHCP, and I think such proposals are a good idea. Alternately, if people prefer a wider-scoped new mechanism for communicating network preferences/policy beyond just DNS, I believe it has already been suggested that such work may be a good idea, but is out of scope for this WG. On Fri, Aug 7, 2020 at 11:07 AM Ted Lemon wrote: > On Aug 7, 2020, at 3:34 AM, Paul Vixie wrote: > > you have ignored what i've said, and changed the subject, and attacked a > straw > man. i beg you to end that pattern of behaviour. the topic under discussi= on > > is: > > > I could ask you the same. Imagine that we are in a room on the second > floor of a building, and there are some apples in the room that are takin= g > up space. To free up space, you propose that we put the apples outside th= e > window. I object that if you put the apples outside the window, they will > fall and be bruised, and thus rendered useless. And you say =E2=80=9Cstop= putting > words in my mouth=E2=80=94I never said that the apples should fall=E2=80= =94I just said to > put them out the window.=E2=80=9D > > This is what this conversation feels like from my perspective. > > When you establish a way for the network to say =E2=80=9Cif you want to u= se the > network, you must disable the security that is presently enabled on your > device,=E2=80=9D you create an attack surface. You are saying =E2=80=9Cdo= n=E2=80=99t worry, I=E2=80=99m not > talking about creating an attack surface=E2=80=94I just want to be able t= o tell the > user they=E2=80=99ve been blocked because their device=E2=80=99s security= stance is not > permitted here.=E2=80=9D This is like saying that if you put the apples = out the > window, they won=E2=80=99t fall: you=E2=80=99re denying that there is a c= onnection between > saying =E2=80=9Cyou=E2=80=99re not winning because you are using a secure= and private DNS > protocol=E2=80=9D and the user disabling their secure and private DNS pro= tocol so > that they can win. > > Now, it may be that you believe that this doesn=E2=80=99t create an attac= k > surface, and so we don=E2=80=99t have to do anything to address that. You= may even > be right. But the reason we keep going around on this is that it=E2=80=99= s dead > obvious to me that you are creating an attack surface, and so I naturally > start thinking about how to mitigate it so that you can get what you want= , > and I can not put an attack surface in my devices. I=E2=80=99m engaging w= ith you > because I want to help you get what you say you want, not because I=E2=80= =99m > unreasonably trying to thwart you. > > Making me out to be unreasonable and a villain when I do this is not > cool. If I=E2=80=99m wrong, convince me I=E2=80=99m wrong. Don=E2=80=99t= tell me to shut up. > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000e9ee7305ac4b6931 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mechanisms to communicate information do not create attack= surfaces.=C2=A0 Clients trusting and changing behavior based on communicat= ed information has the potential to create attack surfaces.=C2=A0 How much = clients trust info or how they change their behavior is policy and out-of-s= cope for this WG.=C2=A0 Therefore, as long as a critical mass of client imp= lementors=C2=A0can think of reasons to want mechanisms for the network to c= ommunicate preferences, it would be completely appropriate to produce relev= ant RFCs, as long as security=C2=A0considerations give=C2=A0strong reminder= s of the potential dangers of untrusted use.

More s= pecifically, we've seen some proposals for adding DNS-specific informat= ion=C2=A0such as DoH URLs to already-existing mechanisms such as DHCP, and = I think such proposals are a good idea.=C2=A0 Alternately, if people prefer= a wider-scoped new mechanism for communicating network preferences/policy = beyond just DNS, I believe it has already been suggested that such work may= be a good idea, but is out of scope for this WG.

On Fri, Aug 7,= 2020 at 11:07 AM Ted Lemon <mellon@= fugue.com> wrote:
On Aug 7, 2020, at 3:3= 4 AM, Paul Vixie <= paul@redbarn.org> wrote:
you have ignored what i've = said, and changed the subject, and attacked a straw=C2=A0
man. i beg you to end that pattern of behaviour. the topic under discuss= ion=C2=A0
is:

I= could ask you the same.=C2=A0 Imagine that we are in a room on the second = floor of a building, and there are some apples in the room that are taking = up space. To free up space, you propose that we put the apples outside the = window. I object that if you put the apples outside the window, they will f= all and be bruised, and thus rendered useless. And you say =E2=80=9Cstop pu= tting words in my mouth=E2=80=94I never said that the apples should fall=E2= =80=94I just said to put them out the window.=E2=80=9D

=
This is what this conversation feels like from my perspective.

When you establish a way for the network to say =E2=80=9C= if you want to use the network, you must disable the security that is prese= ntly enabled on your device,=E2=80=9D you create an attack surface. You are= saying =E2=80=9Cdon=E2=80=99t worry, I=E2=80=99m not talking about creatin= g an attack surface=E2=80=94I just want to be able to tell the user they=E2= =80=99ve been blocked because their device=E2=80=99s security stance is not= permitted here.=E2=80=9D =C2=A0This is like saying that if you put the app= les out the window, they won=E2=80=99t fall: you=E2=80=99re denying that th= ere is a connection between saying =E2=80=9Cyou=E2=80=99re not winning beca= use you are using a secure and private DNS protocol=E2=80=9D and the user d= isabling their secure and private DNS protocol so that they can win.
<= div>
Now, it may be that you believe that this doesn=E2=80=99= t create an attack surface, and so we don=E2=80=99t have to do anything to = address that. You may even be right. But the reason we keep going around on= this is that it=E2=80=99s dead obvious to me that you are creating an atta= ck surface, and so I naturally start thinking about how to mitigate it so t= hat you can get what you want, and I can not put an attack surface in my de= vices. I=E2=80=99m engaging with you because I want to help you get what yo= u say you want, not because I=E2=80=99m unreasonably trying to thwart you.<= /div>

Making me out to be unreasonable and a villain whe= n I do this is not cool.=C2=A0 If I=E2=80=99m wrong, convince me I=E2=80=99= m wrong. Don=E2=80=99t tell me to shut up.

-- Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000e9ee7305ac4b6931-- From nobody Fri Aug 7 09:06:26 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 BFC2E3A0B4B for ; Fri, 7 Aug 2020 09:06:24 -0700 (PDT) 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 snG1TFilgnTM for ; Fri, 7 Aug 2020 09:06:22 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 525123A0B56 for ; Fri, 7 Aug 2020 09:06:22 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id 2so2146285qkf.10 for ; Fri, 07 Aug 2020 09:06:22 -0700 (PDT) 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=PR5VTXR/dtRH1GnBuHsHzgohzSO31xDL0FW1DxHGK4E=; b=JKLD6lwOe07a1jU1pByJBw3hHcY2mibiqvnhhtLwJ6+30OqZZAjB+20IL4PG9CHg99 YOZIKE6dxRQI1YEFBb/2JiFg7MvzcdrMUIZv90kPQDoEmPDbWLVeTyKmSpYhKhhXTaTH DfCo2WHx5D/2mLaDbZZ/oFwSXPocUYRiQMTnTLEcJYA2WEqHhudBf3V3/shzzBGKzSJ7 y12kX/heNLXizWih9HUbayssA8RGqx5soC564bVRkD26e2QVw+1megESbLuD7ZrViNHg INPggclg5Yj8MCG7C8GK1HlpKkyl0U0WAeOQfyH2qLVcGkperS1rXfBz2NRx65a0MFSf 6d6Q== 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=PR5VTXR/dtRH1GnBuHsHzgohzSO31xDL0FW1DxHGK4E=; b=YQ/iMBF0Sx2Uwm7G8y31d0hrySp+fm5EUF2AukrrIsAEkCqEPNGMgOTeKCCsyWWfy9 aoOcwgqSgMII58zggQUQUNjWJaWDmBBPIEnvrOeF3D34jE9Sx6QfPcnnu7dRzPJRhMct lZvO4Do/sh5v9iQ21S9D/uqxiyrERD5Lree2/YCatuzxHjDZshAagfwndd/unxPhed3w CBDFXOyW/eLEO814PE0IYPi8q5d+Q7eFMWF/cQewIY0VQo0+dipfhSafuer1sIVzYU3k SU2ZkRRflAkn1OfW6INhHjsYqHaNIF/WWUrbLxJZDYogAGZ71A2I/XbJtAltbRUQjre2 4HRQ== X-Gm-Message-State: AOAM530v5kA7BrrotP01l4jGIgmi6neZo6NiMwRSfmKPtbgZZA/pVb8t oCGC6QPvFMkFOHPuqn7OfAuGVrOzv0MFTaZO/tI= X-Google-Smtp-Source: ABdhPJwjHCKU04tknr5LgUZeUMxRJvA4wZuxvwnNMFL0hoQL6Vabgi3QLbaBYNa9Y6Jg5tQYGPFV7OYyeQvTELT8WqM= X-Received: by 2002:a37:4717:: with SMTP id u23mr14581518qka.280.1596816381217; Fri, 07 Aug 2020 09:06:21 -0700 (PDT) MIME-Version: 1.0 References: <6975870.lmG34PBWiJ@linux-9daj> <2736542.fsHRET1YXo@linux-9daj> <7a244a97f0954a889518cabb797c4ed3@att.com> In-Reply-To: <7a244a97f0954a889518cabb797c4ed3@att.com> From: "Chris Box (BT)" Date: Fri, 7 Aug 2020 17:06:09 +0100 Message-ID: To: "STARK, BARBARA H" Cc: Paul Vixie , Ted Lemon , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000002ca65f05ac4bc9fb" Archived-At: Subject: Re: [Add] Requirements drafts 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: Fri, 07 Aug 2020 16:06:25 -0000 --0000000000002ca65f05ac4bc9fb Content-Type: text/plain; charset="UTF-8" On Fri, 7 Aug 2020 at 14:27, STARK, BARBARA H wrote: > This isn't about mandating any sort of client behavior in response to a > network saying the network has a policy to require use of DNS servers it > advertises. The network has to assume there are clients that will ignore > the policy statement; therefore, mandating client behavior is futile. But > if there is a well-known means for the network to express this, then > people/coders who *want* to can write code or configure devices that react > to such a policy statement in a way that makes sense for them. Earlier in the thread I said that it wasn't necessary for a network to communicate policy in advance, only to provide a way to deliver the reasons for a block, after it has occurred. But the above, together with Paul's, has convinced me that such a thing would be useful. Clearly there are large risks if clients automatically acquiesce to whatever the unknown network says. Ted's right to point that out. But I can envisage cases where it would be sensible. Also +1 to what Eric said. --0000000000002ca65f05ac4bc9fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, 7 Aug 2020 at 14:27, STARK, BARBARA H <bs7652@att.com> wrote:
This isn't about mandating any sort of cl= ient behavior in response to a network saying the network has a policy to r= equire use of DNS servers it advertises. The network has to assume there ar= e clients that will ignore the policy statement; therefore, mandating clien= t behavior is futile. But if there is a well-known means for the network to= express this, then people/coders who *want* to can write code or configure= devices that react to such a policy statement in a way that makes sense fo= r them.

Earlier in the thread I said that it wasn't necessary = for a network to communicate policy in advance, only to provide a way to de= liver the reasons for a block, after it has occurred. But the above, togeth= er with Paul's, has convinced me that such a thing would be useful.

Clearly t= here are large risks if clients automatically acquiesce to whatever the unk= nown network says. Ted's right to point that out. But I can envisage ca= ses where it would be sensible.

<= div class=3D"gmail_quote">Also +1 to what Eric said.


--0000000000002ca65f05ac4bc9fb-- From nobody Fri Aug 7 09:48: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 55C4F3A0C07 for ; Fri, 7 Aug 2020 09:48:12 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 729_-CKEGHOv for ; Fri, 7 Aug 2020 09:48:10 -0700 (PDT) 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 D7DF03A0CD1 for ; Fri, 7 Aug 2020 09:48:09 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id b79so2279438qkg.9 for ; Fri, 07 Aug 2020 09:48:09 -0700 (PDT) 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=3XSBPuupGuzLPsUWME3y4GZWT0EYZUFvSOksZPIsOgY=; b=jf+UrZ5pMWLLaBIzeCbzFfAau3Oxj1DWjglhId848Z0hnUwgXWxtCAIS7GC0Ij/OLg ax9HtwPd2iv2EwebuHV9DaGXHOQ0k4oy38387Id8daOAjoH9ZHiaqDTvWsH/1e+a07Zc 6WX8DABHBz/tJNax75HG+LWD7tvSnfXDgPdfCSxJ1MWzkftbYyvD4541kcWON1sOf819 HWY0cE/Yt5rzKb21w9iX+JZEuPYfo03MnArxjtI1A5VBeTSpMfpQOPKsv0XI+lf+II9Q j+EMaO7r/bjd+Ka6+kNT5bNtFLdTbWvfKzOkpB24Orn+F+cJMwiBwil8ciFgnEj9h3+2 7Oug== 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=3XSBPuupGuzLPsUWME3y4GZWT0EYZUFvSOksZPIsOgY=; b=tlHFOifOa9BTORawKHFpU002Oi+RWCoZjUN8cZV6FNTj0TYWJ20GRoGjz0Brqf4VBU TbA7EBWB6STcTmoJn0mtUnC8NQ4X9rh13QGcDgS+ajzE9E2L69nxpD9Jm1+C02PEFhv4 WL5Qa3acMzno8XOqcTpVtMjHGia4tEiviZ9MSS2M/2alzk0rMBCVDIJGdpasGgwjQP/l ATJMssPvW7881Wxmo6BN0Kc8waOBphN5SGH9ls0Oxg/Uryvo2U3HVBdrJ0puD5Kuvqeb i5gP5mUH6N7r5J6U7h/tHREYtK3vyVz5H+sPHcIEDRcdBN8LGwOvpGS2Q8idSs72hGdV SU1g== X-Gm-Message-State: AOAM531LhNQe4vRAsqJaBrZUeypeDaxELfOqHH7j/0++LvpOHSQi1SpJ e7ZhU6cfyp6vmbF+r+nua4Hfm5AmGpICxg== X-Google-Smtp-Source: ABdhPJxV+8xx5HY2PcxAvLxXNX8jdV+Zn3sZqM0X6SIgAIh3yb6sXL3JQhs8qbkE0G5r1QE2e/dlEA== X-Received: by 2002:ae9:e506:: with SMTP id w6mr14369012qkf.376.1596818888709; Fri, 07 Aug 2020 09:48:08 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:48f5:aed2:5246:8aa5? ([2601:18b:300:36ee:48f5:aed2:5246:8aa5]) by smtp.gmail.com with ESMTPSA id p34sm1172494qte.79.2020.08.07.09.48.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2020 09:48:08 -0700 (PDT) From: Ted Lemon Message-Id: <54D54CAE-A401-44A7-A459-EAF5275ECCA4@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A5C1BA1E-ADA6-419A-93DD-745D877A6CC4" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 7 Aug 2020 12:48:06 -0400 In-Reply-To: Cc: Paul Vixie , ADD Mailing list To: Eric Orth References: <6975870.lmG34PBWiJ@linux-9daj> <2736542.fsHRET1YXo@linux-9daj> <67FFA539-EEC2-4F2A-B1F4-9118E4026E2C@fugue.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Add] Requirements drafts 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: Fri, 07 Aug 2020 16:48:12 -0000 --Apple-Mail=_A5C1BA1E-ADA6-419A-93DD-745D877A6CC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 7, 2020, at 11:39 AM, Eric Orth wrote: > Mechanisms to communicate information do not create attack surfaces. That=E2=80=99s pretty much the way we create attack surfaces. The belief = that it is not has a long history of causing very expensive security = failures. An analogous case is the certificate alert bypass in web browsers. = There=E2=80=99s nothing wrong with using self-signed certs. But if you = ask the user to decide whether to trust one, you have an attack surface = that=E2=80=99s easy to exploit, because users will tend to say yes. As a consequence of this, what has begun to happen is that browsers have = stopped even presenting a dialog when they get a cert they can=E2=80=99t = validate with PKI. They do not offer users the option of bypassing the = warning. To bypass the warning, the user has to actually already know = how to bypass it. And indeed they don=E2=80=99t necessarily even get an = explanation of why the connection has failed. The less information they = get, the harder it is to trick them into bypassing the self-signed cert. What we=E2=80=99re proposing here is to create an analogous attack = surface. It seems like a good idea, because you=E2=80=99re informing the = user as to why they are losing. But it creates a way to trick the user = into acting against their interests. What you=E2=80=99ve said is that this isn=E2=80=99t a problem, because = the attack surface only exists if the implementation displays the = information to the user. But the whole point of providing the mechanism = is to make it possible to communicate useful information to the user. What I=E2=80=99ve said, to which Paul is objecting, is that the = mechanism should include a way of establishing and verifying trust, so = that the user is presented with information that they=E2=80=99ve decided = to trust only after they make the decision to trust it. This means that = when the network tells you =E2=80=9Cno,=E2=80=9D it=E2=80=99s okay for = you to act on that. BTW, this is totally orthogonal to the question of offering a DoH server = in DHCP. If there is no pre-configured DoH server, this would be useful = and make sense, and isn=E2=80=99t a particular security risk. If it were = supposed to override the user=E2=80=99s pre-configured DoH server, that = would be a problem, but I don=E2=80=99t expect that anybody would = implement that. --Apple-Mail=_A5C1BA1E-ADA6-419A-93DD-745D877A6CC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Aug 7, 2020, at 11:39 AM, Eric Orth <ericorth@google.com>= wrote:
Mechanisms to communicate = information do not create attack = surfaces.

That=E2=80=99s pretty much the way we create attack surfaces. = The belief that it is not has a long history of causing very expensive = security failures.

An analogous case is the certificate alert bypass in web = browsers. There=E2=80=99s nothing wrong with using self-signed certs. = But if you ask the user to decide whether to trust one, you have an = attack surface that=E2=80=99s easy to exploit, because users will tend = to say yes.

As = a consequence of this, what has begun to happen is that browsers have = stopped even presenting a dialog when they get a cert they can=E2=80=99t = validate with PKI. They do not offer users the option of bypassing the = warning. To bypass the warning, the user has to actually already know = how to bypass it. And indeed they don=E2=80=99t necessarily even get an = explanation of why the connection has failed. The less information they = get, the harder it is to trick them into bypassing the self-signed = cert.

What = we=E2=80=99re proposing here is to create an analogous attack surface. = It seems like a good idea, because you=E2=80=99re informing the user as = to why they are losing. But it creates a way to trick the user into = acting against their interests.

What you=E2=80=99ve said is that this = isn=E2=80=99t a problem, because the attack surface only exists if the = implementation displays the information to the user. But the whole point = of providing the mechanism is to make it possible to communicate useful = information to the user.

What I=E2=80=99ve said, to which Paul is objecting, is that = the mechanism should include a way of establishing and verifying trust, = so that the user is presented with information that they=E2=80=99ve = decided to trust only after they make the decision to trust it. This = means that when the network tells you =E2=80=9Cno,=E2=80=9D it=E2=80=99s = okay for you to act on that.

BTW, this is totally orthogonal to the = question of offering a DoH server in DHCP. If there is no pre-configured = DoH server, this would be useful and make sense, and isn=E2=80=99t a = particular security risk. If it were supposed to override the user=E2=80=99= s pre-configured DoH server, that would be a problem, but I don=E2=80=99t = expect that anybody would implement that.

= --Apple-Mail=_A5C1BA1E-ADA6-419A-93DD-745D877A6CC4-- From nobody Fri Aug 7 11:06: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 144E13A0E92 for ; Fri, 7 Aug 2020 11:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 VaGyOf71-6tp for ; Fri, 7 Aug 2020 11:06:55 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450: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 B07E23A0E90 for ; Fri, 7 Aug 2020 11:06:54 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id c19so9167563wmd.1 for ; Fri, 07 Aug 2020 11:06:54 -0700 (PDT) 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=PB6YpQW1t9TLcrE1JMhKn/rOkOezN1XyM5Ln/a09faM=; b=Nf45sSVX3TRM+4zfGCWXHLjhKyAI5EfmR5KtsGiib+BoplFigfjGSTAs9NZbqPmyWn zr4Ci9OLFemEU/EpZ3pr+XTJ1gThjL9fdwThvDSzc1TEy6dTFuV1uvZTjp8EcHf1UQwc 27PsFDEBD2kG4kWJVv8rEEp7ZoIRAdmLgByo7tDy9YjXOB9A9JV9KzK0DGrdiHT3CiQu 2dQ6xud/MkFj/Hd81cKWs+5R74xW3eS1oAWyH7aiPyiAJQPYy1fPUp7AQp8UVY4AaqzX b1y+l/PMg6EnD2bV5tnX+2p+MZamLPf2oKZoLxtGI7H/oLJk0ewc6CZ4wp1kmPHo23IX hGAw== 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=PB6YpQW1t9TLcrE1JMhKn/rOkOezN1XyM5Ln/a09faM=; b=g8jVcMfmAxclYuOJjUQvgeM70kXPwR31yFCmmvJ0+cqNSwY/ypZaf1diZe3RTW0FFU TMX/Iy+oy4l5N1mwhAcNAdNZIzQenuR87rSGbfcGpgys4Zu3Mq7EXg5dJKRje5VLvpVS NjadWzzSXK9ZbWvGdA+H4sVckKDiZ0hIaWVXVubv7vyJcpYDfW2oO3uz/Jiaun57JoI4 azfhS/K/zwo9CD89fPVoDblGqQw0KayCASHgrBaZHmJmYS5ttlp1xcaGfG3YrXauBXJb O2etJX6p3YSTKKGwpxnglOywyVahC+WsBzDshObfvpN0kNhsNYBpQ7cFgrMQO7FE8GIx yrFw== X-Gm-Message-State: AOAM53359gHfWuCpxC1KKTbt0C+YFYYDDZWVslWO862TBXWROid6QZcO IOIP8wObtHCY7iFGVEH3UPkuxYVM9j10ZWbGwCWQeVr2 X-Google-Smtp-Source: ABdhPJxVU+oUKFKxIuLlHYUlymVpfS92sFfvONNYRmjTUNXjs9+SkQGiUa7mgYsDq4net5bpRrDS6jQQ3s45VYuVa+8= X-Received: by 2002:a1c:a553:: with SMTP id o80mr13588401wme.50.1596823612895; Fri, 07 Aug 2020 11:06:52 -0700 (PDT) MIME-Version: 1.0 References: <6975870.lmG34PBWiJ@linux-9daj> <2736542.fsHRET1YXo@linux-9daj> <67FFA539-EEC2-4F2A-B1F4-9118E4026E2C@fugue.com> <54D54CAE-A401-44A7-A459-EAF5275ECCA4@fugue.com> In-Reply-To: <54D54CAE-A401-44A7-A459-EAF5275ECCA4@fugue.com> From: Eric Orth Date: Fri, 7 Aug 2020 14:06:40 -0400 Message-ID: To: Ted Lemon Cc: Paul Vixie , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000037b2bb05ac4d784d" Archived-At: Subject: Re: [Add] Requirements drafts 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: Fri, 07 Aug 2020 18:06:56 -0000 --00000000000037b2bb05ac4d784d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 7, 2020 at 12:48 PM Ted Lemon wrote: > BTW, this is totally orthogonal to the question of offering a DoH server > in DHCP. If there is no pre-configured DoH server, this would be useful a= nd > make sense, and isn=E2=80=99t a particular security risk. If it were supp= osed to > override the user=E2=80=99s pre-configured DoH server, that would be a pr= oblem, but > I don=E2=80=99t expect that anybody would implement that. > I do not understand your point of how DHCP is fundamentally different from other mechanisms of communicating network preferences/policy. Why would clients/users be trusted to use info responsibly only if it comes from DHCP? Or is your point that just offering a specific DoH resolver is fine, but more specific policy such as "you must use this resolver" would be problematic? --00000000000037b2bb05ac4d784d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 7, 2020 at 12:48 PM Ted L= emon <mellon@fugue.com> wrote= :
BTW, this is totally orthogonal to the questio= n of offering a DoH server in DHCP. If there is no pre-configured DoH serve= r, this would be useful and make sense, and isn=E2=80=99t a particular secu= rity risk. If it were supposed to override the user=E2=80=99s pre-configure= d DoH server, that would be a problem, but I don=E2=80=99t expect that anyb= ody would implement that.

I do = not understand your point of how DHCP is fundamentally different from other= mechanisms of communicating network preferences/policy.=C2=A0 Why would cl= ients/users be trusted to use info responsibly only if it comes from DHCP? = Or is your point that just offering a specific DoH resolver is fine, but mo= re specific policy such as "you must use this resolver" would be = problematic?
--00000000000037b2bb05ac4d784d-- From nobody Fri Aug 7 11:10:52 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 88F393A0EDF for ; Fri, 7 Aug 2020 11:10:51 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 dH3C6Olj_mXv for ; Fri, 7 Aug 2020 11:10:50 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 155EC3A0EDE for ; Fri, 7 Aug 2020 11:10:50 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id o22so1927491qtt.13 for ; Fri, 07 Aug 2020 11:10:49 -0700 (PDT) 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=Mhi6vYmNsqmRVQtAIPIYhFLutat//HMexV3I/5G+D2A=; b=XasXcBH6JDazwd75YQrVEiZmiG60f7dnhux74bzVOem+btylQq1JNxGbluSUquPlPQ 28VlN27iq54yCj2yogsYpOY41Al+TOaW0b8vx7vJVEN0rw99lD8phgNAZNSCm1pRwTeV cHkuJPb6eUWxUe6hIu1uJLG2wto19wahrgVDW260HIVkhH7zAfv5pWNfa+c3G9tmbmIT RdFLJSaNXOnSqF39xJXRs1+zvDqvAejqPFiKGbwMVOgjcsbZbp483OfOTvkNexkjj7mU nyMhfSq92NRKkQjU9vnXQo2IAbkzXPj+PL7v7b+X+m7G2ZZFgmFchzGA8bQnWs0kFPMc n2IQ== 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=Mhi6vYmNsqmRVQtAIPIYhFLutat//HMexV3I/5G+D2A=; b=pWn2whzGGZd7u4d9wYl+2onCPuQHQ+bMlibvIzlcnDHEtbm9639Ij1RVga3RB1kWv1 3Y5vYTCAipYWdBi8TkZJAZm7bJ6SQMAVeHBmKpgnIrKYEBG5VE4eOMEaqMJSSHzZAjyF /9iUMqYDIfmL5RscnD1gx2jZq5GJNGSAUCIk5HUXUWnduYGdu48Gq4FUI3ScJiKasg3D cPp4GlPDK4VC2dMZSROHRK5jXtHZnFRv1Wi1C+iQjeg9u7BamBafAcFmgdTbIrbaqI+u eafkt+/8mfhSiHqywINzIemfc/Qwbfzwfl+5BZUNqo474mjuejQN8t2YPiYry/quhhYr bD3Q== X-Gm-Message-State: AOAM530XvbL/zDkh7vD39qVfckjgmuEkVBv8xort6WSmyHATjCmu4msw RYbbU0WpICjou6hpi5O0tZwv2LBxhFYBPg== X-Google-Smtp-Source: ABdhPJzZDpvynqK+4rGbyCyXBU7Hwg+oHOhV/Z1GDKGgKSK0/cZT88oBWakPugrsdcEJSSXnh/VyOw== X-Received: by 2002:ac8:dc9:: with SMTP id t9mr15391748qti.138.1596823848954; Fri, 07 Aug 2020 11:10:48 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:48f5:aed2:5246:8aa5? ([2601:18b:300:36ee:48f5:aed2:5246:8aa5]) by smtp.gmail.com with ESMTPSA id g4sm7677234qtp.89.2020.08.07.11.10.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2020 11:10:48 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F232CF74-4E46-4E6A-8AFE-C07647177D50" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 7 Aug 2020 14:10:47 -0400 In-Reply-To: Cc: Paul Vixie , ADD Mailing list To: Eric Orth References: <6975870.lmG34PBWiJ@linux-9daj> <2736542.fsHRET1YXo@linux-9daj> <67FFA539-EEC2-4F2A-B1F4-9118E4026E2C@fugue.com> <54D54CAE-A401-44A7-A459-EAF5275ECCA4@fugue.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Add] Requirements drafts 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: Fri, 07 Aug 2020 18:10:52 -0000 --Apple-Mail=_F232CF74-4E46-4E6A-8AFE-C07647177D50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 7, 2020, at 2:06 PM, Eric Orth wrote: > I do not understand your point of how DHCP is fundamentally different = from other mechanisms of communicating network preferences/policy. Why = would clients/users be trusted to use info responsibly only if it comes = from DHCP? Or is your point that just offering a specific DoH resolver = is fine, but more specific policy such as "you must use this resolver" = would be problematic? What I believe Paul is asking for is a way to inform the user that DoH = is not permitted on this network. What DHCP does is to provide the = address of a DoH server that is available on this network. A DNS resolver that is not configured with a DoH server ought to prefer = the local DoH server to the local Do53 server. So informing it of the = availability of this service makes sense. A DNS resolver that is = configured with a DoH server ought not to replace that DoH server with = one advertised by DHCP, because that would be an obvious way to violate = the user=E2=80=99s privacy. So if we were to specify such an option, I = would expect the applicability statement to say this clearly. And if it = didn=E2=80=99t, an implementation that I did would still ignore the DHCP = option if there was already an explicit DoH server configured. It=E2=80=99= s hard to imagine an implementor of this DHCP option popping up a dialog = to ask the user what to do when there is a conflict. But the express purpose of the error message is to inform the user, so = an implementation necessarily has to pop up a dialog, or in some other = way inform the user. That is how the two things are different. --Apple-Mail=_F232CF74-4E46-4E6A-8AFE-C07647177D50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Aug 7, 2020, at 2:06 PM, Eric Orth <ericorth@google.com>= wrote:
I do not understand your point = of how DHCP is fundamentally different from other mechanisms of = communicating network preferences/policy.  Why would clients/users = be trusted to use info responsibly only if it comes from DHCP? Or is = your point that just offering a specific DoH resolver is fine, but more = specific policy such as "you must use this resolver" would be = problematic?

What I believe Paul is asking for is a way to inform the user = that DoH is not permitted on this network.  What DHCP does is to = provide the address of a DoH server that is available on this = network.

A DNS = resolver that is not configured with a DoH server ought to prefer the = local DoH server to the local Do53 server. So informing it of the = availability of this service makes sense.  A DNS resolver that is = configured with a DoH server ought not to replace that DoH server with = one advertised by DHCP, because that would be an obvious way to violate = the user=E2=80=99s privacy. So if we were to specify such an option, I = would expect the applicability statement to say this clearly. And if it = didn=E2=80=99t, an implementation that I did would still ignore the DHCP = option if there was already an explicit DoH server configured. It=E2=80=99= s hard to imagine an implementor of this DHCP option popping up a dialog = to ask the user what to do when there is a conflict.

But the express purpose = of the error message is to inform the user, so an implementation = necessarily has to pop up a dialog, or in some other way inform the = user.  That is how the two things are different.

= --Apple-Mail=_F232CF74-4E46-4E6A-8AFE-C07647177D50-- From nobody Fri Aug 7 11:38: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 A4DEE3A0D94 for ; Fri, 7 Aug 2020 11:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=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 WcR43WD7CYXR for ; Fri, 7 Aug 2020 11:38:32 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640093.outbound.protection.outlook.com [40.107.64.93]) (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 A806E3A0D64 for ; Fri, 7 Aug 2020 11:38:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DPxmsvvw0DcTG8RalqSyvhI30fSD2Wp5sU7TYS9McdLkxYdTsCoFouizAJ9vXrQPTuItiSQJHMy2u/0HKf5rvaSy2m5FSjP845iSd9eNOboWYX6xhEGZBgzXWFivn/4dHzyltDIDbfFtX5UqYpNcauyKNZ+M8H/kbCAK0YxBgE+mI3L+mwcTS/W+B7FVHuRjpYITs9zpJDy5KGJHBi/I/TH0Hx6lTTrnXJCyww550N8zKEfM2nmMZJS6cFBWI8m2qNr2vnhP+g+tsTikuwWbeqnm27lmKOyIRieTfgBbLwqQTTfJg1f2FeDXxUaAZZ5aoY6KV2AdNfG6PZ9JqXJcuw== 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=8qRzpn9yknRxeIERga11NTePSlv5XEkPn1VTiXQB66U=; b=MoTLRYIJFvInl/3hekj0UPTy5wgLCnMJgSvaWyqrgaCLujJP/rgCuonF4MPi+4CVBW57Z+6avIICKLdPtaVegfdcbqFe/j16pHUPVG8u2Sis3Sf17ZjQrwiE/MJ8SdvF8Opt+F1FjgScrv7tctQTAnP7v/Wv53+ZO41swzXDk1URVK4yIYJc9KE+x8seNQ5zSnmDmoISTwD9pRjawD6JqYXXSLneArUTFWuQnfNGDWoaFZoPRH7QnjH7K5GaNRJ19GSx3i4v3TDkQedkEREBhe3nxZbmLHrCM/yeX5HYe2rkjMDFIUruPf5u1AkMrsN3LoqU4xRDTzUAQylUQZPCKw== 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=8qRzpn9yknRxeIERga11NTePSlv5XEkPn1VTiXQB66U=; b=g4txRTVWuQRV4Y2pIWNfJcoqx0FLoDKKarU6hT55xMTE+EBt8Ui2VPv1RNPcY8cbsZrdm+k+sA0NUt6ovMhCZlXBVkCHrp/KRg6k+6B88Xt977ray+DyxvAy4bwm0UttTYNrokqq1qKTv+qCw27Xqkfk8KQNyrGj46RxfwQBfh4= Received: from DM6PR00MB0781.namprd00.prod.outlook.com (2603:10b6:5:1b5::20) by DM6PR00MB0797.namprd00.prod.outlook.com (2603:10b6:5:1bd::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3300.0; Fri, 7 Aug 2020 18:38:30 +0000 Received: from DM6PR00MB0781.namprd00.prod.outlook.com ([fe80::e898:2d46:56a9:b23e]) by DM6PR00MB0781.namprd00.prod.outlook.com ([fe80::e898:2d46:56a9:b23e%5]) with mapi id 15.20.3309.000; Fri, 7 Aug 2020 18:38:30 +0000 From: Tommy Jensen To: Ted Lemon , Eric Orth CC: ADD Mailing list , Paul Vixie Thread-Topic: [EXTERNAL] Re: [Add] Requirements drafts Thread-Index: AQHWabV6hj8GI2410k+JCUla01tJrakoOxqAgABNQ6+AAUK+gIAADq8AgAAUWICAACgqAIAAEIeAgAIf/QCAAH62gIAACPGAgAATKQCAABX0AIAAASaAgAAGe+8= Date: Fri, 7 Aug 2020 18:38:30 +0000 Message-ID: References: <6975870.lmG34PBWiJ@linux-9daj> <2736542.fsHRET1YXo@linux-9daj> <67FFA539-EEC2-4F2A-B1F4-9118E4026E2C@fugue.com> <54D54CAE-A401-44A7-A459-EAF5275ECCA4@fugue.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-07T18:38:30.257Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:a080:aff0:3c1a:c550:9273:1a28] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8c016cbb-1a79-4b87-d88a-08d83b011509 x-ms-traffictypediagnostic: DM6PR00MB0797: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qrXjDDQ42mrSdBAoEmCE8TxLx4Dosnbi5UhXvWnHoYYEaE49Ajr0/9n7yc3dXA8tcqiybmk/sVo+jeFhJhUGXvMcqEU1Ec8dNXDXiWVrwBTqUOUikeepxHl1p+YwRLx7YNCxaGURiY5D3iN4vEWc0to1fcmamWtfAbokGD8vEgbw0iwhvAI1La/cKLVDgUoXSdlL/+uG1pFbtWGNQ+jmVVwADcJOCzDD/sKxlR0H9Q3Zq4wLajRjDiV5YrpKY04urFfkAUkFMgM/YDiiOl4FoZJnb0xjKHHQeHRCqSSfO520caxEHfTQ3S1aRL9Dq7CLRtqHBcHCwvU7whe2H8h0DYrWpwCk+wSlzplAV1ZwRSX91yOa34t/kCzcXpbFW4SmyCNuHRWO7l0Flz7g/SjPRA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0781.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(39860400002)(366004)(396003)(8990500004)(19627405001)(966005)(478600001)(8936002)(8676002)(9686003)(6506007)(53546011)(55016002)(10290500003)(33656002)(166002)(7696005)(110136005)(5660300002)(82960400001)(83380400001)(2906002)(86362001)(316002)(4326008)(91956017)(76116006)(66446008)(64756008)(66556008)(66476007)(66946007)(71200400001)(66574015)(82950400001)(54906003)(52536014)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ViKG3BRR2mkb+nyAYM15eGf+SC7yng1qD0JtLvCXHvc+KV/8rhoAWbaK61eEm4a+lllJ112i0O5uNAcwWkYXHv8z6tvE+qygc6+Jx7DIb/j5FBi7Hd1Fi6QIxKIad6K6mMU3H4LoCjnJjX+hmGeZfuiH9r9W9dyp+CTO24bSFihTEGflCbTpB6sbgXwVX1Jn21Kkrxvt2/u+4As4oGcnj6/u1+7hMLdntPSeVHuiWee3ZNvj47iQG+zFxJWbMjWn8oypHvnozCA9jPkBb0ofpk7MdLC16cCQhtPv7dgnnPcCNHTnx/yI4zHvDE+/aiyYW0U/gvcO53Ie8TvI79HpFCaZ3U0NgyHwPVL/RpdLR+aQqQFDETobx06eh251TeG47SNZUC9H9XbPlHC9I0Kb4VnEQJ25RR4CD8WY7fnjzilIfQpojNIxWRYV2kKdzLpnDyCu6tvsRLqVymDX/WhvLWd5bJ5v3mVIYCcpcItWHQPyTMyztr3z2rvnaDRYiQ9BY8Gn79s4HaRPS/EK3kEJUaojhEYnXI5qKJ+G9o9aynXOBbz/LaXHYMOedT28H5poa7o+6aRm1ovSAl6qL5PMyAB9xZ9pSSFQYxOfdA+VI0hY+T/Cjoz04bDlVTP2U3CEgr6Jr9pm/8OWNQIaDUKs9fls+Z4HV17DER9pKoQBlMc/VNtG4T2BG5Y6ObQRYXTtw31aVb9EILTqzPPk7nGhkA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB078103C208E50E21FB4E3874FA490DM6PR00MB0781namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0781.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c016cbb-1a79-4b87-d88a-08d83b011509 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2020 18:38:30.6420 (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: tAPUzPepOYmdJrhxtfi97ywOSGm3TnNbWfZgK2rbrAfoqH1bs4FFxwghPiClnkN7Zk2IEDKTMe3NJtc+LUv1fA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0797 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: Requirements drafts 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: Fri, 07 Aug 2020 18:38:35 -0000 --_000_DM6PR00MB078103C208E50E21FB4E3874FA490DM6PR00MB0781namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think of this difference Ted is highlighting as "network recommendation" = versus "network requirement". The former has existed for classic DNS in DHC= P for a long time, and the latter as of yet does not exist for DNS servers. I agree with Ted: offering network recommendations of DoH servers make perf= ect sense. It brings DoH use up to parity with classic DNS use. Offering ne= twork requirements for DoH I consider to be beyond WG scope as it is a subs= et of the network requirements problem which is unsolved for clients with n= o prior knowledge of the network. To be clear: I think the problem of secure communication of network require= ments is worth solving. However, it should get the scope and attention it d= eserves to get it right as opposed to an awkward blocker to DoH deployment. Thanks, Tommy Jensen =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The latest in Windows Internet Protocols: Native gRPC support: https://aka.ms/grpcblogpost DNS over HTTPS: https://aka.ms/dohblogpost ________________________________ From: Add on behalf of Ted Lemon Sent: Friday, August 7, 2020 11:10 AM To: Eric Orth Cc: ADD Mailing list ; Paul Vixie Subject: [EXTERNAL] Re: [Add] Requirements drafts On Aug 7, 2020, at 2:06 PM, Eric Orth > wrote: I do not understand your point of how DHCP is fundamentally different from = other mechanisms of communicating network preferences/policy. Why would cl= ients/users be trusted to use info responsibly only if it comes from DHCP? = Or is your point that just offering a specific DoH resolver is fine, but mo= re specific policy such as "you must use this resolver" would be problemati= c? What I believe Paul is asking for is a way to inform the user that DoH is n= ot permitted on this network. What DHCP does is to provide the address of = a DoH server that is available on this network. A DNS resolver that is not configured with a DoH server ought to prefer the= local DoH server to the local Do53 server. So informing it of the availabi= lity of this service makes sense. A DNS resolver that is configured with a= DoH server ought not to replace that DoH server with one advertised by DHC= P, because that would be an obvious way to violate the user=92s privacy. So= if we were to specify such an option, I would expect the applicability sta= tement to say this clearly. And if it didn=92t, an implementation that I di= d would still ignore the DHCP option if there was already an explicit DoH s= erver configured. It=92s hard to imagine an implementor of this DHCP option= popping up a dialog to ask the user what to do when there is a conflict. But the express purpose of the error message is to inform the user, so an i= mplementation necessarily has to pop up a dialog, or in some other way info= rm the user. That is how the two things are different. --_000_DM6PR00MB078103C208E50E21FB4E3874FA490DM6PR00MB0781namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I think of this difference Ted is highlighting as "network recommendat= ion" versus "network requirement". The former has existed fo= r classic DNS in DHCP for a long time, and the latter as of yet does not ex= ist for DNS servers.

I agree with Ted: offering network recommendations of DoH servers make perf= ect sense. It brings DoH use up to parity with classic DNS use. Offering ne= twork requirements for DoH I consider to be beyond WG scope as it is a subs= et of the network requirements problem which is unsolved for clients with no prior knowledge of the network. = ;

To be clear: I think the problem of secure communication of network require= ments is worth solving. However, it should get the scope and attention it d= eserves to get it right as opposed to an awkward blocker to DoH deployment.=

Thanks,=
Tommy Jensen
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The latest in Wi= ndows Internet Protocols:
  Native gR= PC support: https://aka.ms/grpcblogpost 
  DNS over = HTTPS: https://aka.ms/dohblogpost=  
From: Add <add-bounces@i= etf.org> on behalf of Ted Lemon <mellon@fugue.com>
Sent: Friday, August 7, 2020 11:10 AM
To: Eric Orth <ericorth@google.com>
Cc: ADD Mailing list <add@ietf.org>; Paul Vixie <paul@redba= rn.org>
Subject: [EXTERNAL] Re: [Add] Requirements drafts
 
ericorth@google.com> wrote:
I do not understand your point of how DHCP is fundamentally different from o= ther mechanisms of communicating network preferences/policy.  Why woul= d clients/users be trusted to use info responsibly only if it comes from DH= CP? Or is your point that just offering a specific DoH resolver is fine, but more specific policy such as "yo= u must use this resolver" would be problematic?

What I believe Paul is asking for is a way to inform the us= er that DoH is not permitted on this network.  What DHCP does is to pr= ovide the address of a DoH server that is available on this network.

A DNS resolver that is not configured with a DoH server oug= ht to prefer the local DoH server to the local Do53 server. So informing it= of the availability of this service makes sense.  A DNS resolver that= is configured with a DoH server ought not to replace that DoH server with one advertised by DHCP, because that w= ould be an obvious way to violate the user=92s privacy. So if we were to sp= ecify such an option, I would expect the applicability statement to say thi= s clearly. And if it didn=92t, an implementation that I did would still ignore the DHCP option if there was already an expl= icit DoH server configured. It=92s hard to imagine an implementor of this D= HCP option popping up a dialog to ask the user what to do when there is a c= onflict.

But the express purpose of the error message is to inform t= he user, so an implementation necessarily has to pop up a dialog, or in som= e other way inform the user.  That is how the two things are different= .

--_000_DM6PR00MB078103C208E50E21FB4E3874FA490DM6PR00MB0781namp_-- From nobody Fri Aug 7 11:47: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 E134C3A0D94 for ; Fri, 7 Aug 2020 11:47:47 -0700 (PDT) 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 BDp4R_YzLORk for ; Fri, 7 Aug 2020 11:47:46 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 C2F093A0D5F for ; Fri, 7 Aug 2020 11:47:46 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id l15so2632048ils.2 for ; Fri, 07 Aug 2020 11:47:46 -0700 (PDT) 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=ejc/wT+tfWnSqlUTG8Wk7GX5130Fsz8MozdZqk1ZKNk=; b=MiC1tDvif9P7CD7oKer03KvJc9PgvK4K/TairZXfS5yP+kFIDLWDJKMCmEDdr0H2eH N9EOTLUy7lwhyy9hNeVt1quJ3KJgdnmhxCIXYxRFUCcgSek+XXPF2YAkdIzyXiNxiABl 7cOwsTWQ5x/6mXINKU2jj/obQ2RTlTw4JQQhwLkeIpROVIyFV2RMsj6jqBA8lQ9xpeVY 2ntLJphRbabKItKIRAZNifcAlvYLoOQMNwvySw3Ifzm3lYQAMr0mIHiPgwQiTTr50J5s gGVrQFAEbnU4GbO8iPcCRT1W/8vkmh6fRVnuaYOr60yhCDJnk6uM3kU7f2mpynji6vJM BoUA== 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=ejc/wT+tfWnSqlUTG8Wk7GX5130Fsz8MozdZqk1ZKNk=; b=jG5DeD9uVRPzWOx6bfxoM28AsMzhP4hfXmezRuUzfg+pUBeJTK7Fzp2k1LAhCirGda VjvIIP7bGU8/bwJ/+UdmY/2WF+G1VjJ82g2pMe6GAIbYTVjawGFDYhlcyBtoaXv/kmI2 MF76WfTZ+1aohqqNtWDkvjwBTSMN/KBVe0N3/7Ew+y1cET9sOMB1osUR/P8NbHrtlBxu j5c760VRefl5IAHUGWNiJZmFKgEZvvw615uBXNyYgOY4x4XHHT5IZrRpp3voU3GsivWs N6Zn4dF4nzgHnFhoHB322w0lmA3jvY6gddGaBh5gsb6AshHDlH4/+QHSsBcr3F8rjxL9 SIFg== X-Gm-Message-State: AOAM531sUT5xpxupa9DvKyZX9xTTtNd9AF31nNYFH14XQ1ImUC8AxHru 9MSaW1GHUz3NNnFUf11vIiYuszF2j8sp8sr9i0A= X-Google-Smtp-Source: ABdhPJyFMXzc2BiIGw14V7WdNdEZ6tC2RNrEzCPMMuf6nStQpsfSaIP13zR/SJLpYwcu2yj/4pO0hc+ojzZSXuBGCGs= X-Received: by 2002:a05:6e02:1212:: with SMTP id a18mr5940530ilq.73.1596826065948; Fri, 07 Aug 2020 11:47:45 -0700 (PDT) MIME-Version: 1.0 References: <6975870.lmG34PBWiJ@linux-9daj> <2736542.fsHRET1YXo@linux-9daj> <67FFA539-EEC2-4F2A-B1F4-9118E4026E2C@fugue.com> <54D54CAE-A401-44A7-A459-EAF5275ECCA4@fugue.com> In-Reply-To: From: Rob Sayre Date: Fri, 7 Aug 2020 11:47:34 -0700 Message-ID: To: Tommy Jensen Cc: Ted Lemon , Eric Orth , ADD Mailing list , Paul Vixie Content-Type: multipart/alternative; boundary="0000000000006dd7d405ac4e0a83" Archived-At: Subject: Re: [Add] [EXTERNAL] Re: Requirements drafts 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: Fri, 07 Aug 2020 18:47:48 -0000 --0000000000006dd7d405ac4e0a83 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 7, 2020 at 11:38 AM Tommy Jensen wrote: > I think of this difference Ted is highlighting as "network recommendation" > versus "network requirement". The former has existed for classic DNS in > DHCP for a long time, and the latter as of yet does not exist for DNS > servers. > You mean "DoH servers" at the end I think, and I agree that advertising a DoH or DoT server is not a regression. It's not clear how some of these resolvers are going to provide a certificate. Maybe we'll see more PSK traffic on LANs. > > I agree with Ted: offering network recommendations of DoH servers make > perfect sense. It brings DoH use up to parity with classic DNS use. > Offering network requirements for DoH I consider to be beyond WG scope as > it is a subset of the network requirements problem which is unsolved for > clients with no prior knowledge of the network. > Sorry for the "+1" message, but +1. thanks, Rob --0000000000006dd7d405ac4e0a83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 7, 2020 at 11:38 AM Tommy Jen= sen <Jensen.Thomas=3D4= 0microsoft.com@dmarc.ietf.org> wrote:
I think of this difference Ted is highlighting as "network recommendat= ion" versus "network requirement". The former has existed fo= r classic DNS in DHCP for a long time, and the latter as of yet does not ex= ist for DNS servers.

You mean &= quot;DoH servers" at the end I think, and I agree that advertising a D= oH or DoT server is not a regression. It's not clear how some of these = resolvers are going to provide a certificate. Maybe we'll see more PSK = traffic on LANs.
=C2=A0

I agree with Ted: offering network recommendations of DoH servers make perf= ect sense. It brings DoH use up to parity with classic DNS use. Offering ne= twork requirements for DoH I consider to be beyond WG scope as it is a subs= et of the network requirements problem which is unsolved for clients with no prior knowledge of the network.=C2= =A0

Sorry for=C2=A0the "+1= " message, but=C2=A0+1.

thanks,
Rob=

--0000000000006dd7d405ac4e0a83-- From nobody Fri Aug 7 12:50:29 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 C7F7A3A0F93 for ; Fri, 7 Aug 2020 12:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 hWZ2jt2T9Z8B for ; Fri, 7 Aug 2020 12:50:27 -0700 (PDT) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (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 C92893A0F8F for ; Fri, 7 Aug 2020 12:50:26 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id a14so2699133wra.5 for ; Fri, 07 Aug 2020 12:50:26 -0700 (PDT) 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=xmX86Hu7qYjVJmXFI0JxPaDld4XrLvaRhFjQ8uavfdE=; b=Scd+uO2RjZTWVitkDJ6QWLKV5g4nvZ3HLNbHdCgdqq239ygw99WwfjLhJHm9WfCsZT HGnkTbmuw8MTBDABIcT6eKP6dj5y79LsvN+rWfVN/uUd+PF8jhrAHgU7/T39qkK0LvRI T0wkquAus1RNMUqitYZEbbkIjDgoHxy9gbo7fJuxazZjyGnvMYmmV9He+G6RRkzsXNDc P29NE8S9zMZOUgtlLqn7aJX6U24TK0c5W4lbXdwxGJAlNNiQjd0O99VZ2NzwyYS+GL6o xwFZ0+uLjCWK8jfn+mq/yEM3mTCCot9zvjZQEBYQqNEJ/qhuVyVqGNVbK3LT4rlCXwip 09AQ== 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=xmX86Hu7qYjVJmXFI0JxPaDld4XrLvaRhFjQ8uavfdE=; b=Zkrkmh6MbnA2RRxT9i3t4H0DALIqUTk5s16x5mpoQ5hcyVmvQ08Bj/hpTz79uTvC27 /zuaNI7mBuVOxMHxYEYPWeKwdFwkZWvR6Gsc4Bs5YP0pSiovgfGsvoRvmPLFzFGmfa7U brxLKb31i+b5VybjJTfUbL+Rf69/axaClYFdS9fZOiYfrPx/A1XMhH+492gTaXdN+/sH P8Yo/Z1+AnAhtsfbjBkmJV0SN3ZnwwnaN2CgAzZi0oha/Lc6sSqdKIjnmU+pzhlxxNRH iUt4xsYsItiSF0+PL+doyIXmk/u7tApAP4JfUBEEgquQu+0gUmu23DHJVKgIZkuwic5C nL1Q== X-Gm-Message-State: AOAM530mcdaTJssfrrpSCG17XCHLale5v3nP2UKxwTV5nr5cCBFjJVkA cxq8tmmU/zQ1sISCHXeTJTCxeK6ARACMvmGQGNrx9Q== X-Google-Smtp-Source: ABdhPJzbJvnvteq7YPLq+LS8f805RnlfGGIxra1TcpwX+9wvjuZ3SlDuBqVdFquwCqYkXCmJvrW46J5YtGkitSU+n7I= X-Received: by 2002:adf:b34a:: with SMTP id k10mr13166754wrd.402.1596829824963; Fri, 07 Aug 2020 12:50:24 -0700 (PDT) MIME-Version: 1.0 References: <6975870.lmG34PBWiJ@linux-9daj> <2736542.fsHRET1YXo@linux-9daj> <67FFA539-EEC2-4F2A-B1F4-9118E4026E2C@fugue.com> <54D54CAE-A401-44A7-A459-EAF5275ECCA4@fugue.com> In-Reply-To: From: Eric Orth Date: Fri, 7 Aug 2020 15:50:13 -0400 Message-ID: To: Rob Sayre Cc: Tommy Jensen , Ted Lemon , ADD Mailing list , Paul Vixie Content-Type: multipart/alternative; boundary="0000000000007c73b905ac4eeabf" Archived-At: Subject: Re: [Add] [EXTERNAL] Re: Requirements drafts 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: Fri, 07 Aug 2020 19:50:29 -0000 --0000000000007c73b905ac4eeabf Content-Type: text/plain; charset="UTF-8" I do not believe there is any practical distinction between "network recommendations" and "network requirements" unless the client chooses to follow the requirements or the network chooses to attempt to enforce its requirements. Maybe good for the network to specify that it considers something to be a requirement and I especially like the idea of networks specifying whether or not they will attempt to enforce requirements. Any mandates of clients following "requirements" are obviously out-of-scope for the WG and unenforceable by IETF, but I don't think anybody has seriously suggested doing that. Any mandates of networks not attempting to enforce requirements are similarly out of scope, and much as I would prefer they didn't, I assume some networks will. Some scenarios I can think of where general-purpose clients may want to use those network-provided signals: - If the client detects that DoH does not work and may be being blocked by the network, the client may want to check for a "DoH is disallowed on this network and we will attempt to enforce that" signal or maybe an "only DoH provider X is allowed on this network" signal. That can allow the client to provide better error messages, informing the user of what is going on. - If the user is taking action to manually change configuration (e.g. using a client settings UI), some clients may find it reasonable at that time to inform the user of the network-provided recommendations or "requirements". Maybe even more powerful if combined with test queries to determine if non-recommended configurations are functional. There was a comment above about clients responding to network preference signals by popping up a dialog to the user about it. Sounds like a problematic UX that I don't see any general-purpose client implementing, but if some client wants to, out of scope for the WG to say that they can't. --0000000000007c73b905ac4eeabf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do not believe there is any practical d= istinction between "network recommendations" and "network re= quirements" unless the client chooses to follow the requirements or th= e network chooses to attempt to enforce its requirements.=C2=A0 Maybe good = for the network to specify that it considers something to be a requirement = and I especially like the idea of networks specifying whether or not they w= ill attempt to enforce requirements.=C2=A0 Any mandates of clients followin= g "requirements" are obviously out-of-scope for the WG and unenfo= rceable by IETF, but I don't think anybody has seriously suggested doin= g that.=C2=A0 Any mandates of networks not attempting to enforce requiremen= ts are similarly out of scope, and much as I would prefer they didn't, = I assume some networks will.

Some scen= arios I can think of where general-purpose clients may want to use those ne= twork-provided signals:
  • If the client detects that DoH do= es not work and may be being blocked by the network, the client may want to= check for a "DoH is disallowed=C2=A0on this network and we will attem= pt to enforce that" signal or maybe an "only DoH provider X is al= lowed on this network" signal.=C2=A0 That can allow the client to prov= ide better error messages, informing the user of what is going on.
  • = If the user is taking action to manually change configuration (e.g. using a= client settings UI), some clients may find it reasonable at that time to i= nform the user of the network-provided recommendations or "requirement= s".=C2=A0 Maybe even more powerful if combined with test queries to de= termine if non-recommended configurations are functional.
The= re was a comment above about clients responding to network preference signa= ls by popping up a dialog to the user about it.=C2=A0 Sounds like a problem= atic UX that I don't see any general-purpose client implementing, but i= f some client wants to, out of scope for the WG to say that they can't.=
--0000000000007c73b905ac4eeabf-- From nobody Fri Aug 7 14:11: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 43B243A0AF1 for ; Fri, 7 Aug 2020 14:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 wNvv5WjEoHfp for ; Fri, 7 Aug 2020 14:10:59 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 422773A0ABA for ; Fri, 7 Aug 2020 14:10:59 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id k8so3068144wma.2 for ; Fri, 07 Aug 2020 14:10:59 -0700 (PDT) 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=CKIj8KNdogWzfO9sYtc2O/uyWZMDlA9DozonL8hKctg=; b=oiQhBPVh0uf7H0rh+Aa03h1SUb8wgFwCccSS1VBbry1AF1OqFS0tP6yuB5U9F/1ihu ZvwPvl42sSkGKkDNLQUBd+0hn6eOZ8udBrlsQbBFfqhkbBdRH5rZhyMUc2xHjw5kTEiS u2UhE+E/gBGxWlQWNZ5dBMl+19zhqxWfPum/I3lGg5zf/QCs5WUDNkw9Rr/vYQAD4LkZ q8z1347wQyFcA7SayaxedFalE8+JC/A5pecE/0GjJqRANPn3oLtavBCYr+HWzXG7H6JX 2+lMvuqtzM2YE419NbbS3xUF1ukM0ZUlSDAdwygBnNaIQb3xLgTH2VKkJ944deDXpU6R Dj+Q== 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=CKIj8KNdogWzfO9sYtc2O/uyWZMDlA9DozonL8hKctg=; b=YCH/04qAq0dyB6QuqLNEDsX99Jl4D/4dagyrEAE94gz2tKvEyxnM17ZHwzspgEaF1k BDD+BN83s73lBXb0Ppd3JtoYCdo4iE7Jgfhtrscx8427WtH5dwQjNVOZ48ekzPVpWv/K KQSpVrN3NdV7RpF3XQK9DHbIC3Tim89dZFhDol8zxuFd6pjCTiwbzzTwBr9sCHeV/7zX yjsdwhmkjHCkoAsnXCpdmMiqlQvrmeKZdtPbdFQosI9uswQvdc4hOLpq0KaBl8stzODO JD2aO0vcyMuw2oP++ChRLIS5n2kN6OswFa6zNV6s85kd73ivLJky3ht/l0tmcQg3eenq n71g== X-Gm-Message-State: AOAM531iFaJOqi7uwCXSfPAeyu2ZVho+43V68I9ptExhZ9oSp3XpAR9C R0oT2UH5g5VCPsxiKaEmaphJdzzLXv4fyA1hbrgwoQ== X-Google-Smtp-Source: ABdhPJxZuu0RzkUW9pe7fKbF+XBFk01Lp+kyxzZ1a0GmJhjHu7f1SpEYv59KnC7x/3s03DKUYAIf3+v9PeOnv4fmgyg= X-Received: by 2002:a1c:3dd6:: with SMTP id k205mr14308287wma.21.1596834657527; Fri, 07 Aug 2020 14:10:57 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> In-Reply-To: From: Eric Orth Date: Fri, 7 Aug 2020 17:10:46 -0400 Message-ID: To: Ben Schwartz Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000087654305ac500a01" Archived-At: Subject: Re: [Add] New Version Notification for draft-schwartz-svcb-dns-00.txt 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: Fri, 07 Aug 2020 21:11:01 -0000 --00000000000087654305ac500a01 Content-Type: text/plain; charset="UTF-8" I like the idea overall, but can you further explain the decision to use dns: URIs to describe DNS servers? Seems a bit funky since that URI scheme is designed for DNS data, not a DNS server. What we want here seems to match more with just the optional "authority" section of a dns: URI. Do we need a new URI scheme for DNS servers? Wasn't there a recent proposal for that? On Tue, Aug 4, 2020 at 8:41 PM Ben Schwartz wrote: > Moving DPRIVE and DNSOP to BCC to avoid cross-posting. > > On Tue, Aug 4, 2020 at 1:53 PM Ben Schwartz > wrote: > >> Hi ADD and DPRIVE, >> >> I've noticed three recent drafts that propose to use the SVCB format: >> draft-mglt-add-rdp, draft-tapril-ns2, and >> draft-pauly-add-resolver-discovery. These drafts, across multiple >> working groups, consider distinct use cases and architectures, but they all >> propose using SVCB (in very different ways) to convey information about a >> DNS server that supports encrypted transport. >> >> In the interest of harmonizing these proposals, creating a solid >> foundation, and separating concerns, I've written a short draft that >> specifies _only_ a minimal SVCB mapping for DNS URIs*, and does not address >> any specific use case. >> >> I hope this draft can enable each of these proposals to focus more on >> their goals, and worry less about the SVCB encoding. (It also serves as an >> interesting test of the SVCB design.) >> >> Please review, >> Ben Schwartz >> >> *SVCB is based on URIs like https://, so for a DNS mapping we start with >> dns:// URIs. >> >> ---------- Forwarded message --------- >> From: >> Date: Tue, Aug 4, 2020 at 1:38 PM >> Subject: New Version Notification for draft-schwartz-svcb-dns-00.txt >> To: Benjamin Schwartz >> >> >> >> A new version of I-D, draft-schwartz-svcb-dns-00.txt >> has been successfully submitted by Benjamin Schwartz and posted to the >> IETF repository. >> >> Name: draft-schwartz-svcb-dns >> Revision: 00 >> Title: Service Binding Mapping for DNS URIs >> Document date: 2020-08-04 >> Group: Individual Submission >> Pages: 8 >> URL: >> https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-00.txt >> Status: https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/ >> Htmlized: https://tools.ietf.org/html/draft-schwartz-svcb-dns-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns >> >> >> Abstract: >> The SVCB DNS record type expresses a bound collection of endpoint >> metadata, for use when establishing a connection to a named service. >> DNS itself can be such a service, when the server is identified by a >> hostname in a "dns:" URI. This document provides the SVCB mapping >> for name-based DNS URIs, allowing DNS servers to indicate support for >> new transport protocols. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000087654305ac500a01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like the idea overall, but can you further explain the d= ecision to use dns: URIs to describe DNS servers? Seems a bit funky since t= hat URI scheme is designed for DNS data, not a DNS server.=C2=A0 What we wa= nt here seems to match more with just the optional "authority" se= ction of a dns: URI.

Do we need a new URI scheme for DNS= servers? Wasn't there a recent proposal for that?

On Tue, Aug 4, = 2020 at 8:41 PM Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:
Moving DPRIVE and= DNSOP to BCC to avoid cross-posting.

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Aug 4, 2020 at 1:53 PM Ben Sch= wartz <bemasc@go= ogle.com> wrote:
Hi ADD and DPRIVE,

I've not= iced three recent drafts that propose to use the SVCB format: draft-mglt-ad= d-rdp, draft-tapril-ns2, and draft-pauly-add-resolver-discovery.=C2=A0 Thes= e drafts, across multiple working=C2=A0groups,=C2=A0consider distinct use c= ases and architectures, but they all propose using SVCB (in very different = ways) to convey information about a DNS server that supports encrypted tran= sport.

In the interest of harmonizing these propos= als, creating a solid foundation, and separating concerns, I've written= a short draft that specifies _only_ a minimal SVCB mapping for DNS URIs*, = and does not address any specific use case.

I = hope this draft can enable each of these proposals to focus more on their g= oals,=C2=A0and worry less about the SVCB encoding.=C2=A0 (It also serves as= an interesting test of the SVCB design.)

Plea= se review,
Ben Schwartz

*SVCB is based on URIs like https://, so for a = DNS mapping we start with dns:// URIs.
<= /div>

---------- Forwarded message ---------
From: <= internet-draf= ts@ietf.org>
Date: Tue, Aug 4, 2020 at 1:38 PM
Subject:= New Version Notification for draft-schwartz-svcb-dns-00.txt
To: Benjami= n Schwartz <bemas= c@google.com>



A new version of I-D, draft-schwartz-svcb-dns-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-svcb-dns
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Service Binding Mapping for DNS UR= Is
Document date:=C2=A0 2020-08-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-0= 0.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-schwartz-svcb-dns-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns


Abstract:
=C2=A0 =C2=A0The SVCB DNS record type expresses a bound collection of endpo= int
=C2=A0 =C2=A0metadata, for use when establishing a connection to a named se= rvice.
=C2=A0 =C2=A0DNS itself can be such a service, when the server is identifie= d by a
=C2=A0 =C2=A0hostname in a "dns:" URI.=C2=A0 This document provid= es the SVCB mapping
=C2=A0 =C2=A0for name-based DNS URIs, allowing DNS servers to indicate supp= ort for
=C2=A0 =C2=A0new transport protocols.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000087654305ac500a01-- From nobody Fri Aug 7 20:11: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 B01243A0B9C for ; Fri, 7 Aug 2020 20:11:36 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 4O98_sapn_0s for ; Fri, 7 Aug 2020 20:11:35 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 AB5E03A0B90 for ; Fri, 7 Aug 2020 20:11:35 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id i15so2668492ils.9 for ; Fri, 07 Aug 2020 20:11:35 -0700 (PDT) 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=Mt5pxsoXzurLOkwgnVuveOxJWapFl1e4F4SLrY/fSYI=; b=na8QPTKWLuY1o/XSDLSVlKMBy72NbANPu+yJCp0zhbpjHG8os9Q/rCnvJYVIypJpZP AOoU8ATWQsosLgqM0AUD0lC/cY21Q6QMpbBWR+vduI8pB8Y6s0Gg15ctpub4m2fDJjJF OtSZoDC+TgHaPGxPwH0wN8Lg49Tl1NPmrV8Y+gE/oUg/Do+h4gTNASbenc3C1Ch4riXE l3Gctes9G27TV5NR5fwt5RNssXhWaz+JAVZ+60rK8kO2C122ctjfAyBLCWd8o+zxkveY NVeArZct5rcxSUzWom0Kd+P1yXUcfVKAs0MPQKE2bME7rbVRmAkhUQgyz0sCfzAXW8ze ooAQ== 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=Mt5pxsoXzurLOkwgnVuveOxJWapFl1e4F4SLrY/fSYI=; b=GPpCpx9/F/xd82E2679HdmYbCIDAnevrOJUTOt68wlMhgHwfPJCRKWrn97KnWAzKgT M1l5NvOznklQUtIcRAYxLb/HVoPhgxl9KlYkgSZgeWtD2F5lDzJuzCaOCuwNjihlvmhz asmpI5P2H11fE23F5EkKuuWpOF4/dTgOB6pCxexl9ttEk3jybF2f5HpnMIG5xW07R2j3 u7e1OCwVPXVHR/T8ALwOodaLeKr46ehVSiPo6CL1Tp6uiFMIabFHacvPStOmLLFud/g6 CXm9yZ40zldCW3UK4bdC+u4zRiy3gBXi7J9J7h+Eh/Fq+f5dvQ/4WoBG3IxypsC5mJtT SDAw== X-Gm-Message-State: AOAM533XEQBK7rnwILlRTA4VC77O8FiAn6UaF45y9nDLJWgXWhbpy5eF l6ChVgnloLc2pq0y2AAVbMqfA9JhCcQg9kbtSdqGWjRLI5Y= X-Google-Smtp-Source: ABdhPJwt2M8djhhvHahL5n+ePhMIXVWqVnK6/+6vrEFaGTi0JfqZhxALKFzcK/TncXPM4ewQIFct1BdeLpKR8h58lPk= X-Received: by 2002:a92:5a90:: with SMTP id b16mr7227882ilg.189.1596856295029; Fri, 07 Aug 2020 20:11:35 -0700 (PDT) MIME-Version: 1.0 References: <6975870.lmG34PBWiJ@linux-9daj> <2736542.fsHRET1YXo@linux-9daj> <67FFA539-EEC2-4F2A-B1F4-9118E4026E2C@fugue.com> <54D54CAE-A401-44A7-A459-EAF5275ECCA4@fugue.com> In-Reply-To: From: Rob Sayre Date: Fri, 7 Aug 2020 20:11:23 -0700 Message-ID: To: Eric Orth Cc: Tommy Jensen , Ted Lemon , ADD Mailing list , Paul Vixie Content-Type: multipart/alternative; boundary="00000000000038ff9505ac551414" Archived-At: Subject: Re: [Add] [EXTERNAL] Re: Requirements drafts 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, 08 Aug 2020 03:11:37 -0000 --00000000000038ff9505ac551414 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 7, 2020 at 12:50 PM Eric Orth wrote: > I do not believe there is any practical distinction between "network > recommendations" and "network requirements" > I agree with this sentiment. As long as there are no MUST/SHALL/REQUIRED rules on clients, it seems like agreeing on things for the network to send could be productive. thanks, Rob --00000000000038ff9505ac551414 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 7, 2020 at 12:50 PM Eric Orth= <ericorth@google.com> wro= te:
I do not believe there is = any practical distinction between "network recommendations" and &= quot;network requirements"

I agree with this sentiment. As long as there are no MUST/SHALL/REQUIRED r= ules on clients, it seems like agreeing on things for the network to send c= ould be productive.

thanks,
Rob

--00000000000038ff9505ac551414-- From nobody Sun Aug 9 12:03:23 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 9F8423A0C48 for ; Sun, 9 Aug 2020 12:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 ow3yWg1uLrI8 for ; Sun, 9 Aug 2020 12:03:19 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 704A23A0C47 for ; Sun, 9 Aug 2020 12:03:19 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id k20so6378164wmi.5 for ; Sun, 09 Aug 2020 12:03:19 -0700 (PDT) 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=TD5T3CBG/6V7cCX8qy1QxQIPn7rcEwzsDSpvXYfYpPY=; b=CoJNvnWyFQFUi6nbuMjD1xRMfKm05UaN2wIjurw3kjTakGqikDvQ4gQQ7mSs7fkaC2 +2JVjUNqBhx2bE89YPQpfvdDdtu0mUJpfQH9oGDxkBYhZw8hAkDuOaSsgapBGun3SEQo tr1rwOnxKDyC/n+uanIiRcT0KYrlNWRn3tZ/yV0wNDcD2R9AYU+yPDDkrLG24XJB/CHY AfOLBtuggy65//wA5/hYrrf5YuVzNkzQRcABQQVM1AmKJ4xoc0zL73cnueHLo+I+veKv pI4JEH9NYUmjiqxEiAYw3edpGtLsXYzZiE2skLTdSecaj9eXzNNaW3M2kA59CfMCfGTs TJ7A== 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=TD5T3CBG/6V7cCX8qy1QxQIPn7rcEwzsDSpvXYfYpPY=; b=A44uNqoqWRVDfMrJLT91pEXZH8j5hfv6hwwN0kpyMK7v5PPRhy4z9sJjsc88VIn2FD /lR2C6mGN37ZGGy2E984RouLeKs7QqZ6AMVj9+NUOvYc1YP4N5TsQuP0eISAZsCRhdG9 0E3blvsGnLMUYYN57GiZRVW/SRoXQDYQHYkwubxGAs4HIZTw/JiTrhJCj4BeO987c0o5 r+CB2PA1bbrqp0KsoBlMFLqhZCgqnaBIHgNnvl0PAFbbK24r9LSFYrcrflqRc7r5aPSX tem4DL9ynDEwvQKKXjGJKO8gUnTmh839raMlJXkIrnIqROwA0RzLQY7JZrqP/EoeSVFD lkcA== X-Gm-Message-State: AOAM531weKJ4bXVjhM7N3mYIuHpm6kv9mbgKTlkbUHfcgpPK9eS02ns9 a3G/onY6Q8a1nxR43XyalmjqrandCgwtTcfziiVbJLGDbRY= X-Google-Smtp-Source: ABdhPJzMHZ77BNFFIhVrTwF0vWYY6FsS80mFtpKl0dSI7pcDBAHdZC4FSLHmn2bNmq2bsjL4fGzMqUNn8yuSoK420t8= X-Received: by 2002:a1c:a757:: with SMTP id q84mr21014292wme.1.1596999797573; Sun, 09 Aug 2020 12:03:17 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> In-Reply-To: From: Ben Schwartz Date: Sun, 9 Aug 2020 15:03:05 -0400 Message-ID: To: Eric Orth Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000ac182105ac767d06" Archived-At: Subject: Re: [Add] New Version Notification for draft-schwartz-svcb-dns-00.txt 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, 09 Aug 2020 19:03:22 -0000 --000000000000ac182105ac767d06 Content-Type: multipart/alternative; boundary="000000000000a47af205ac767de7" --000000000000a47af205ac767de7 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 7, 2020 at 5:11 PM Eric Orth wrote: > I like the idea overall, but can you further explain the decision to use > dns: URIs to describe DNS servers? > I wouldn't say that's what's happening here. The SVCB/HTTPS record describes a way to perform connection establishment when attempting to retrieve a resource by its URI. (Use of a URI with SVCB is recommended but not required.) The SVCB draft only defines a mapping for "http://" and "https://" URIs; this draft provides the mapping for "dns://". For both "https://" and "dns://" URIs, SVCB serves the same function: the URI provides an authority, and SVCB provides some information on how to enhance your connection to that authority, in pursuit of the indicated resource. Ultimately, the client must want to access some resource (i.e. an HTTP resource or a DNS record, indicated by the URI's path in both cases), or there's no need to connect to the authority at all. In truth, I don't think the "dns: URI" part is really important here; it's mostly just a nice conceptual framework for the draft. The real question is: if we distribute information in this form, will it work well as a component of the systems we're trying to build? Seems a bit funky since that URI scheme is designed for DNS data, not a DNS > server. What we want here seems to match more with just the optional > "authority" section of a dns: URI. > Yes; this is the SVCB design generally. Note that the "authority" section is also optional in "https" URIs. Do we need a new URI scheme for DNS servers? Wasn't there a recent proposal > for that? > I believe those proposals are principally inspired by DNS Stamps https://dnscrypt.info/stamps-specifications. With SVCB, the URI (normally) identifies the authority by name, and the protocol is negotiated at connection time. With DNS Stamps, all protocol and connection parameters are encoded into the URI itself. I think the SVCB approach is more suitable for our purposes, because it separates the simple, important question (who am I sending queries to?) from the complicated, boring question (how do I perform connection establishment?). This is similar to HTTPS: I wouldn't want to encode QUIC vs. TLS, or ECH public keys, into the HTTPS URI, where the info could get out of sync or distract from the important question (who is the authority?). On Tue, Aug 4, 2020 at 8:41 PM Ben Schwartz 40google.com@dmarc.ietf.org> wrote: > >> Moving DPRIVE and DNSOP to BCC to avoid cross-posting. >> >> On Tue, Aug 4, 2020 at 1:53 PM Ben Schwartz > > wrote: >> >>> Hi ADD and DPRIVE, >>> >>> I've noticed three recent drafts that propose to use the SVCB format: >>> draft-mglt-add-rdp, draft-tapril-ns2, and >>> draft-pauly-add-resolver-discovery. These drafts, across multiple >>> working groups, consider distinct use cases and architectures, but they all >>> propose using SVCB (in very different ways) to convey information about a >>> DNS server that supports encrypted transport. >>> >>> In the interest of harmonizing these proposals, creating a solid >>> foundation, and separating concerns, I've written a short draft that >>> specifies _only_ a minimal SVCB mapping for DNS URIs*, and does not address >>> any specific use case. >>> >>> I hope this draft can enable each of these proposals to focus more on >>> their goals, and worry less about the SVCB encoding. (It also serves as an >>> interesting test of the SVCB design.) >>> >>> Please review, >>> Ben Schwartz >>> >>> *SVCB is based on URIs like https://, so for a DNS mapping we start >>> with dns:// URIs. >>> >>> ---------- Forwarded message --------- >>> From: >>> Date: Tue, Aug 4, 2020 at 1:38 PM >>> Subject: New Version Notification for draft-schwartz-svcb-dns-00.txt >>> To: Benjamin Schwartz >>> >>> >>> >>> A new version of I-D, draft-schwartz-svcb-dns-00.txt >>> has been successfully submitted by Benjamin Schwartz and posted to the >>> IETF repository. >>> >>> Name: draft-schwartz-svcb-dns >>> Revision: 00 >>> Title: Service Binding Mapping for DNS URIs >>> Document date: 2020-08-04 >>> Group: Individual Submission >>> Pages: 8 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/ >>> Htmlized: https://tools.ietf.org/html/draft-schwartz-svcb-dns-00 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns >>> >>> >>> Abstract: >>> The SVCB DNS record type expresses a bound collection of endpoint >>> metadata, for use when establishing a connection to a named service. >>> DNS itself can be such a service, when the server is identified by a >>> hostname in a "dns:" URI. This document provides the SVCB mapping >>> for name-based DNS URIs, allowing DNS servers to indicate support for >>> new transport protocols. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > --000000000000a47af205ac767de7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 7, 2020 at 5:11 PM Eric Orth <= ericorth=3D40google.com@dmar= c.ietf.org> wrote:
I like the idea overall, but can you further ex= plain the decision to use dns: URIs to describe DNS servers?

I wouldn't say that's what's happening = here.

The SVCB/HTTPS record describes a way to per= form connection establishment when attempting to retrieve a resource by its= URI.=C2=A0 (Use of a URI with SVCB is recommended but not required.)=C2=A0= The SVCB draft only defines a mapping for "http://" and "ht= tps://" URIs; this draft provides the mapping for "dns://".<= /div>

For both "https://" and=C2=A0"dns:/= /" URIs, SVCB serves the same function: the URI provides an authority,= and SVCB provides some information on how to enhance=C2=A0your connection = to that authority, in pursuit of the indicated resource.=C2=A0 Ultimately, = the client must want to access some resource (i.e. an HTTP resource or a DN= S record, indicated by the URI's path in both cases), or there's no= need to connect to the authority at all.

In truth= , I don't think the "dns: URI" part is really important here;= it's mostly just a nice=C2=A0conceptual framework for the draft.=C2=A0= The real question is: if we distribute information in this form, will it w= ork well as a component of the systems we're trying to build?

Seems a bit funky since that URI schem= e is designed for DNS data, not a DNS server.=C2=A0 What we want here seems= to match more with just the optional "authority" section of a dn= s: URI.

Yes; this is the SVCB design = generally.=C2=A0 Note that the "authority" section is also option= al in "https" URIs.

Do we need a new URI scheme = for DNS servers? Wasn't there a recent proposal for that?

I believe those proposals are principally in= spired by DNS Stamps=C2=A0https://dnscrypt.info/stamps-specifications. With SVCB, the URI = (normally) identifies the authority by name, and the protocol is negotiated= at connection time.=C2=A0 With DNS Stamps, all protocol and connection par= ameters are encoded into the URI itself.

I think t= he SVCB approach is more suitable for our purposes, because it separates th= e simple, important question (who am I sending queries to?) from the compli= cated, boring question (how do I perform connection establishment?).=C2=A0 = This is similar to HTTPS: I wouldn't want to encode QUIC vs. TLS, or EC= H public keys, into the HTTPS URI, where the info could get out of sync or = distract from the important question (who is the authority?).
On Tue, Aug 4, 2020 at 8:41 = PM Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:
Moving DPRIV= E and DNSOP to BCC to avoid cross-posting.

On Tue, Aug 4, 2020 at 1:53 PM Be= n Schwartz <bema= sc@google.com> wrote:
Hi ADD and DPRIVE,

I'v= e noticed three recent drafts that propose to use the SVCB format: draft-mg= lt-add-rdp, draft-tapril-ns2, and draft-pauly-add-resolver-discovery.=C2=A0= These drafts, across multiple working=C2=A0groups,=C2=A0consider distinct = use cases and architectures, but they all propose using SVCB (in very diffe= rent ways) to convey information about a DNS server that supports encrypted= transport.

In the interest of harmonizing these p= roposals, creating a solid foundation, and separating concerns, I've wr= itten a short draft that specifies _only_ a minimal SVCB mapping for DNS UR= Is*, and does not address any specific use case.

I hope this draft can enable each of these proposals to focus more on th= eir goals,=C2=A0and worry less about the SVCB encoding.=C2=A0 (It also serv= es as an interesting test of the SVCB design.)

Please review,
Ben Schwartz

*SVCB is based on URIs like https://, so for a DNS mapping we= start with dns:// URIs.

=
----------= Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Aug 4, 2020 at 1:38 PM
Subject: New Version N= otification for draft-schwartz-svcb-dns-00.txt
To: Benjamin Schwartz <= ;bemasc@google.com>



A new version of I-D, draft-schwartz-svcb-dns-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-svcb-dns
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Service Binding Mapping for DNS UR= Is
Document date:=C2=A0 2020-08-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-0= 0.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-schwartz-svcb-dns-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns


Abstract:
=C2=A0 =C2=A0The SVCB DNS record type expresses a bound collection of endpo= int
=C2=A0 =C2=A0metadata, for use when establishing a connection to a named se= rvice.
=C2=A0 =C2=A0DNS itself can be such a service, when the server is identifie= d by a
=C2=A0 =C2=A0hostname in a "dns:" URI.=C2=A0 This document provid= es the SVCB mapping
=C2=A0 =C2=A0for name-based DNS URIs, allowing DNS servers to indicate supp= ort for
=C2=A0 =C2=A0new transport protocols.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000a47af205ac767de7-- --000000000000ac182105ac767d06 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCDMeGeNYkdq4WeLmNLJ/YajdQhVZc5b3YrOR5oPAasDqDAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA4MDkxOTAzMThaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAP7TJKVqmwKQZPLhSUlXR59NNjZPyayy1WWKI8Enm/9QdxLlEbxEY/iZmOwB1ietpQ6jIb9GI SSuzRUOv8k4SYlazYVPtBp4/+ZaqGGHgb1iYIXSP43e52N8Nq5/8/vKHnBHvznauE4eCWd7Uhv8Z ndaKYCdNdf0n9gh/+ZWtAUOQSNRvR8MhkTOm6LuI7CIH10DBXx5MSUuAOjoYac0wrS2UCmIoVgaK 4w8joQGsgXj0jWaFOPGdF5ygcjdNdQfUWKTDJNpvH/dyNmKeMM1Z6+Vq2gBZCOXvXtUjhU4MaE2D 6e03wI8Vzp1zGuTlyQ9YGAGFobhvuGVF63Rn/dylug== --000000000000ac182105ac767d06-- From nobody Sun Aug 9 17:44: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 69A763A12DB for ; Sun, 9 Aug 2020 17:44:53 -0700 (PDT) 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, 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 (2048-bit key) header.d=lowentropy.net header.b=Dx3QeioO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UC2a2ZTG 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 lGzzu-vHp2oL for ; Sun, 9 Aug 2020 17:44:52 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DF93A12DA for ; Sun, 9 Aug 2020 17:44:51 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 15C9BE9D for ; Sun, 9 Aug 2020 20:44:51 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Sun, 09 Aug 2020 20:44:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=I6syo9uvcynDPpeTJDg89PCmPQPBJEf w/ND5Rbtb4hE=; b=Dx3QeioOMTNfuaKNJfNOo8IPAB6Zk0u+ynOG7D5zTabJUwP eXurhIhx4hLgiinefpbbp/ff5SqQWZq1nvH0cANY5DgZ/oBEF292rEWi5zzClOPD 866TJvS0GU4O7KZbJmBrkPYLNXMhQU1CAG8Cw/9Ned0tLk2xoP+xUQJ5MhLM8oEV 9agrcrtfyDG1f8bBU6C6WHCdlyW1zSrsxyx8EMyxy6XEe33BQ8oG295SmLMzxt2o OYe9KuFilTw97kCuLTV0xB8ns9fZqVUsZgh/59zfhY3Idof0Vk0g77G0qn+vMrVW 2KJ/5i7khqjdUHfUC6nk6VnriO5CH56nHw9LdTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=I6syo9 uvcynDPpeTJDg89PCmPQPBJEfw/ND5Rbtb4hE=; b=UC2a2ZTGwVIKXJZdc0S99V a/xF9lcCgThRrZEYEiR1z+RQec1dYPw2l44awWX7upd3C8nBfUNuQ0utKYREZpBq AeXO7p7OisQWEU0Ig8nsPBkdgHSvydTUZun046JZqpn5TDB8SAOrvKSULCWGUvn9 IA5IMuaYRD5UIRzCto0h7HCiagkwgme6ezyHr1CbbcNq2+EhnUXUZMwafmVmceuI CCvASM/jw79tYu5RFQzNq+esHHwswATXZryniD6qxYhTQAQ3eyPrmGW7fClQyyIl 60ZQWcKetgXZqluRBK688y7natNRxFi78sgQqhpay1lTM4rmdY8Xww3GcfMUW3Ng == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrkeejgdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnheptdefkedvhfdtvdelgedtff ffgfdugfdufedthfeujeeutdelfeeuvefgledutdehnecuffhomhgrihhnpegvgigrmhhp lhgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 75933E00A6; Sun, 9 Aug 2020 20:44:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-143-g3d58b38-fm-20200806.002-g3d58b387 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> Date: Mon, 10 Aug 2020 10:44:31 +1000 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain Archived-At: Subject: [Add] DNS URI scheme (was SVCB for DNS) 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, 10 Aug 2020 00:44:54 -0000 I wasn't going to respond and then I saw this... On Mon, Aug 10, 2020, at 05:03, Ben Schwartz wrote: > Note that the "authority" section is also optional in "https" URIs. This is not true in any way I can discern. Authority is mandatory in HTTP. But then I realized that I don't like what this draft implies. Eric's question is entirely fair. I also believe that that your response is accurate based on the definition of the dns: scheme. RFC 4501 defines the authority component as optional, and uses it to indicate a resolver. It's a little vague on this point, but it strongly implies that it refers to a recursive resolver. This is deeply awkward, because it uses URI terms to imply that the zone is not the authority for the data provided. That suits the SVCB usage perfectly here, but it completely breaks my conception of what authority in a URI is. I hope that I'm not the only one. My model for URIs says that there is an entity that controls a portion of the namespace established for the scheme. That entity is identified by the authority component. The authority gets to say whatever it likes about resources that exist in the part of the namespace it controls. It would have been clearer for me if dns://example.com/ was tied to the QNAME and the authority were the authoritative server for the name. Authority == authoritative has a nice bit of symmetry. And QNAME as authority would still allow dns:// URIs to be locators, but it would have only required either recursion or use of a recursive. And you could authenticate the results with DNSSEC. All very neat. But that's not what RFC 4501 defines. Resolver as authority is convenient for this particular use case, but it implies that the resolver somehow confers authority. That RFC 4501 fails to define a means of authenticating resolvers further undermines the utility of the scheme. I'm inclined to suggest that we NOT use dns:// URIs. Not because they aren't suitable - they fit surprisingly well to the use case - but because they are not good. From nobody Sun Aug 9 17:47: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 6E9673A12DC for ; Sun, 9 Aug 2020 17:47:38 -0700 (PDT) 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, 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 sPqiexlSl3Mn for ; Sun, 9 Aug 2020 17:47:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0513A12DB for ; Sun, 9 Aug 2020 17:47:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E4CC1389D9 for ; Sun, 9 Aug 2020 20:26:52 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zSVEcv71mPmS for ; Sun, 9 Aug 2020 20:26:52 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D1690389D2 for ; Sun, 9 Aug 2020 20:26:51 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CB7C550C for ; Sun, 9 Aug 2020 20:47:34 -0400 (EDT) From: Michael Richardson To: ADD Mailing list In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Add] Requirements drafts 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, 10 Aug 2020 00:47:39 -0000 --=-=-= Content-Type: text/plain Chris Box (BT) wrote: > I'm not especially in favour of pursuing "discover whether using a resolver > X is acceptable". A case that I was thinking about is when on trains/aircraft. You *CAN* use some external resolver, but the performance will be awful. How/do we let the network explain this? And, the situation may change after authenticating to the network and/or upgrading to the better data plan. > I think it would be better to let the client try. If it succeeds, great. If > not (because the network is denying it), we should allow the network to > explain why it is not succeeding. This is simply a usability improvement. The above is distinct from the case where national infrastructure blocks the access, and here we need to let the network explain. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8wmSYACgkQgItw+93Q 3WV+4wf/egWfKExsPegFP/lMHQr5HRJUWiFAp1sszDMEEuLYlCG4TWHFGYpxGDCI xwNdqMb9G4o9AteMLY5IuULFe6dxQOuH1vzsCpGpbFaDA4iSU3Qe59R9TYggylDQ XKyCgNadFzO1LWwbxEwHGPHvzO9cV6tptwY51SL0CI6Oj501gMN7gSiG+15/DYZn j1T/BSNoHrjxy0KEKsiQODlBrehAbRGL64O99X7k7bVaMR8rW5Ga94lgno6Tho6Q svdGzADnbPiL6D7JS39dhcjpZgiohyB9zqUGnBFAyiwW43XKi6hKLEiQ+mwaGBxK +AP0kZtL5JCXlv5/u5LrGj6VcRZbfQ== =RnOg -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 10 06:49:07 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 E9D793A1577 for ; Mon, 10 Aug 2020 06:49:05 -0700 (PDT) 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 7XPPXanGcqE9 for ; Mon, 10 Aug 2020 06:49:04 -0700 (PDT) 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 4FD743A1574 for ; Mon, 10 Aug 2020 06:49:04 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id g6so9607633ljn.11 for ; Mon, 10 Aug 2020 06:49:04 -0700 (PDT) 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=O+1BIZRgjcYi8WXL3r26k2K2nhHvN5+HIF5Vs8iwB5A=; b=txItzMV0346EFrfWwMCxGzr4K3LAGYxL4IP3rMQIAjQIABP76/ExECmxnLQMoFD1IH hNKPf8Iqoujz5vBg8eJwL6384Dp2km7mTxXtNarkk2FTkV2Eud4qOanY6xFwyY5nPOo5 5t5m1iJIu0YEHPpyjsY4a7V31HJVabZ8FBLrzXYTAMUI+ZTz6Jylqq8Y86i1MZeKtDkS s+KawPuVUMWRxt04UG7CEkZ8ETn3ZVyypoMGYlTlViEc55TCt3lYlU5+mqEz5n0j8RDI xjJIQuSUq0aBlsl4bIucai2uPH+EdV5U/pTtEY9o/AB9rEPYmBlRIO3IZZDI11TM4S5Z en7A== 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+1BIZRgjcYi8WXL3r26k2K2nhHvN5+HIF5Vs8iwB5A=; b=CDj8hmEuFaS2jbZXZnHayqAU8CjGTLnO6xa1V7gq5SNvrucE745yTp5ww22ipn5l8m yuTx/kPC4k7yfl6X7T5WAP1tF6mxrtSVHOvyIPg0JXgEFWoXwz1qaAdPwgRGlXplWkLs S6jbQbGhD/v40dmaHRxNNSEddJeXT/SEqrTii5ynkrBZRpW8B55iv7YrALImQr403oeV F88zqZWqBoNtYePoIvFaHsrpYWh/kthKWXJmEVDKGwqXCR8tMmZHQPh4NJ6Zf99NSkbd Mx6hSoWLI+cveL2FGcn3b8Gci1zC8COnkxNrdnuKzHhgXiL0TDMfpVhr6GL583149CJJ CgOg== X-Gm-Message-State: AOAM531omzwKdJJ7otNeSlMTCuTv+zMUjj9O5TxBhYocUde4hM0c8O8S WF1/YdPzxTk4znrs7ZmDyvHERRiE3LQOLSTf2/xGFFLgm48= X-Google-Smtp-Source: ABdhPJzePfvJcr/I7l2JuWqQ9o0wO57QrMZXceMBBgtQkf0fc7q8vxvF4IQcEiLIEEuo08K+OWWXEQ/z6NVq4gVNkBw= X-Received: by 2002:a2e:908a:: with SMTP id l10mr613706ljg.409.1597067342381; Mon, 10 Aug 2020 06:49:02 -0700 (PDT) MIME-Version: 1.0 References: <15378.1597020454@localhost> In-Reply-To: <15378.1597020454@localhost> From: Eric Rescorla Date: Mon, 10 Aug 2020 06:48:26 -0700 Message-ID: To: Michael Richardson Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000a01c5105ac8637d5" Archived-At: Subject: Re: [Add] Requirements drafts 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, 10 Aug 2020 13:49:06 -0000 --000000000000a01c5105ac8637d5 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 9, 2020 at 5:47 PM Michael Richardson wrote: > > Chris Box (BT) wrote: > > I'm not especially in favour of pursuing "discover whether using a > resolver > > X is acceptable". > > A case that I was thinking about is when on trains/aircraft. > You *CAN* use some external resolver, but the performance will be awful. > Is this in fact true? Back when I used to fly, I used to use DoH quite a bit as well as using browsers that were not configured with DoH and I never really noticed a material difference. -Ekr --000000000000a01c5105ac8637d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Aug 9, 2020 at 5:47 PM Michae= l Richardson <mcr+ietf@sandel= man.ca> wrote:

Chris Box (BT) <chris.box.ietf@gmail.com> wrote:
=C2=A0 =C2=A0 > I'm not especially in favour of pursuing "disco= ver whether using a resolver
=C2=A0 =C2=A0 > X is acceptable".

A case that I was thinking about is when on trains/aircraft.
You *CAN* use some external resolver, but the performance will be awful.

Is this in fact true? Back when I used to= fly, I used to use DoH quite a bit as well as
using browsers tha= t were not configured with DoH and I never really noticed a material
<= div>difference.

-Ekr

--000000000000a01c5105ac8637d5-- From nobody Mon Aug 10 07:51: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 682AE3A1658 for ; Mon, 10 Aug 2020 07:51:01 -0700 (PDT) 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, 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=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 XeaLOuMNzefb for ; Mon, 10 Aug 2020 07:51:00 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 EFA5F3A163A for ; Mon, 10 Aug 2020 07:50:59 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id j187so8517303qke.11 for ; Mon, 10 Aug 2020 07:50:59 -0700 (PDT) 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=hKtu3Gu0fAEOQgNkPYcoOIR911PSmSWBIG0ujuNx7Ds=; b=CJm4A9K0PbDOVmkoJZPvD41dRf9RIDA0YRH/E6jxNEqxIjMjCqm3XECpGopy5mPF8u Fo0uM7Mg+xywwN5rQngI21n3ca3eS5gWD4vNmnKKJrzGMwgHySPh8fc2p9GlhBzc+FsD rPikZljegwrQoNG4pTj3EUFz0MkixOrqAnrwO9wybYv0rvxR6sQUD70WtnCKS5DlACcb QLlgr9hOsh1zrVHRQaE5RGDaz/TlAlglweox9ABhJ1EPxW/U6LYuOXJ4Wkx4P/vXrMLL u/2TUbm/fx+z6IsKr0Ceq4mb6pKDK907Njmpma7+u46ooECiXErBcI7x02Se+L1hnsWF /GJA== 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=hKtu3Gu0fAEOQgNkPYcoOIR911PSmSWBIG0ujuNx7Ds=; b=I1DzpZMq15zzumGtSIuXVdHa9CAj+VunmlgBZAZeZWK4P26Jw+4BpH+vuF+OaiuLgx lgnCacPyqkuN/aAMwoDUFjfGqZtoj1cMpvB8e6i82/snN4o68h5IZb3v+ENA5VyxuN96 87mG7Dp4EdoA5djbjk6caQfJiZdRq+liYh4Sc5dy0BCaQzx2BJnFt9VgZu0LqG/bH26y qjO19QGxG4LQowpLGIZAscJRyr/p3sNuuguBVrXaZeipYIWXHlO6aO3/3NPga+XHl6eY w+OpWtlfREb+GtcyfITEp6MpahgIZl0JA2U0naEQATPwXEoKPn5mcplaYJN1tDZhg+ly 0ODQ== X-Gm-Message-State: AOAM530jN+P62tvu1h087zieZ52HX/4pDqB54FO4CLCG0nvuFv8D2so9 6haC0bLz/nYFjx/KcHDsrckDY6xdmQ8xUg== X-Google-Smtp-Source: ABdhPJx2AERmMRVThhrhC/DvHYsfZ0utOjNX9gm3ADrKHtnIcL/42JqcI802O26Iv+faBos4GNr4Hw== X-Received: by 2002:a37:9a46:: with SMTP id c67mr27652026qke.85.1597071058666; Mon, 10 Aug 2020 07:50:58 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:bdf4:17c2:a39e:1d69? ([2601:18b:300:36ee:bdf4:17c2:a39e:1d69]) by smtp.gmail.com with ESMTPSA id f14sm12896386qkl.52.2020.08.10.07.50.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2020 07:50:56 -0700 (PDT) From: Ted Lemon Message-Id: <2D76BF4C-DEBE-45B9-B631-96FC08CDC507@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7F5443CB-8CA5-463E-8CC1-0CC5A5A97DEC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 10 Aug 2020 10:50:55 -0400 In-Reply-To: Cc: Michael Richardson , ADD Mailing list To: Eric Rescorla References: <15378.1597020454@localhost> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Add] Requirements drafts 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, 10 Aug 2020 14:51:01 -0000 --Apple-Mail=_7F5443CB-8CA5-463E-8CC1-0CC5A5A97DEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 10, 2020, at 9:48 AM, Eric Rescorla wrote: > Is this in fact true? Back when I used to fly, I used to use DoH quite = a bit as well as > using browsers that were not configured with DoH and I never really = noticed a material > difference. Unlikely to be true. What=E2=80=99s true is that high latency and packet = loss cause problems for TCP connections on airplanes, and packet loss = causes DNS failures, but when you have packet loss the DNS answer = doesn=E2=80=99t matter, and probably isn=E2=80=99t in cache anyway. I = definitely have noticed DNS failures in flight, but they are always when = the network fundamentally isn=E2=80=99t working. A DNS cache on the = airplane will probably lower latency for some oft-visited sites, but = only a bit. If you have a cache in your laptop, it will get you nearly = all of the benefit that using the caching resolver on the airplane = infrastructure would give you. --Apple-Mail=_7F5443CB-8CA5-463E-8CC1-0CC5A5A97DEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Aug 10, 2020, at 9:48 AM, Eric Rescorla <ekr@rtfm.com> = wrote:
Is = this in fact true? Back when I used to fly, I used to use DoH quite a = bit as well as
using browsers that were not = configured with DoH and I never really noticed a material
difference.

Unlikely to be true. What=E2=80=99s true is that high latency = and packet loss cause problems for TCP connections on airplanes, and = packet loss causes DNS failures, but when you have packet loss the DNS = answer doesn=E2=80=99t matter, and probably isn=E2=80=99t in cache = anyway. I definitely have noticed DNS failures in flight, but they are = always when the network fundamentally isn=E2=80=99t working. A DNS cache = on the airplane will probably lower latency for some oft-visited sites, = but only a bit. If you have a cache in your laptop, it will get you = nearly all of the benefit that using the caching resolver on the = airplane infrastructure would give you.

= --Apple-Mail=_7F5443CB-8CA5-463E-8CC1-0CC5A5A97DEC-- From nobody Mon Aug 10 08:53: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 BADE83A07C5 for ; Mon, 10 Aug 2020 08:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 EgX8l_Fg_s_a for ; Mon, 10 Aug 2020 08:53:51 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 4AE0A3A07B5 for ; Mon, 10 Aug 2020 08:53:51 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id z18so8651130wrm.12 for ; Mon, 10 Aug 2020 08:53:51 -0700 (PDT) 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=r5/zjf/V0uWYq+/Goax9sNCcQzVGpWPRVwl7z6Z0pm8=; b=J04hjp8/FSXiPDM1EUIDsoeaq9RxbFRzrsUCcJzd4t76hNmZgMbm9GBP41Na8GODil Jci/WEzolk6CnW4gdC1XujmdK9tqVajORQ+sN/gPEAHoiIbLwSo8/JJQrYjlvXahpINT V81r2VFvTsNXpYzRCTUsBT3drpi/ZyGAZK/tob3QW/dZMt1XnnZyEPVF2Ewz15A9JGDz 9dnKKDb/AiArxHZG7H5DHV/oTZhVWxkUSXD/PiuF98fgW9mH/RaUxmKwigFTRUjq1aC0 76eYoflu9Xy71TtbBKFDMq5H650NOfxJ/GkpvbRMJhETWe6011CQKC7Lbw9Xolbyenj2 jTzQ== 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=r5/zjf/V0uWYq+/Goax9sNCcQzVGpWPRVwl7z6Z0pm8=; b=nwHa7uW+1BNeNYiFBje3aGB4Tx5p1Du9Ehp2B8xtnHDT6skqcG2kIjWsxqacZXS/JZ RgeA+igaRGLFQptzYS471WXPnHkqDxhLnU+t+EkuG3XNcAaS6c1nT2ZsORtzhfSF8MyQ A30dX40PnZKCkkB5R1y+L7yVyJVgh+kVRIOBCa3Z8fel05iA/XrXAmcVDdJsW676vvGb VWsUXcLumM1lgZn/2fZUgnmX+YAnribsgORndENnYwCae1pqevSmUA1Ds3jAyi1Jk4vT shFLM7lECqfPZMfqQNHErAaD44DMseB1AHw2+8ke46Banyz/mi2X5gN9c+LVLi5tZlPW bQYg== X-Gm-Message-State: AOAM5334oxVQSl5uSaLZeRkpdDH7AgxMr/oc+uFCXiSR60hS6GOTu/Zh NFTnDt4NxAjBi2q8o3jc0aWADWusdGdl+YCtuaWCIA== X-Google-Smtp-Source: ABdhPJyr038cd5Wpw7q5TVUtVTcbBaBBQDuLpXYJ0Ide5wcp8r653TL9cbXPQUQJTt65R3pD+pFMwIecRrnpuIuaDTk= X-Received: by 2002:adf:b602:: with SMTP id f2mr24236267wre.186.1597074829485; Mon, 10 Aug 2020 08:53:49 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> In-Reply-To: From: Eric Orth Date: Mon, 10 Aug 2020 11:53:38 -0400 Message-ID: To: Ben Schwartz Cc: Eric Orth , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000e497dc05ac87f507" Archived-At: Subject: Re: [Add] New Version Notification for draft-schwartz-svcb-dns-00.txt 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, 10 Aug 2020 15:53:55 -0000 --000000000000e497dc05ac87f507 Content-Type: text/plain; charset="UTF-8" Clarification question: Is the draft intended for finding alternate DNS servers given a query identifying one DNS server? Or is it intended as a generalization of the proposals for finding a designated DNS server given something like a webpage? Or both or more? My reading of the draft was that it was targeting just the first, but from your response and considering the three drafts referenced in your original email, I'm thinking I may have read the intent too narrowly. On Sun, Aug 9, 2020 at 3:03 PM Ben Schwartz wrote: > On Fri, Aug 7, 2020 at 5:11 PM Eric Orth 40google.com@dmarc.ietf.org> wrote: > >> I like the idea overall, but can you further explain the decision to use >> dns: URIs to describe DNS servers? >> > > I wouldn't say that's what's happening here. > > The SVCB/HTTPS record describes a way to perform connection establishment > when attempting to retrieve a resource by its URI. (Use of a URI with SVCB > is recommended but not required.) The SVCB draft only defines a mapping > for "http://" and "https://" URIs; this draft provides the mapping for > "dns://". > > For both "https://" and "dns://" URIs, SVCB serves the same function: the > URI provides an authority, and SVCB provides some information on how to > enhance your connection to that authority, in pursuit of the indicated > resource. Ultimately, the client must want to access some resource (i.e. > an HTTP resource or a DNS record, indicated by the URI's path in both > cases), or there's no need to connect to the authority at all. > > In truth, I don't think the "dns: URI" part is really important here; it's > mostly just a nice conceptual framework for the draft. The real question > is: if we distribute information in this form, will it work well as a > component of the systems we're trying to build? > > Seems a bit funky since that URI scheme is designed for DNS data, not a >> DNS server. What we want here seems to match more with just the optional >> "authority" section of a dns: URI. >> > > Yes; this is the SVCB design generally. Note that the "authority" section > is also optional in "https" URIs. > > Do we need a new URI scheme for DNS servers? Wasn't there a recent >> proposal for that? >> > > I believe those proposals are principally inspired by DNS Stamps > https://dnscrypt.info/stamps-specifications. With SVCB, the URI > (normally) identifies the authority by name, and the protocol is negotiated > at connection time. With DNS Stamps, all protocol and connection > parameters are encoded into the URI itself. > > I think the SVCB approach is more suitable for our purposes, because it > separates the simple, important question (who am I sending queries to?) > from the complicated, boring question (how do I perform connection > establishment?). This is similar to HTTPS: I wouldn't want to encode QUIC > vs. TLS, or ECH public keys, into the HTTPS URI, where the info could get > out of sync or distract from the important question (who is the authority?). > > On Tue, Aug 4, 2020 at 8:41 PM Ben Schwartz > 40google.com@dmarc.ietf.org> wrote: >> >>> Moving DPRIVE and DNSOP to BCC to avoid cross-posting. >>> >>> On Tue, Aug 4, 2020 at 1:53 PM Ben Schwartz >> > wrote: >>> >>>> Hi ADD and DPRIVE, >>>> >>>> I've noticed three recent drafts that propose to use the SVCB format: >>>> draft-mglt-add-rdp, draft-tapril-ns2, and >>>> draft-pauly-add-resolver-discovery. These drafts, across multiple >>>> working groups, consider distinct use cases and architectures, but they all >>>> propose using SVCB (in very different ways) to convey information about a >>>> DNS server that supports encrypted transport. >>>> >>>> In the interest of harmonizing these proposals, creating a solid >>>> foundation, and separating concerns, I've written a short draft that >>>> specifies _only_ a minimal SVCB mapping for DNS URIs*, and does not address >>>> any specific use case. >>>> >>>> I hope this draft can enable each of these proposals to focus more on >>>> their goals, and worry less about the SVCB encoding. (It also serves as an >>>> interesting test of the SVCB design.) >>>> >>>> Please review, >>>> Ben Schwartz >>>> >>>> *SVCB is based on URIs like https://, so for a DNS mapping we start >>>> with dns:// URIs. >>>> >>>> ---------- Forwarded message --------- >>>> From: >>>> Date: Tue, Aug 4, 2020 at 1:38 PM >>>> Subject: New Version Notification for draft-schwartz-svcb-dns-00.txt >>>> To: Benjamin Schwartz >>>> >>>> >>>> >>>> A new version of I-D, draft-schwartz-svcb-dns-00.txt >>>> has been successfully submitted by Benjamin Schwartz and posted to the >>>> IETF repository. >>>> >>>> Name: draft-schwartz-svcb-dns >>>> Revision: 00 >>>> Title: Service Binding Mapping for DNS URIs >>>> Document date: 2020-08-04 >>>> Group: Individual Submission >>>> Pages: 8 >>>> URL: >>>> https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-00.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/ >>>> Htmlized: https://tools.ietf.org/html/draft-schwartz-svcb-dns-00 >>>> Htmlized: >>>> https://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns >>>> >>>> >>>> Abstract: >>>> The SVCB DNS record type expresses a bound collection of endpoint >>>> metadata, for use when establishing a connection to a named service. >>>> DNS itself can be such a service, when the server is identified by a >>>> hostname in a "dns:" URI. This document provides the SVCB mapping >>>> for name-based DNS URIs, allowing DNS servers to indicate support for >>>> new transport protocols. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>>> -- >>> 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 > --000000000000e497dc05ac87f507 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Clarification question: Is the draft intended for finding = alternate DNS servers given a query identifying one DNS server? Or is it in= tended as a generalization of the proposals for finding a designated DNS se= rver given something like a webpage? Or both or more?

My= reading of the draft was that it was targeting=C2=A0just the first, but fr= om your response and considering the three drafts referenced in your origin= al email, I'm thinking I may have read the intent too narrowly.

On= Sun, Aug 9, 2020 at 3:03 PM Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:
On Fri, Aug 7, 2020 at 5:11 PM Eric Orth <ericorth=3D40google.com@dmarc.i= etf.org> wrote:
I like the idea overall, but can you further explai= n the decision to use dns: URIs to describe DNS servers?
=

I wouldn't say that's what's happening here= .

The SVCB/HTTPS record describes a way to perform= connection establishment when attempting to retrieve a resource by its URI= .=C2=A0 (Use of a URI with SVCB is recommended but not required.)=C2=A0 The= SVCB draft only defines a mapping for "http://" and "https:= //" URIs; this draft provides the mapping for "dns://".

For both "https://" and=C2=A0"dns://&qu= ot; URIs, SVCB serves the same function: the URI provides an authority, and= SVCB provides some information on how to enhance=C2=A0your connection to t= hat authority, in pursuit of the indicated resource.=C2=A0 Ultimately, the = client must want to access some resource (i.e. an HTTP resource or a DNS re= cord, indicated by the URI's path in both cases), or there's no nee= d to connect to the authority at all.

In truth, I = don't think the "dns: URI" part is really important here; it&= #39;s mostly just a nice=C2=A0conceptual framework for the draft.=C2=A0 The= real question is: if we distribute information in this form, will it work = well as a component of the systems we're trying to build?

Seems a bit funky since that URI scheme is= designed for DNS data, not a DNS server.=C2=A0 What we want here seems to = match more with just the optional "authority" section of a dns: U= RI.

Yes; this is the SVCB design gene= rally.=C2=A0 Note that the "authority" section is also optional i= n "https" URIs.

Do we need a new URI scheme for = DNS servers? Wasn't there a recent proposal for that?

I believe those proposals are principally inspir= ed by DNS Stamps=C2=A0https://dnscrypt.info/stamps-specifications. With = SVCB, the URI (normally) identifies the authority by name, and the protocol= is negotiated at connection time.=C2=A0 With DNS Stamps, all protocol and = connection parameters are encoded into the URI itself.

=
I think the SVCB approach is more suitable for our purposes, because i= t separates the simple, important question (who am I sending queries to?) f= rom the complicated, boring question (how do I perform connection establish= ment?).=C2=A0 This is similar to HTTPS: I wouldn't want to encode QUIC = vs. TLS, or ECH public keys, into the HTTPS URI, where the info could get o= ut of sync or distract from the important question (who is the authority?).=

On Tue, Aug 4,= 2020 at 8:41 PM Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:=
Moving DPRIVE and DNSOP to BCC to avoid cross-posting.

On Tue, Aug 4, 2020= at 1:53 PM Ben Schwartz <bemasc@google.com> wrote:
Hi ADD and DPRIVE,

I've noticed three recent drafts that propose to use the SVCB = format: draft-mglt-add-rdp, draft-tapril-ns2, and draft-pauly-add-resolver-= discovery.=C2=A0 These drafts, across multiple working=C2=A0groups,=C2=A0co= nsider distinct use cases and architectures, but they all propose using SVC= B (in very different ways) to convey information about a DNS server that su= pports encrypted transport.

In the interest of har= monizing these proposals, creating a solid foundation, and separating conce= rns, I've written a short draft that specifies _only_ a minimal SVCB ma= pping for DNS URIs*, and does not address any specific use case.
<= div>
I hope this draft can enable each of these proposals to = focus more on their goals,=C2=A0and worry less about the SVCB encoding.=C2= =A0 (It also serves as an interesting test of the SVCB design.)

Please review,
Ben Schwartz

*SVCB is based on URIs like https://, so for a DNS mapping we start= with dns:// URIs.

---------- Forwa= rded message ---------
From: <internet-drafts@ietf.org><= /span>
Date: Tue, Aug 4, 2020 at 1:38 PM
Subject: New Version Notific= ation for draft-schwartz-svcb-dns-00.txt
To: Benjamin Schwartz <bemasc@google.com>=



A new version of I-D, draft-schwartz-svcb-dns-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-svcb-dns
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Service Binding Mapping for DNS UR= Is
Document date:=C2=A0 2020-08-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-0= 0.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-schwartz-svcb-dns-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns


Abstract:
=C2=A0 =C2=A0The SVCB DNS record type expresses a bound collection of endpo= int
=C2=A0 =C2=A0metadata, for use when establishing a connection to a named se= rvice.
=C2=A0 =C2=A0DNS itself can be such a service, when the server is identifie= d by a
=C2=A0 =C2=A0hostname in a "dns:" URI.=C2=A0 This document provid= es the SVCB mapping
=C2=A0 =C2=A0for name-based DNS URIs, allowing DNS servers to indicate supp= ort for
=C2=A0 =C2=A0new transport protocols.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--
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
--000000000000e497dc05ac87f507-- From nobody Mon Aug 10 08:56: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 D6AB93A07C0 for ; Mon, 10 Aug 2020 08:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 c-y3Qutrjk68 for ; Mon, 10 Aug 2020 08:56:54 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 16FAB3A07B5 for ; Mon, 10 Aug 2020 08:56:54 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id k20so19971wmi.5 for ; Mon, 10 Aug 2020 08:56:53 -0700 (PDT) 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=r2xJticuOUeHMzfUUkPHOHpjrcDX5cXnkKtpFLbBxnE=; b=EF6kVK+2ifBFpzOSXy8Uz1UINhQ09qxW6TfIQPPbllm8HyyqATw8Vx4Y/pCPvyUta6 /ZC37qX4I3POYAcnfzInmFmiC7vcFeroabg3Z65G/enMuQMw6ZW/UHo3rTRF1Y5ziNWc gUutDckXdYCRzW5ekITuVwKNFGHOwJ4a2uuMrZDy2Fsmq3O2Sx71n/XGSF6PtP78Rm8H T5l8yfuu/n0UOHwlarYQ44Ea6H4DS7lueJqbHbl6s4p8iDqHEfz4At3eU6yusZdSAjfV HRWL3JYb+myLjmH3XA/FZsbLk9LtiqEPieAMYPd23BVtd95b9UDD+GKoOfXJ5Srj2iJx 0ELw== 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=r2xJticuOUeHMzfUUkPHOHpjrcDX5cXnkKtpFLbBxnE=; b=ZdQwUhbK+OZGTV/i6opurtVNzF6C51ldX9a9ycQmFnsWKjqXkv9JSfOEJ4k2xtMaYa y0myN+fqKE+1J11BRINOACZcUnzy60pufoN7rfYzTYNHLdTyrO8xj+AJYQAKNfexA7sA 7Lx3ec8njwRL/LZlFbsrThpnd1Hk3dWd6O/syEWIRGrDWejvqvZPpJvHCSUx0B6meG0q 7CNM45mSju9WvCd+RLbrvekTYMKZ6DqscDRBSAW++CTsOCI/NXmqLfTojZ3PIHhTMGkq zblpWUkAGlfKbW8OS/9iilRO1cWUebtL4u2TGU8vzVAQa6shRE4rgQ99ZOlDnZJGlnVZ YJGA== X-Gm-Message-State: AOAM531MU4I9Q48GQsHiHNv8F6EVdElfN4T2uRg0t6W3NAMay5Mw2k7C ovrrnDgKha9EecnLzvpF/0+P1mBWapJQgyYZshxwan4Y64Q= X-Google-Smtp-Source: ABdhPJxUeZbUVIWDKvChhwizwytBnJqPh+wMBO3vUe2xp1/eH3F0KKF7PeoI6WsMKlIaZSsbwPmPP3vHwtyCL7f7N5k= X-Received: by 2002:a1c:4e17:: with SMTP id g23mr10528wmh.42.1597075012323; Mon, 10 Aug 2020 08:56:52 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> In-Reply-To: From: Ben Schwartz Date: Mon, 10 Aug 2020 11:56:41 -0400 Message-ID: To: Martin Thomson Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d0361805ac88000e" Archived-At: Subject: Re: [Add] DNS URI scheme (was SVCB for DNS) 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, 10 Aug 2020 15:56:56 -0000 --000000000000d0361805ac88000e Content-Type: multipart/alternative; boundary="000000000000ca80b605ac880000" --000000000000ca80b605ac880000 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 9, 2020 at 8:45 PM Martin Thomson wrote: > I wasn't going to respond and then I saw this... > > On Mon, Aug 10, 2020, at 05:03, Ben Schwartz wrote: > > Note that the "authority" section is also optional in "https" URIs. > > This is not true in any way I can discern. Authority is mandatory in HTTP. > You're right, at least in the IETF, RFC 7230 is pretty clear that authority is mandatory. It turns out I am the latest victim of the WHATWG vs. IETF URI/URL debacle. See e.g. https://jsdom.github.io/whatwg-url/#url=aHR0cHM6L3NlZ21lbnQxL3NlZ21lbnQyP2tleT12YWx1ZQ==&base=aHR0cHM6Ly9leGFtcGxlLmNvbS8= ... > My model for URIs says that there is an entity that controls a portion of > the namespace established for the scheme. That entity is identified by the > authority component. The authority gets to say whatever it likes about > resources that exist in the part of the namespace it controls. > I think you might be disappointed by a lot of the defined URIs, e.g. "ldap", "xmpp", "nntp". (Not that I necessarily disagree.) ... > I'm inclined to suggest that we NOT use dns:// URIs. Not because they > aren't suitable - they fit surprisingly well to the use case - but because > they are not good. > OK, I've removed the dependency on dns:// URIs and cut a new version: https://tools.ietf.org/html/draft-schwartz-svcb-dns-01. > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000ca80b605ac880000 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Aug 9, 2020 at 8:45 PM Martin= Thomson <mt@lowentropy.net>= wrote:
I wasn&#= 39;t going to respond and then I saw this...

On Mon, Aug 10, 2020, at 05:03, Ben Schwartz wrote:
> Note that the "authority" section is also optional in "= https" URIs.

This is not true in any way I can discern.=C2=A0 Authority is mandatory in = HTTP.

You're right, at least in the= IETF, RFC 7230 is pretty clear that=C2=A0authority is mandatory.=C2=A0 It = turns out I am the latest victim of the WHATWG vs. IETF URI/URL debacle. Se= e e.g.=C2=A0https://jsdom.github.io/whatwg-url/#url=3DaHR0cHM6L3NlZ21lbnQxL3= NlZ21lbnQyP2tleT12YWx1ZQ=3D=3D&base=3DaHR0cHM6Ly9leGFtcGxlLmNvbS8=3D
My model for URIs says that there is an entity that controls a= portion of the namespace established for the scheme.=C2=A0 That entity is = identified by the authority component.=C2=A0 The authority gets to say what= ever it likes about resources that exist in the part of the namespace it co= ntrols.

I&#= 39;m inclined to suggest that we NOT use dns:// URIs.=C2=A0 Not because the= y aren't suitable - they fit surprisingly well to the use case - but be= cause they are not good.



--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000ca80b605ac880000-- --000000000000d0361805ac88000e Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCDL9iV9aGo7KpTohwRCmdRtsCLfAhVeKozKsafzVwkPmjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA4MTAxNTU2NTJaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAPS6ZNITiJZzZNN1oOv922JrvT28fyHU2WZZK2gNK23dBmW8ISODWRgms22DQmWnp90/yzxrx t3B51bX9Di6dgrEKMl2Fm8sjzwikmww1QTjwAUPdoXNPRJhj+rxR+9WzH/qaXrWElHBn56w5VC1q egdzg0sV+NPv85VqDh9NWmXVKfjCDXKt/h5yyHwUuq0NfnzCIHPTxV+b/u2TCYewxOfJlWi0xl8v Li6UQjQ3C+J0dYMkHsgH5+g00/DNKfIoYs3YAdGZu0l9r6qFBId1siJCbF+W43t7qQ9hv6Po1sJ7 YOtKBHt242xac0nsu/BAKfQmkaTzmKzGpHUCA6Geuw== --000000000000d0361805ac88000e-- From nobody Mon Aug 10 10:02: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 DC8513A0B4F for ; Mon, 10 Aug 2020 10:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 ENqebHs9fnR7 for ; Mon, 10 Aug 2020 10:02:11 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 C3C073A0B4B for ; Mon, 10 Aug 2020 10:02:10 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id c80so212905wme.0 for ; Mon, 10 Aug 2020 10:02:10 -0700 (PDT) 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=dqWl5lLzh73UyDw/0W+4Kmx3qXLQ/ZdaAWJRtlOpJeA=; b=vqWn0SgstZqOFIdF/46pO/WwNAGAoLmHumZdLfh9FfsKWN2meWe3S/TXD3YMnGBYdj F6Q5etUnxjqh8ZbNhTVvXJ7YE88lWDppa5nD82imvCP4pBwzcZw5sllxdqKesn7a2gQ2 oEYzcFJrYWPWaUfIRY3QUwwkOzr6stn2BId9Rgp2BXoRG2BBbuo/nMvp+hpcTqwCE6ty RQ0tipaFQWF1IIv485Yh8/hOsXRB7sgxWqD6E6DR7CYmpl/6bRPatrcnrTRJWDOm7+Sn dIWqC2bFjGyce+EEEEB9TO9G9JMey652QmkZuZAchYA5JF+euiTocG8aWmFik0FfI2uK PrLw== 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=dqWl5lLzh73UyDw/0W+4Kmx3qXLQ/ZdaAWJRtlOpJeA=; b=b/7l0+zx3CMsVBbyu3+XCBo0Kn/BoCVrWWHqCoHNhUsR6n5HRagrAQnG49VZz21VBG uRmyeLCFAjdpLchJakIHAs2zpbzmM3mB6X+W6tGaCyRFGNtDlEW21kaCOAS3HTrd09mW HfEtVDo5O4nyRg1ESepwyFpF9m2yX99rRmmNqH2sVtxEQmy+4bMMkdQOnU7EmpL2TF57 12TTd6i4UPbbDd0W95ZHzbDDg4EtKsdx97bn9t2M8LUDKsjsqKOwl2kIknl+/aFG0t0l lphFdqnhsigPuCjfcBP5r/D/DgbF8PpvjvmycGNSp5U9zpCLchU7nBIUm/1WPGJMwhHP GLiQ== X-Gm-Message-State: AOAM531leDL7ZefXeGbxO0r9crPyfFC42L0mmZThN0euybrJgK1/28Vb hq//N4jf/9WLbctYbDqA9yB8erQZXo0fUKnveaUvf5Lt X-Google-Smtp-Source: ABdhPJwSmdosuhQtlviuaAYJ5xbks+j0r3hsdlJdLJ1pQHX4ta2DL6YPtrOEfh0svyIXorlyUA5zc/xDgtsBrLFHv10= X-Received: by 2002:a1c:a757:: with SMTP id q84mr201717wme.1.1597078928060; Mon, 10 Aug 2020 10:02:08 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> In-Reply-To: From: Ben Schwartz Date: Mon, 10 Aug 2020 13:01:56 -0400 Message-ID: To: Eric Orth Cc: Eric Orth , ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000042d0de05ac88ea62" Archived-At: Subject: Re: [Add] New Version Notification for draft-schwartz-svcb-dns-00.txt 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, 10 Aug 2020 17:02:14 -0000 --00000000000042d0de05ac88ea62 Content-Type: multipart/alternative; boundary="0000000000002fd47405ac88ea06" --0000000000002fd47405ac88ea06 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 10, 2020 at 11:53 AM Eric Orth wrote: > Clarification question: Is the draft intended for finding alternate DNS > servers given a query identifying one DNS server? > Pretty much, yeah. Or is it intended as a generalization of the proposals for finding a > designated DNS server given something like a webpage? Or both or more? > > My reading of the draft was that it was targeting just the first, but from > your response and considering the three drafts referenced in your original > email, I'm thinking I may have read the intent too narrowly. > This is intended as a reusable component for converting "domain name of a DNS server" into "instructions for contacting that server over an encrypted transport". How you learned that domain name, and what you use it for, are outside the scope of this draft. My hope is that this component allows various other proposals to focus on those questions, and to share at least the syntax of the encrypted transport parameters for different use cases. It seems like the emphasis on "dns://" URIs was a source of some confusion, so I've rephrased the text to avoid that dependency. On Sun, Aug 9, 2020 at 3:03 PM Ben Schwartz 40google.com@dmarc.ietf.org> wrote: > >> On Fri, Aug 7, 2020 at 5:11 PM Eric Orth > 40google.com@dmarc.ietf.org> wrote: >> >>> I like the idea overall, but can you further explain the decision to use >>> dns: URIs to describe DNS servers? >>> >> >> I wouldn't say that's what's happening here.. >> >> The SVCB/HTTPS record describes a way to perform connection establishment >> when attempting to retrieve a resource by its URI.. (Use of a URI with >> SVCB is recommended but not required.) The SVCB draft only defines a >> mapping for "http://" and "https://" URIs; this draft provides the >> mapping for "dns://". >> >> For both "https://" and "dns://" URIs, SVCB serves the same function: >> the URI provides an authority, and SVCB provides some information on how to >> enhance your connection to that authority, in pursuit of the indicated >> resource. Ultimately, the client must want to access some resource (i.e. >> an HTTP resource or a DNS record, indicated by the URI's path in both >> cases), or there's no need to connect to the authority at all. >> >> In truth, I don't think the "dns: URI" part is really important here; >> it's mostly just a nice conceptual framework for the draft. The real >> question is: if we distribute information in this form, will it work well >> as a component of the systems we're trying to build? >> >> Seems a bit funky since that URI scheme is designed for DNS data, not a >>> DNS server. What we want here seems to match more with just the optional >>> "authority" section of a dns: URI. >>> >> >> Yes; this is the SVCB design generally. Note that the "authority" >> section is also optional in "https" URIs. >> >> Do we need a new URI scheme for DNS servers? Wasn't there a recent >>> proposal for that? >>> >> >> I believe those proposals are principally inspired by DNS Stamps >> https://dnscrypt.info/stamps-specifications. With SVCB, the URI >> (normally) identifies the authority by name, and the protocol is negotiated >> at connection time. With DNS Stamps, all protocol and connection >> parameters are encoded into the URI itself. >> >> I think the SVCB approach is more suitable for our purposes, because it >> separates the simple, important question (who am I sending queries to?) >> from the complicated, boring question (how do I perform connection >> establishment?). This is similar to HTTPS: I wouldn't want to encode QUIC >> vs. TLS, or ECH public keys, into the HTTPS URI, where the info could get >> out of sync or distract from the important question (who is the authority?). >> >> On Tue, Aug 4, 2020 at 8:41 PM Ben Schwartz >> 40google.com@dmarc.ietf.org> wrote: >>> >>>> Moving DPRIVE and DNSOP to BCC to avoid cross-posting. >>>> >>>> On Tue, Aug 4, 2020 at 1:53 PM Ben Schwartz >>> > wrote: >>>> >>>>> Hi ADD and DPRIVE, >>>>> >>>>> I've noticed three recent drafts that propose to use the SVCB format: >>>>> draft-mglt-add-rdp, draft-tapril-ns2, and >>>>> draft-pauly-add-resolver-discovery. These drafts, across multiple >>>>> working groups, consider distinct use cases and architectures, but they all >>>>> propose using SVCB (in very different ways) to convey information about a >>>>> DNS server that supports encrypted transport. >>>>> >>>>> In the interest of harmonizing these proposals, creating a solid >>>>> foundation, and separating concerns, I've written a short draft that >>>>> specifies _only_ a minimal SVCB mapping for DNS URIs*, and does not address >>>>> any specific use case. >>>>> >>>>> I hope this draft can enable each of these proposals to focus more on >>>>> their goals, and worry less about the SVCB encoding. (It also serves as an >>>>> interesting test of the SVCB design.) >>>>> >>>>> Please review, >>>>> Ben Schwartz >>>>> >>>>> *SVCB is based on URIs like https://, so for a DNS mapping we start >>>>> with dns:// URIs. >>>>> >>>>> ---------- Forwarded message --------- >>>>> From: >>>>> Date: Tue, Aug 4, 2020 at 1:38 PM >>>>> Subject: New Version Notification for draft-schwartz-svcb-dns-00.txt >>>>> To: Benjamin Schwartz >>>>> >>>>> >>>>> >>>>> A new version of I-D, draft-schwartz-svcb-dns-00.txt >>>>> has been successfully submitted by Benjamin Schwartz and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-schwartz-svcb-dns >>>>> Revision: 00 >>>>> Title: Service Binding Mapping for DNS URIs >>>>> Document date: 2020-08-04 >>>>> Group: Individual Submission >>>>> Pages: 8 >>>>> URL: >>>>> https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-00.txt >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/ >>>>> Htmlized: https://tools.ietf.org/html/draft-schwartz-svcb-dns-00 >>>>> Htmlized: >>>>> https://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns >>>>> >>>>> >>>>> Abstract: >>>>> The SVCB DNS record type expresses a bound collection of endpoint >>>>> metadata, for use when establishing a connection to a named service. >>>>> DNS itself can be such a service, when the server is identified by a >>>>> hostname in a "dns:" URI. This document provides the SVCB mapping >>>>> for name-based DNS URIs, allowing DNS servers to indicate support >>>>> for >>>>> new transport protocols. >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>>> -- >>>> 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 >> > --0000000000002fd47405ac88ea06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 10, 2020 at 11:53 AM Eric Ort= h <ericorth=3D40google.co= m@dmarc.ietf.org> wrote:
Clarification q= uestion: Is the draft intended for finding alternate DNS servers given a qu= ery identifying one DNS server?

Prett= y much, yeah.

Or is it intended as a generalization of the p= roposals for finding a designated DNS server given something like a webpage= ? Or both or more?

My reading of the draft was that it w= as targeting=C2=A0just the first, but from your response and considering th= e three drafts referenced in your original email, I'm thinking I may ha= ve read the intent too narrowly.

This is intended as a reusable component for converting "domain name= of a DNS server" into "instructions for contacting that server o= ver an encrypted transport".=C2=A0 How you learned that domain name, a= nd what you use it for, are outside the scope of this draft.=C2=A0 My hope = is that this component allows various other proposals to focus on those que= stions, and to share at least the syntax of the encrypted transport paramet= ers for different use cases.

It seems like the emp= hasis on "dns://" URIs was a source of some confusion, so I'v= e rephrased the text to avoid that dependency.

On Sun, Aug 9, 2020 at 3:03 PM Ben Schwartz= <bemasc=3D40google.com@dmarc.ietf.org> wrote:
On Fri, Aug = 7, 2020 at 5:11 PM Eric Orth <ericorth=3D40google.com@dmarc.ietf.org> wrote= :
I like the idea overall, but can you further explain the decision to use= dns: URIs to describe DNS servers?

I= wouldn't say that's what's happening here..

The SVCB/HTTPS record describes a way to perform connection establis= hment when attempting to retrieve a resource by its URI..=C2=A0 (Use of a U= RI with SVCB is recommended but not required.)=C2=A0 The SVCB draft only de= fines a mapping for "http://" and "https://" URIs; this= draft provides the mapping for "dns://".

For both "https://" and=C2=A0"dns://" URIs, SVCB serv= es the same function: the URI provides an authority, and SVCB provides some= information on how to enhance=C2=A0your connection to that authority, in p= ursuit of the indicated resource.=C2=A0 Ultimately, the client must want to= access some resource (i.e. an HTTP resource or a DNS record, indicated by = the URI's path in both cases), or there's no need to connect to the= authority at all.

In truth, I don't think the= "dns: URI" part is really important here; it's mostly just a= nice=C2=A0conceptual framework for the draft.=C2=A0 The real question is: = if we distribute information in this form, will it work well as a component= of the systems we're trying to build?
=

Seems a bit funky since that URI scheme is designed for DNS d= ata, not a DNS server.=C2=A0 What we want here seems to match more with jus= t the optional "authority" section of a dns: URI.

Yes; this is the SVCB design generally.=C2=A0 Note t= hat the "authority" section is also optional in "https"= URIs.

Do we need a new URI scheme for DNS servers? Wasn&#= 39;t there a recent proposal for that?

I believe those proposals are principally inspired by DNS Stamps=C2= =A0https://dnscrypt.info/stamps-specifications. With SVCB, the URI (norm= ally) identifies the authority by name, and the protocol is negotiated at c= onnection time.=C2=A0 With DNS Stamps, all protocol and connection paramete= rs are encoded into the URI itself.

I think the SV= CB approach is more suitable for our purposes, because it separates the sim= ple, important question (who am I sending queries to?) from the complicated= , boring question (how do I perform connection establishment?).=C2=A0 This = is similar to HTTPS: I wouldn't want to encode QUIC vs. TLS, or ECH pub= lic keys, into the HTTPS URI, where the info could get out of sync or distr= act from the important question (who is the authority?).

On Tue, Aug 4, 2020 at 8:41 PM Be= n Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:
Moving DPRIVE and= DNSOP to BCC to avoid cross-posting.

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Aug 4, 2020 at 1:53 PM Ben Sch= wartz <bemasc@go= ogle.com> wrote:
Hi ADD and DPRIVE,

I've not= iced three recent drafts that propose to use the SVCB format: draft-mglt-ad= d-rdp, draft-tapril-ns2, and draft-pauly-add-resolver-discovery.=C2=A0 Thes= e drafts, across multiple working=C2=A0groups,=C2=A0consider distinct use c= ases and architectures, but they all propose using SVCB (in very different = ways) to convey information about a DNS server that supports encrypted tran= sport.

In the interest of harmonizing these propos= als, creating a solid foundation, and separating concerns, I've written= a short draft that specifies _only_ a minimal SVCB mapping for DNS URIs*, = and does not address any specific use case.

I = hope this draft can enable each of these proposals to focus more on their g= oals,=C2=A0and worry less about the SVCB encoding.=C2=A0 (It also serves as= an interesting test of the SVCB design.)

Plea= se review,
Ben Schwartz

*SVCB is based on URIs like https://,= so for a DNS mapping we start with dns:// URIs.

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Aug 4, 2020 at 1:38 = PM
Subject: New Version Notification for draft-schwartz-svcb-dns-00.txt<= br>To: Benjamin Schwartz <bemasc@google.com>



A new version of I-D, draft-schwartz-svcb-dns-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-svcb-dns
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Service Binding Mapping for DNS UR= Is
Document date:=C2=A0 2020-08-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-0= 0.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-schwartz-svcb-dns-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns


Abstract:
=C2=A0 =C2=A0The SVCB DNS record type expresses a bound collection of endpo= int
=C2=A0 =C2=A0metadata, for use when establishing a connection to a named se= rvice.
=C2=A0 =C2=A0DNS itself can be such a service, when the server is identifie= d by a
=C2=A0 =C2=A0hostname in a "dns:" URI.=C2=A0 This document provid= es the SVCB mapping
=C2=A0 =C2=A0for name-based DNS URIs, allowing DNS servers to indicate supp= ort for
=C2=A0 =C2=A0new transport protocols.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--
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
--0000000000002fd47405ac88ea06-- --00000000000042d0de05ac88ea62 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCB665kdt7yK49UXwkZc0FofwRvM7ZGRIElAyJqefi1QhjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA4MTAxNzAyMDlaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEALzWKuVFihFWE7zfrkkCT/NYWTfQEO1/kEAFnLcs2hy6NHN7Kg2tOOiTOQ/pTK6D8+ivmQk6f ySEuayeUWHzaD41SqWYpCpRrKNB4iPXAOW75t+ZG3j9TqzUfbBX6549NOUcG+UcdmfT/eeh+Fh5t dVOJoxrulJml4EbGcxwmKcktphzYcxegaE5aKMPPF/gkgJvM1YwT+UOXNZFPMmIN/5Bt/QK+Iw5l Z0ZtbasoGW1IMU8RJKAoSIbL358cJRnGRk2xJcZRcNKloC848eYrikerCUA/LbD6bCk3e2pDOYDu 7gq1YUBknmOQkVsX6XJOmMkiAP4y4nqdb5ncKFGehw== --00000000000042d0de05ac88ea62-- From nobody Mon Aug 10 10:34:43 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 0B0223A0B3F; Mon, 10 Aug 2020 10:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=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 21YJu79tg2uG; Mon, 10 Aug 2020 10:34:39 -0700 (PDT) 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 3BEFA3A08A9; Mon, 10 Aug 2020 10:34:39 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 07AHIex2004780; Mon, 10 Aug 2020 10:34:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=j+B88ACt4OTqZxYEbB1F00jB7M5QZUGioyau9uwHs0M=; b=RRj9gOY8uCw49E4zR0cllw2zzLYVwYIVqyegU1rGGTi2PPfIOhZGhlpEfxkplnkYCkIE AFFi+gqsSwS/ZFOCr42yHrCiYuQx94hOTUIAH9tQljUrWGkxzEpCt5ACD5lK2kqTFOA0 C68s0nQ56fyD+zy3MeTPQMSVpMo5WBdgqDpkMiDVJV6tF39Kry16PdHni3wjQdpUQh75 3avGeNbReYVRoC8Xfr0ohc6dqQ1nVBbdS9A9h+GOaQbTbSjubQ87HAp4dsvKM1kf1Z67 4CHQ6sfpXm0U9jeorBZHcQ3zziqYjVxlv95K7LrCga50rwc/TgYMEKXdu7eVLS/2w4Q1 Ig== 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 32srqrvq0y-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 10 Aug 2020 10:34:38 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QEU00HSAZHM5ZJ0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 10 Aug 2020 10:34:34 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QEU00T00YUUCC00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 10 Aug 2020 10:34:34 -0700 (PDT) X-Va-A: X-Va-T-CD: e72da815dcb01dab2f988f94f1719970 X-Va-E-CD: 3e9fc8a9109f777cd858679839a41347 X-Va-R-CD: ad001817491c53ec16a5bde7f0519243 X-Va-CD: 0 X-Va-ID: 7a510bdc-07c3-474d-96fc-a8286e113205 X-V-A: X-V-T-CD: e72da815dcb01dab2f988f94f1719970 X-V-E-CD: 3e9fc8a9109f777cd858679839a41347 X-V-R-CD: ad001817491c53ec16a5bde7f0519243 X-V-CD: 0 X-V-ID: 99250f46-b6e0-4b68-aec6-cc41a5bad748 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-10_14:2020-08-06, 2020-08-10 signatures=0 Received: from [17.234.80.109] (unknown [17.234.80.109]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QEU00P1ZZHL8O00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 10 Aug 2020 10:34:34 -0700 (PDT) From: Tommy Pauly Message-id: <66BDBEC3-4118-4CAB-8DC1-9BDF4BA3B6AF@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_801A349E-493E-43EF-91E0-80DCFD26FA99" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Mon, 10 Aug 2020 10:34:33 -0700 In-reply-to: Cc: Martin Thomson , ADD Mailing list To: Ben Schwartz References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-10_14:2020-08-06, 2020-08-10 signatures=0 Archived-At: Subject: Re: [Add] DNS URI scheme (was SVCB for DNS) 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, 10 Aug 2020 17:34:41 -0000 --Apple-Mail=_801A349E-493E-43EF-91E0-80DCFD26FA99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 10, 2020, at 8:56 AM, Ben Schwartz = wrote: >=20 >=20 >=20 > On Sun, Aug 9, 2020 at 8:45 PM Martin Thomson > wrote: > I wasn't going to respond and then I saw this... >=20 > On Mon, Aug 10, 2020, at 05:03, Ben Schwartz wrote: > > Note that the "authority" section is also optional in "https" URIs. >=20 > This is not true in any way I can discern. Authority is mandatory in = HTTP. >=20 > You're right, at least in the IETF, RFC 7230 is pretty clear that = authority is mandatory. It turns out I am the latest victim of the = WHATWG vs. IETF URI/URL debacle. See e.g. = https://jsdom.github.io/whatwg-url/#url=3DaHR0cHM6L3NlZ21lbnQxL3NlZ21lbnQy= P2tleT12YWx1ZQ=3D=3D&base=3DaHR0cHM6Ly9leGFtcGxlLmNvbS8=3D = > =20 > ... > My model for URIs says that there is an entity that controls a portion = of the namespace established for the scheme. That entity is identified = by the authority component. The authority gets to say whatever it likes = about resources that exist in the part of the namespace it controls. >=20 > I think you might be disappointed by a lot of the defined URIs, e.g. = "ldap", "xmpp", "nntp". (Not that I necessarily disagree.) >=20 > ... > I'm inclined to suggest that we NOT use dns:// URIs. Not because they = aren't suitable - they fit surprisingly well to the use case - but = because they are not good. >=20 > OK, I've removed the dependency on dns:// URIs and cut a new version: = https://tools.ietf..org/html/draft-schwartz-svcb-dns-01 = . Thanks for making that update. I think this tightens up the scope of the = proposal well. The use of the SVCB record for the DNS scheme makes = sense, and this seems like the right building block to use. Best, Tommy >=20 >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add = > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --Apple-Mail=_801A349E-493E-43EF-91E0-80DCFD26FA99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Aug 10, 2020, at 8:56 AM, Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:



On Sun, Aug 9, 2020 at 8:45 PM Martin Thomson = <mt@lowentropy.net> wrote:
I = wasn't going to respond and then I saw this...

On Mon, Aug 10, 2020, at 05:03, Ben Schwartz wrote:
> Note that the "authority" section is also optional in "https" = URIs.

This is not true in any way I can discern.  Authority is mandatory = in HTTP.

You're right, at least in the IETF, RFC = 7230 is pretty clear that authority is mandatory.  It turns = out I am the latest victim of the WHATWG vs. IETF URI/URL debacle. See = e.g. https://jsdom.github.io/whatwg-url/#url=3DaHR0cHM6L3NlZ21lbnQxL= 3NlZ21lbnQyP2tleT12YWx1ZQ=3D=3D&base=3DaHR0cHM6Ly9leGFtcGxlLmNvbS8=3D<= /a>
 
...
My model for URIs says that = there is an entity that controls a portion of the namespace established = for the scheme.  That entity is identified by the authority = component.  The authority gets to say whatever it likes about = resources that exist in the part of the namespace it controls.

I think you might be disappointed by a lot of the = defined URIs, e.g. "ldap", "xmpp", "nntp".  (Not that I = necessarily disagree.)

...
I'm inclined to suggest that we NOT = use dns:// URIs.  Not because they aren't suitable - they fit = surprisingly well to the use case - but because they are not good.

OK, I've removed the dependency on dns:// URIs and cut a new = version: https://tools.ietf..org/html/draft-schwartz-svcb-dns-01.

Thanks for = making that update. I think this tightens up the scope of the proposal = well. The use of the SVCB record for the DNS scheme makes sense, and = this seems like the right building block to use.

Best,
Tommy


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

= --Apple-Mail=_801A349E-493E-43EF-91E0-80DCFD26FA99-- From nobody Mon Aug 10 11:25: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 4D8873A0A4F for ; Mon, 10 Aug 2020 11:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 NjAmZTKtrmQ5 for ; Mon, 10 Aug 2020 11:25:48 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 5E2543A0A3F for ; Mon, 10 Aug 2020 11:25:48 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id r2so9093231wrs.8 for ; Mon, 10 Aug 2020 11:25:48 -0700 (PDT) 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=ptWLpo3ZacUWYbYHuGS45ToGyGo3Ax0yVUZgKyndV7c=; b=klKNVlz9M40hpzg0oJ49CxQCnAFXbkgQJ29Q0Gm70WAU2OfDjQb9z7K5j0ru7ere5c 2w3OcrU4cTWgSZPagSseubfgORe0UG0h8Ci/fB0ikUV8fFzfIFvkK9CHfSdNDagJ8GDm q45YmiIAMvUlDnZZ1Z9Y++IzeDXrwqJC4C5QvHKrlUPgPKoeCs6d1BLPJO3EIPKqqdtf VURf97EzWdjjEhmECBrlijPoVKD9qWd78rXoOdkHgqEBQhZaYh1dHeuMDleHBqmNNsXf XIyVGjArVwhs08ZK9ammrP/cLjwNFf81WDbWaoqkgL1tXRhStZq9LYm7NDJZXax+/aKu 1/OA== 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=ptWLpo3ZacUWYbYHuGS45ToGyGo3Ax0yVUZgKyndV7c=; b=ahYKJf648raTalP4jwmyJFGi9asxI2AQ8YaZsOLVR3kYgFalCN+HP8o4SDuwbnK2iX rkZB34Dw2+HcTjH+YTiN6UEf2LC8agXjOdcLnjKiPusJ0hYKjcSq5T2r6S5iVmV1EzMr 33gkSivwRvUHNmygl45J4w6PqlQCXHtNO94CxRXgjpTz9vi8Yv6jq20NjPPi0R9ugvyv XiVl7TQaxtvSV/e1v7D3Wrpa1ktjWHqRprPfuvaYR09uVahBN4W0EG2egKKt1rwvMmoQ gLq+usS0SQwKhy98x+EwU3F5XOQXI7l0nRUXJvZVtYTli6VIamdBDIsNQkmOtvaF459c dOiQ== X-Gm-Message-State: AOAM530gyRAPQ0AswM45n+T51v4oBmqhXch7cF4yqsFUZC5gW6L5xnHv BEYWv03Uz2PoM97YqKHnKT4KIdH0J213OWGcVSbNhaD1 X-Google-Smtp-Source: ABdhPJwuSCkbK4POwIAr9gEcV/mbswrvASbJdrXGmSnVMP4h5EHFXeyc9jxh0JV+QvweSGewF46vwzWdXtwiEi9c1oE= X-Received: by 2002:adf:bc4a:: with SMTP id a10mr25564667wrh.346.1597083946673; Mon, 10 Aug 2020 11:25:46 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> <66BDBEC3-4118-4CAB-8DC1-9BDF4BA3B6AF@apple.com> In-Reply-To: <66BDBEC3-4118-4CAB-8DC1-9BDF4BA3B6AF@apple.com> From: Eric Orth Date: Mon, 10 Aug 2020 14:25:34 -0400 Message-ID: To: Ben Schwartz Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000051d14105ac8a1509" Archived-At: Subject: Re: [Add] DNS URI scheme (was SVCB for DNS) 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, 10 Aug 2020 18:25:50 -0000 --00000000000051d14105ac8a1509 Content-Type: text/plain; charset="UTF-8" Thanks for the new version. Much better without relying on the dns: URI scheme. I would suggest taking the removal of dns: even further and just deleting section 7 ("Relationship to DNS URIs"). The relationship is now that they're just not related at all and I think any attempt to explain it can only be more confusing than valuable. But now that the draft is not rooted in another reference for naming, I think the draft needs a bit more explanation on where the name comes from, further expanding on section 3 ("Name form"). Most DNS servers currently in use are known only by an IP address rather than a queryable name. Need text explaining how a name can be created for such servers or specifying that _dns cannot be queried for them. Also, I think we should set an expectation for how the name corresponds with DNS servers that do have a naturally queryable name from the DNS query URL, eg most DoT and DoH servers. Should we set the expectation that it will work if an implementation takes a known DoT/DoH URL and tacks on the "_dns." prefix? On Mon, Aug 10, 2020 at 1:34 PM Tommy Pauly wrote: > > > On Aug 10, 2020, at 8:56 AM, Ben Schwartz < > bemasc=40google.com@dmarc.ietf.org> wrote: > > > > On Sun, Aug 9, 2020 at 8:45 PM Martin Thomson wrote: > >> I wasn't going to respond and then I saw this... >> >> On Mon, Aug 10, 2020, at 05:03, Ben Schwartz wrote: >> > Note that the "authority" section is also optional in "https" URIs. >> >> This is not true in any way I can discern. Authority is mandatory in >> HTTP. >> > > You're right, at least in the IETF, RFC 7230 is pretty clear > that authority is mandatory. It turns out I am the latest victim of the > WHATWG vs. IETF URI/URL debacle. See e.g. > https://jsdom.github.io/whatwg-url/#url=aHR0cHM6L3NlZ21lbnQxL3NlZ21lbnQyP2tleT12YWx1ZQ==&base=aHR0cHM6Ly9leGFtcGxlLmNvbS8= > > ... > >> My model for URIs says that there is an entity that controls a portion of >> the namespace established for the scheme. That entity is identified by the >> authority component. The authority gets to say whatever it likes about >> resources that exist in the part of the namespace it controls. >> > > I think you might be disappointed by a lot of the defined URIs, e.g. > "ldap", "xmpp", "nntp". (Not that I necessarily disagree.) > > ... > >> I'm inclined to suggest that we NOT use dns:// URIs. Not because they >> aren't suitable - they fit surprisingly well to the use case - but because >> they are not good. >> > > OK, I've removed the dependency on dns:// URIs and cut a new version: > https://tools.ietf..org/html/draft-schwartz-svcb-dns-01 > . > > > Thanks for making that update. I think this tightens up the scope of the > proposal well. The use of the SVCB record for the DNS scheme makes sense, > and this seems like the right building block to use. > > Best, > Tommy > > > >> -- >> 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 > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000051d14105ac8a1509 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the new version.=C2=A0 Much better without rely= ing on the dns: URI scheme.

I would suggest taking the r= emoval of dns: even further and just deleting section 7 ("Relationship= to DNS URIs").=C2=A0 The relationship is now that they're just no= t related at all and I think any attempt to explain it can only be more con= fusing than valuable.

But now that the draft is no= t rooted in another reference for naming, I think the draft needs a bit mor= e explanation on where the name comes from, further expanding on section 3 = ("Name form").=C2=A0 Most DNS servers currently in use are known = only by an IP address rather than a queryable name.=C2=A0 Need text=C2=A0ex= plaining how a name can be created for such servers or specifying that _dns= cannot be queried for them.=C2=A0 Also, I think we should set an expectati= on=C2=A0for how the name corresponds with DNS servers that do have a natura= lly queryable name from the=C2=A0DNS query URL, eg most DoT and DoH servers= .=C2=A0 Should we set the expectation that it will work if an implementatio= n takes a known DoT/DoH URL and tacks on the "_dns." prefix?

On Mon, Aug 10, 2020 at 1:34 PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
<= /div>


On Aug 10= , 2020, at 8:56 AM, Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:



=
On Sun, Au= g 9, 2020 at 8:45 PM Martin Thomson <mt@lowentropy.net> wrote:
I wasn't going to respond and then= I saw this...

On Mon, Aug 10, 2020, at 05:03, Ben Schwartz wrote:
> Note that the "authority" section is also optional in "= https" URIs.

This is not true in any way I can discern.=C2=A0 Authority is mandatory in = HTTP.

You're right, at least in the= IETF, RFC 7230 is pretty clear that=C2=A0authority is mandatory.=C2=A0 It = turns out I am the latest victim of the WHATWG vs. IETF URI/URL debacle. Se= e e.g.=C2=A0https://jsdom.github.io/whatwg-url/#url=3DaHR0= cHM6L3NlZ21lbnQxL3NlZ21lbnQyP2tleT12YWx1ZQ=3D=3D&base=3DaHR0cHM6Ly9leGF= tcGxlLmNvbS8=3D
=C2=A0
...
My model for URIs says that there is an en= tity that controls a portion of the namespace established for the scheme.= =C2=A0 That entity is identified by the authority component.=C2=A0 The auth= ority gets to say whatever it likes about resources that exist in the part = of the namespace it controls.

I think y= ou might be disappointed by a lot of the defined=C2=A0URIs, e.g. "ldap= ", "xmpp", "nntp".=C2=A0 (Not that I necessarily d= isagree.)

...
I'm inclined to suggest that we NOT use dns:// URIs.= =C2=A0 Not because they aren't suitable - they fit surprisingly well to= the use case - but because they are not good.

OK, I've removed the dependency on dns:// URIs and cut a new ve= rsion:=C2=A0https://tools.ietf..org/html/draft-schwartz-svcb-dns-= 01.

Thanks for makin= g that update. I think this tightens up the scope of the proposal well. The= use of the SVCB record for the DNS scheme makes sense, and this seems like= the right building block to use.

Best,

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000051d14105ac8a1509-- From nobody Mon Aug 10 11:26: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 84A133A0A4A for ; Mon, 10 Aug 2020 11:26:18 -0700 (PDT) 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 Zy24rdh63yqv for ; Mon, 10 Aug 2020 11:26:16 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 4C04F3A0A3F for ; Mon, 10 Aug 2020 11:26:16 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id t7so8073935otp.0 for ; Mon, 10 Aug 2020 11:26:16 -0700 (PDT) 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=3luV3pkRDIyOOvrlIY3ZJ9IAZ6gja8ASfArd/GTkVVQ=; b=umFjkUg9QTKWgsyc3O6Xh9kHcsKUeT16TTJki5NUhk9gUrHeyP3VV7pylJp7Tb8tUL ow9oPISFMaqCj0pmZzB8DT9RFmqCW41iQvA6CBBZtf7NBNoAxknkt1dHnhKnYqVvuEP9 5o448xmc+WXpq0brHBIus9edEKy0Es1ROGq54Rc5O71FC6uEl0ALkyHcirIH+dHNOots c/G1DVn+MgOjehZ1NRu+8tHzYTYc6Ba46FY8tZmi7ERKk2G5TrNZ7wFerTZ3H91LcRLn B3l0zH58X3T/HG4jy/T7BruWWXYjfH2kLfMbZmTLO8dKU58rQVnGsd7ucBwi03kHTUB8 yYOQ== 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=3luV3pkRDIyOOvrlIY3ZJ9IAZ6gja8ASfArd/GTkVVQ=; b=Q/ZyF+JfSigAThEhWh08nqZlz0eEqyecI3VGVWu+y2KOOOAQV3i24yuWJxVMlOBn2g XUnvZ8naHHbFzayQSAplv05GKIVlLaitHjflwqukzHp3JseMfiY2FlQdAYMkEfr0jcmA xsvw7BcR+7Bm0St3SRT+lRaAbgO10ZgH5B+zi6UVEuzlw3Jx6Lyatn8yayBOngCkG6Ml u3FPt98yoOSCaTe7NgVsg4su4AM/2J4gV/Yfv1a2V0o+wNQBCmXKDmlYq2IxYsZU06nN mJkcV/+C0Tji2kzMX0FAgQd3sAEu5tJz2MfTzgo1QIRW3pdLQW+A4cp2AZ0lr4Rvyw8a ruLw== X-Gm-Message-State: AOAM532g0NsJ9M77YKwO7I9C9y+fh31WbfmhOu59NegwqA9ik7CcsTPu ag1h9GC5hcdFdPJUJN60eHi65y2Z8P6XBLORM4R85sJlM9k= X-Google-Smtp-Source: ABdhPJzjz8ropdnW1RbMcITrM1TabwY8EPsB9pgR2BrQxDkJ7j6910zhQpXE81U8zLrnyQFjraX/3u7Ky4RxHiE/7kY= X-Received: by 2002:a9d:7c94:: with SMTP id q20mr1812982otn.165.1597083975319; Mon, 10 Aug 2020 11:26:15 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> In-Reply-To: From: Ted Hardie Date: Mon, 10 Aug 2020 11:25:48 -0700 Message-ID: To: Martin Thomson Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000000685b405ac8a179c" Archived-At: Subject: Re: [Add] DNS URI scheme (was SVCB for DNS) 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, 10 Aug 2020 18:26:19 -0000 --0000000000000685b405ac8a179c Content-Type: text/plain; charset="UTF-8" Howdy, I don't have a problem with this draft removing dns: URIs, but I do have some comments on Martin's issues below. On Sun, Aug 9, 2020 at 5:45 PM Martin Thomson wrote: > I wasn't going to respond and then I saw this... > > On Mon, Aug 10, 2020, at 05:03, Ben Schwartz wrote: > > Note that the "authority" section is also optional in "https" URIs. > > This is not true in any way I can discern. Authority is mandatory in HTTP. > > But then I realized that I don't like what this draft implies. > > Eric's question is entirely fair. I also believe that that your response > is accurate based on the definition of the dns: scheme. RFC 4501 defines > the authority component as optional, and uses it to indicate a resolver. > It's a little vague on this point, but it strongly implies that it refers > to a recursive resolver. > > This is deeply awkward, because it uses URI terms to imply that the zone is > not the authority for the data provided. That suits the SVCB usage > perfectly here, but it completely breaks my conception of what authority in > a URI is. I hope that I'm not the only one. > > My model for URIs says that there is an entity that controls a portion of > the namespace established for the scheme. That entity is identified by the > authority component. The authority gets to say whatever it likes about > resources that exist in the part of the namespace it controls. > > Unusually, RFC 4501 actually has a usage model set out in the document, which describes how the scheme is intended to be used (Section 2 ). The second paragraph of that is pretty clear on the basic model: The URI scheme described in this document focuses on the data stored in the DNS. As such, there is no provision to specify any of the fields in the actual DNS protocol. This is intended so that the URI may be used even in situations where the DNS protocol is not used directly. Two examples for this are zone file editors and DNS- related configuration files, which may use this URI scheme to identify data. The application would not use the DNS protocol to resolve the URIs. This is reinforced in Section 3: Intended usage: Whenever it is useful for DNS resources to be referenced by protocol-independent identifiers. Often, this occurs when the data is more important than the access method. Since software in general has coped without this so far, it is not anticipated to be implemented widely, nor migrated to by existing systems, but specific solutions (especially security-related) may find this appropriate. The authority section is optional, but permitted, in this scheme for use in cases where a specific hostname and port are to be accessed to retrieve the data. Even when those are supplied, the presumption remains that the reference is to data as stored in the DNS. The normal DNS chain of delegation applies, and the hostname and port have no necessary relationship to the zone maintainer for the DNS delegation of the zones related to the named data. I have seen these used in the wild to reference resources in a split DNS context where only the "internal" resolver would have access to specific parts of the DNS, but even that doesn't change the base model, which still presumes that the reference is to the data stored whether or not it is currently accessible to you. RFC 3986 says this in it discussion of the authority component: Many URI schemes include a hierarchical element for a naming authority so that governance of the name space defined by the remainder of the URI is delegated to that authority (which may, in turn, delegate it further). I suspect this is the source of your discomfort. But that use of the hierarchical element is not the only use, as further reading in the description of "host" would make clear. There are cases where it is intended to be the host you connect to and not the controller of a subsidiary namespace. Most of those cases, like telnet, have no subsidiary namespaces, but some, like XMPP, allow references to resources expected to be distinct from the server named in the authority (note that XMPP URIs also have optional authorities). There are also many cases where the URL scheme references a namespace controlled elsewhere. An example you may remember is the skype scheme, where a phone number is permitted; skype clearly is not the namespace authority for E164 numbers but it has the ability to use them in its functioning. It would have been clearer for me if dns://example.com/ was tied to the > QNAME and the authority were the authoritative server for the name. > > As noted above, that would not have met some of the use cases desired. > Authority == authoritative has a nice bit of symmetry. And QNAME as > authority would still allow dns:// URIs to be locators, but it would have > only required either recursion or use of a recursive. And you could > authenticate the results with DNSSEC. All very neat. But that's not what > RFC 4501 defines. > > Resolver as authority is convenient for this particular use case, but it > implies that the resolver somehow confers authority. > > That RFC 4501 fails to define a means of authenticating resolvers further > undermines the utility of the scheme. > I think it would be fairer to say that its use case and the one you are concerned with overlap but are not congruent. RFC 4501 presumes that you are concerned with the data in the DNS, and it provides you a protocol-agnostic way of referencing that. You can use it to refer to the DNS data required to do a DNSSEC validation; that is within scope even if not one of the examples. But it not only does not imply that the resolver confers authority, it does not even imply which resolution method you are using to get at the data. regards, Ted Hardie > > I'm inclined to suggest that we NOT use dns:// URIs. Not because they > aren't suitable - they fit surprisingly well to the use case - but because > they are not good. > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000000685b405ac8a179c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

I do= n't have a problem with this draft removing dns: URIs, but I do have so= me comments on Martin's issues below.

On Sun, Aug 9, 2020 at 5= :45 PM Martin Thomson <mt@lowentrop= y.net> wrote:
I wasn't going to respond and then I saw this...

On Mon, Aug 10, 2020, at 05:03, Ben Schwartz wrote:
> Note that the "authority" section is also optional in "= https" URIs.

This is not true in any way I can discern.=C2=A0 Authority is mandatory in = HTTP.

But then I realized that I don't like what this draft implies.

Eric's question is entirely fair. I also believe that that your respons= e is accurate based on the definition of the dns: scheme.=C2=A0 RFC 4501 de= fines the authority component as optional, and uses it to indicate a resolv= er.=C2=A0 It's a little vague on this point, but it strongly implies th= at it refers to a recursive resolver.
=C2=A0
This is deeply awkward, because it uses URI terms to imply that the zone is= not the authority for the data provided.=C2=A0 That suits the SVCB usage p= erfectly here, but it completely breaks my conception of what authority in = a URI is.=C2=A0 I hope that I'm not the only one.
=C2=A0
My model for URIs says that there is an entity that controls a portion of t= he namespace established for the scheme.=C2=A0 That entity is identified by= the authority component.=C2=A0 The authority gets to say whatever it likes= about resources that exist in the part of the namespace it controls.


Unusually, RFC 4501 actually has a usa= ge model set out in the document, which describes how the=C2=A0 scheme is i= ntended to be used (Section 2).=C2=A0 The second paragraph of that is pretty clear o= n the basic model:

  =
 The URI scheme described in this document focuses on the data stored
   in the DNS.  As such, there is no provision to specify any of the
   fields in the actual DNS protocol.  This is intended so that the URI
   may be used even in situations where the DNS protocol is not used
   directly.  Two examples for this are zone file editors and DNS-
   related configuration files, which may use this URI scheme to
   identify data.  The application would not use the DNS protocol to
   resolve the URIs.
This is reinforced in Section 3:

   Intended usage: Whene=
ver it is useful for DNS resources to be
   referenced by protocol-independent identifiers.  Often, this occurs
   when the data is more important than the access method.  Since
   software in general has coped without this so far, it is not
   anticipated to be implemented widely, nor migrated to by existing
   systems, but specific solutions (especially security-related) may
   find this appropriate.
The authority section is optional, but permitted, in this = scheme for use in cases where a specific hostname and port are to be access= ed to retrieve the data.=C2=A0 Even when those are supplied, the presumptio= n remains that the reference is to data as stored in the DNS.=C2=A0 The nor= mal DNS chain of delegation applies, and the hostname and port=C2=A0 have n= o necessary relationship to the zone maintainer for the DNS delegation of t= he zones related to the named data.=C2=A0=C2=A0 I have seen these used in t= he wild to reference resources in a split DNS context where only the "= internal" resolver would have access to specific parts of the DNS, but= even that doesn't change the base model, which still presumes that the= reference is to the data stored whether or not it is currently accessible = to you.

RFC 3986 says this in it discussion of the= authority component:

   Many URI schemes include a hierarchical element for a naming
   authority so that governance of the name space defined by the
   remainder of the URI is delegated to that authority (which may, in
   turn, delegate it further).
I suspect this is the source of your di= scomfort.=C2=A0 But that use of the hierarchical element is not the only us= e, as further reading in the description of "host" would make cle= ar.=C2=A0 There are cases where it is intended to be the host you connect t= o and not the controller of a subsidiary namespace.=C2=A0 Most of those cas= es, like telnet, have no subsidiary namespaces,=C2=A0 but some, like XMPP,= =C2=A0 allow references to resources expected to be distinct from the serve= r named in the authority (note that XMPP URIs also have optional authoritie= s).=C2=A0 There are also many cases where the URL scheme references a names= pace controlled elsewhere. =C2=A0 An example you may remember is the skype = scheme, where a phone number is permitted; skype clearly is not the namespa= ce authority for E164 numbers but it has the ability to use them in its fun= ctioning.

It would have been clearer for me if dns://example.com/ was tied to the QNAME= and the authority were the authoritative server for the name.=C2=A0

As noted above, that would not have met some of the u= se cases desired.

=C2=A0
Authority =3D=3D authoritative has a nice bit of symmetry.=C2=A0 And QNAME = as authority would still allow dns:// URIs to be locators, but it would hav= e only required either recursion or use of a recursive.=C2=A0 And you could= authenticate the results with DNSSEC.=C2=A0 All very neat.=C2=A0 But that&= #39;s not what RFC 4501 defines.

Resolver as authority is convenient for this particular use case, but it im= plies that the resolver somehow confers authority.=C2=A0

That RFC 4501 fails to define a means of authenticating resolvers further u= ndermines the utility of the scheme.

I = think it would be fairer to say that its use case and the one you are conce= rned with overlap but are not congruent.=C2=A0 RFC 4501 presumes that you a= re concerned with the data in the DNS, and it provides you a protocol-agnos= tic way of referencing that.=C2=A0 You can use it to refer to the DNS data = required to do a DNSSEC validation; that is within scope even if not one of= the examples.=C2=A0 But it not only does not imply that the resolver confe= rs authority, it does not even imply which resolution method you are using = to get at the data.=C2=A0

regards,
=
Ted Hardie
=C2=A0

I'm inclined to suggest that we NOT use dns:// URIs.=C2=A0 Not because = they aren't suitable - they fit surprisingly well to the use case - but= because they are not good.

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000000685b405ac8a179c-- From nobody Mon Aug 10 13:56: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 8B8633A0D82 for ; Mon, 10 Aug 2020 13:56:20 -0700 (PDT) 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, 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 EsgjHTseTdPS for ; Mon, 10 Aug 2020 13:56:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8E23A0D81 for ; Mon, 10 Aug 2020 13:56:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B746F389D9; Mon, 10 Aug 2020 16:35:33 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4KUgPIECKOQp; Mon, 10 Aug 2020 16:35:33 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B0273389D5; Mon, 10 Aug 2020 16:35:32 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4C3E8724; Mon, 10 Aug 2020 16:56:16 -0400 (EDT) From: Michael Richardson To: Eric Rescorla , ADD Mailing list In-Reply-To: References: <15378.1597020454@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Add] Requirements drafts 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, 10 Aug 2020 20:56:21 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: >> Chris Box (BT) wrote: >> > I'm not especially in favour of pursuing "discover whether using a >> resolver >> > X is acceptable". >> >> A case that I was thinking about is when on trains/aircraft. >> You *CAN* use some external resolver, but the performance will be awful. >> > Is this in fact true? Back when I used to fly, I used to use DoH quite a > bit as well as > using browsers that were not configured with DoH and I never really noticed > a material difference. My experiences have been on pooly provisioned trains, where the bufferbloat meant that DNS requests took many seconds. Yes Ted, *I* can run a local, caching, recursive DNSSEC resolver. I do. But my phone doesn't. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8xtHAACgkQgItw+93Q 3WWw6wf+OMvI8sn230UbwVyulSWH1a62Io9EondY7WtwMAG1B+eJAQE5u94h3ksO m4t8U8xogsXhirjcGi1RJRVCl3rb8oqGdsBhMtX1tpk0i93jEWAop9HKsQQbnDxI MtDVDve6NRMqkggPWtUmpiXhWtsRCsfyv2wC9nMeP538y3ST0xqzG4kczJ+4UPuX vL7+RtxEn9obKYEnvrs9/jHiASMZQDb4Y0Q5BQUJhtdx74DmWmcn+lyG5ahVFax8 38Yp4kBR/mjDOZS1+rLBD457iLnUDXgS8vZpOoyTXQbHzyvBmmakiBOHgSdw6jrv LODwn1+N+b34CR3E98G1Wc2yLMDbLw== =nA+H -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 10 14:41: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 6D9ED3A0D86 for ; Mon, 10 Aug 2020 14:41:30 -0700 (PDT) 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 P-4VFqpyUN-G for ; Mon, 10 Aug 2020 14:41:29 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 102B83A0D38 for ; Mon, 10 Aug 2020 14:41:29 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id t15so10529404iob.3 for ; Mon, 10 Aug 2020 14:41:29 -0700 (PDT) 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=ydSIPqvyty+WuW2G1dUAKdKYhq41XJ+WPsurqsz20BU=; b=QZ4sKqW/3UIzxHCYK7LyQGrMuWo03vFXBjCyuBClmpgmSTSmID6jJCjseZdw8Qn3+D Oa/Y3Aw2IVDnOPrx6WR4O/g7/g1wcq/Afoffbw6YR0/WUsMK4XJDx+MLDDNNoeKtwpeL 3g9YiEIUGW5r183ZyD/fBSjYL1KjHZD1/67NDFDASga7dtXq8y2/tca+G0eO11W3bP/3 IIbZ9vHDGdr2OsW16dovVnnpM3e6svhYhKyDvCEzBSH7Y+VdAVtBBBtibW31lH8w6+dG Xjv8L7suGEgSZCZNt/aRw1ZvPquzpfNTYoyifcVSApxKwPNIQZDU7s2gZbeoXYIF6/tQ d1EA== 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=ydSIPqvyty+WuW2G1dUAKdKYhq41XJ+WPsurqsz20BU=; b=cp+9k9Jo5bEiSe34YzaycFYGkZ2d4n8n9OuXtYF9al69CvwmKljx0op9STtZrGcGcf QcUPkr31HCUAw9V7Bk6z9EaEumDhirI+Tea5Q1vh8OQzmxTiIZQQB6AYrsI0AcJRP+F3 RpmJPq++wgs6cE6SJJwwOIrGgIf+3htwEGdfV/Bukmeo2VNrP5p+4wfVBNbuFOSr4O2F X6VwHHUko+TgancV3SJYpVAWu98jOi5exLOjHTKyKzoBwZIkNfoD7Vv8HygsrJ2F0a5L 9pCEDIw6DIlfRImxHyvHaohr5wYSdgNVVXskxv0Pns+iI2qC0GHDdDB8jJ7cATIJyLC2 kkww== X-Gm-Message-State: AOAM530YTtC6pZl7CP+4KPLtQMiGQgRtpUivtOn1UQ3sY2DagPskqHBE 3jX1KauWnDRhnHmSUoLqRqMOEtzgwsEXu3wp+Mc= X-Google-Smtp-Source: ABdhPJx/O4PAs+O3DJNH1kB+6a0rEMP5unD3WM4ZeiYhXcVM3AjG9mHOD+DsBLe8pxcLdxNhBN5zHmY5thFFjNYbnFM= X-Received: by 2002:a05:6638:2493:: with SMTP id x19mr22961914jat.53.1597095688034; Mon, 10 Aug 2020 14:41:28 -0700 (PDT) MIME-Version: 1.0 References: <15378.1597020454@localhost> In-Reply-To: From: Rob Sayre Date: Mon, 10 Aug 2020 14:41:16 -0700 Message-ID: To: Eric Rescorla Cc: Michael Richardson , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000002873d705ac8cd152" Archived-At: Subject: Re: [Add] Requirements drafts 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, 10 Aug 2020 21:41:30 -0000 --0000000000002873d705ac8cd152 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 10, 2020 at 6:49 AM Eric Rescorla wrote: > > > On Sun, Aug 9, 2020 at 5:47 PM Michael Richardson > wrote: > >> >> Chris Box (BT) wrote: >> > I'm not especially in favour of pursuing "discover whether using a >> resolver >> > X is acceptable". >> >> A case that I was thinking about is when on trains/aircraft. >> You *CAN* use some external resolver, but the performance will be awful. >> > > Is this in fact true? Back when I used to fly, I used to use DoH quite a > bit as well as > using browsers that were not configured with DoH and I never really > noticed a material > difference. > The only issue I've noticed with DoH or VPN on planes are CAPPORT issues--meaning the initial WiFi sign-in might not work. Besides that, I haven't noticed anything other than DoH or VPNs occasionally being better than using the airline DNS server... thanks, Rob --0000000000002873d705ac8cd152 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 10, 2020 at 6:49 AM Eric Resc= orla <ekr@rtfm.com> wrote:


On Sun, Aug 9, 2020 at 5:47 PM M= ichael Richardson <mcr+ietf@sandelman.ca> wrote:

Chris Box (BT) <chris.box.ietf@gmail.com> wrote:
=C2=A0 =C2=A0 > I'm not especially in favour of pursuing "disco= ver whether using a resolver
=C2=A0 =C2=A0 > X is acceptable".

A case that I was thinking about is when on trains/aircraft.
You *CAN* use some external resolver, but the performance will be awful.

Is this in fact true? Back when I used to= fly, I used to use DoH quite a bit as well as
using browsers tha= t were not configured with DoH and I never really noticed a material
<= div>difference.

The only = issue I've noticed with DoH or VPN on planes are CAPPORT issues--meanin= g the initial WiFi sign-in might not work. Besides that, I haven't noti= ced anything other than DoH or VPNs occasionally being better than using th= e airline DNS server...

thanks,
Rob

--0000000000002873d705ac8cd152-- From nobody Mon Aug 10 14:42:43 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 88BC93A0DB0 for ; Mon, 10 Aug 2020 14:42:42 -0700 (PDT) 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 f5bM8D8FnuUC for ; Mon, 10 Aug 2020 14:42:40 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 5F1BD3A0D86 for ; Mon, 10 Aug 2020 14:42:40 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id c15so5534901lfi.3 for ; Mon, 10 Aug 2020 14:42:40 -0700 (PDT) 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=EKJlzoYYvCdIqGfIJZvWYQrerLXryk0aX6PGBGjlyW4=; b=PJO01qOJ6YdeUOk5V6cMh3dgQ9357d2UltOhPa+xTnpcE+OTKG2owovv7nOxWeJFVz MIdZ+UrrJq8dsQh0bc9e1sWnJ7sj/VbnE2Xeq9D/3Yq80hfZ4hiEnUaUttUSRjDM2wMO bChl9dRQYY2IW528DvD5yOrsZ1yrmBeLps/edcf8Jt/MoungqSa/6lgZGj8lestgX6fG 9obmF8QmKxAwrYOZAfbw1lA4M9SBVq7El9a8WdNc5gAzRMx/JEW9MVd/6noFKJITkA/l PBHXekFafWj7ap9BOmjiLSs42hZhsBSHAXCYggglHsdzZlQUjFIR8OSjOn363lAcFcjD E2XQ== 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=EKJlzoYYvCdIqGfIJZvWYQrerLXryk0aX6PGBGjlyW4=; b=TGr3Vw8CE3sBjSzBVEuTREYJuAhSk4IwgJmXHFwYPbVrgc3FRilrltkD+P99MNonu6 Tvk3AtP9GO9ePmh2lVPhdwsMuxEBSITjLVOWENVPAqE9wzvTGjX/VOGZm3UJjb81p4IB JoAnRMMWm/XbkfHCrICWkBhwxgh/rwmyRLhoCZ3NmuP6YiOwXr6Sqk8vIdJIq3gwf5eB hyTmi2g9nJemQXwMIGYiDf0BMamgNDDi9PoFih31AVCW60tZ/5rjwUrEN2crf1s0665X ioA91BjL42KTFovwwXdG1O+iRJxr/X0vf/oEkxrkZffyeFhh2wlHDCLHHYqyUkhbKncg 0xeg== X-Gm-Message-State: AOAM5307ga4lQWbsLrXvvWecQ1aeLGvYGEU2vwTw1hKA1+S39HdAa0ix yG4XN426dRCVjWxAaO1BMSpUMzTyyl2fbrlPDWQumY3RH8I= X-Google-Smtp-Source: ABdhPJwIYlG74g32fPbqv9wrewoNL7o3/xWBQn+hYmO0PKHDnLbcO9/p39IIz2zSCLApu+4dJSlMex/JHZwI7jpukNY= X-Received: by 2002:a05:6512:3444:: with SMTP id j4mr1529447lfr.161.1597095758603; Mon, 10 Aug 2020 14:42:38 -0700 (PDT) MIME-Version: 1.0 References: <15378.1597020454@localhost> <29445.1597092976@localhost> In-Reply-To: <29445.1597092976@localhost> From: Eric Rescorla Date: Mon, 10 Aug 2020 14:42:02 -0700 Message-ID: To: Michael Richardson Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000005d3e4005ac8cd570" Archived-At: Subject: Re: [Add] Requirements drafts 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, 10 Aug 2020 21:42:43 -0000 --0000000000005d3e4005ac8cd570 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 10, 2020 at 1:56 PM Michael Richardson wrote: > > Eric Rescorla wrote: > >> Chris Box (BT) wrote: > >> > I'm not especially in favour of pursuing "discover whether using a > >> resolver > >> > X is acceptable". > >> > >> A case that I was thinking about is when on trains/aircraft. > >> You *CAN* use some external resolver, but the performance will be > awful. > >> > > > Is this in fact true? Back when I used to fly, I used to use DoH > quite a > > bit as well as > > using browsers that were not configured with DoH and I never really > noticed > > a material difference. > > My experiences have been on pooly provisioned trains, where the bufferbloat > meant that DNS requests took many seconds. > Doesn't this have a similarly negative effect on the content you actually want to retrieve which presumably goes over TCP? -Ekr > Yes Ted, *I* can run a local, caching, recursive DNSSEC resolver. I do. > But my phone doesn't. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --0000000000005d3e4005ac8cd570 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 10, 2020 at 1:56 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Eric Rescorla <ekr@rtf= m.com> wrote:
=C2=A0 =C2=A0 >> Chris Box (BT) <chris.box.ietf@gmail.com> wrote:
=C2=A0 =C2=A0 >> > I'm not especially in favour of pursuing &q= uot;discover whether using a
=C2=A0 =C2=A0 >> resolver
=C2=A0 =C2=A0 >> > X is acceptable".
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> A case that I was thinking about is when on trains/a= ircraft.
=C2=A0 =C2=A0 >> You *CAN* use some external resolver, but the perfor= mance will be awful.
=C2=A0 =C2=A0 >>

=C2=A0 =C2=A0 > Is this in fact true? Back when I used to fly, I used to= use DoH quite a
=C2=A0 =C2=A0 > bit as well as
=C2=A0 =C2=A0 > using browsers that were not configured with DoH and I n= ever really noticed
=C2=A0 =C2=A0 > a material difference.

My experiences have been on pooly provisioned trains, where the bufferbloat=
meant that DNS requests took many seconds.

<= div>Doesn't this have a similarly negative effect on the content you ac= tually want to retrieve which presumably goes over TCP?

-Ekr


Yes Ted, *I* can run a local, caching, recursive DNSSEC resolver. I do.
But my phone doesn't.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



--0000000000005d3e4005ac8cd570-- From nobody Mon Aug 10 15:32:47 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 4C6153A0DC9 for ; Mon, 10 Aug 2020 15:32:45 -0700 (PDT) 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, 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 1hysGHYKT_jt for ; Mon, 10 Aug 2020 15:32:44 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 DFFB93A0DC7 for ; Mon, 10 Aug 2020 15:32:43 -0700 (PDT) Received: by sdaoden.eu (Postfix, from userid 1000) id C7A7216056; Tue, 11 Aug 2020 00:32:41 +0200 (CEST) Date: Tue, 11 Aug 2020 00:32:41 +0200 From: Steffen Nurpmeso To: Rob Sayre Cc: Eric Rescorla , Michael Richardson , ADD Mailing list , Steffen Nurpmeso Message-ID: <20200810223241.6F-6g%steffen@sdaoden.eu> In-Reply-To: References: <15378.1597020454@localhost> Mail-Followup-To: Rob Sayre , Eric Rescorla , Michael Richardson , ADD Mailing list , Steffen Nurpmeso User-Agent: s-nail v14.9.19-103-ga01f6c13 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Add] Requirements drafts 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, 10 Aug 2020 22:32:45 -0000 Rob Sayre wrote in : |On Mon, Aug 10, 2020 at 6:49 AM Eric Rescorla wrote: |> On Sun, Aug 9, 2020 at 5:47 PM Michael Richardson |> wrote: |>> Chris Box (BT) wrote: |>>> I'm not especially in favour of pursuing "discover whether using a |>> resolver |>>> X is acceptable". |>> |>> A case that I was thinking about is when on trains/aircraft. |>> You *CAN* use some external resolver, but the performance will be awful. |> |> Is this in fact true? Back when I used to fly, I used to use DoH quite a |> bit as well as |> using browsers that were not configured with DoH and I never really |> noticed a material |> difference. | |The only issue I've noticed with DoH or VPN on planes are CAPPORT |issues--meaning the initial WiFi sign-in might not work. Besides that, I |haven't noticed anything other than DoH or VPNs occasionally being better |than using the airline DNS server... | |thanks, Quite off-topic, but i did not fly in thirty-three years. By then airplanes were dirty ressource hogs. (Luckily the new load of Musk satellites addressed that terrible glowing from the solar panels i think it is, it was so depressing to see that line of artificial stuff that here in Germany and even Europe noone needs in a ~30 second interval, right after they have been started.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Mon Aug 10 17:49:47 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 238D13A0E6B for ; Mon, 10 Aug 2020 17:49:46 -0700 (PDT) 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, 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 Nvx2yK-03evr for ; Mon, 10 Aug 2020 17:49:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD423A0E6A for ; Mon, 10 Aug 2020 17:49:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AF624389D5; Mon, 10 Aug 2020 20:28:58 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 59HT_0SoSQT9; Mon, 10 Aug 2020 20:28:58 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D5BD5389A5; Mon, 10 Aug 2020 20:28:57 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 78B9A10DF; Mon, 10 Aug 2020 20:49:41 -0400 (EDT) From: Michael Richardson To: Eric Rescorla cc: ADD Mailing list In-Reply-To: References: <15378.1597020454@localhost> <29445.1597092976@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Add] Requirements drafts 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 Aug 2020 00:49:46 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: >> My experiences have been on pooly provisioned trains, where the bufferbloat >> meant that DNS requests took many seconds. >> > Doesn't this have a similarly negative effect on the content you actually > want to retrieve which presumably goes over TCP? It depends upon what you are trying to do. Bufferbloat'ed networks do good jobs of delivering large web blobs, and video. They are terrible for interactive use. A feature of offsite DoH/DoT would be that the networks would more visibly suck for all users, and those can get fixed, might get fixed. Those that can't be fixed, because of existing terrestial/satellite limits would probably benefit from as much local DNS caching as possible. One certainly can't do interactive ssh from many trains. (Thalys is among the worst I've seen, and many others have agreed, but Canada's VIA Rail system is a close second) But, I don't have to wait for IMAP/POP3 or SMTP, it happens in the background, so it's okay if it takes many seconds per command. And IMAP supports multiple commands, but I personally tend not to use it that way. Once the data starts flowing, things are okay. git pushes/pulls are a toss-up. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8x6yUACgkQgItw+93Q 3WXQkgf/RFXe00hd1YMBCWnlzcvQ526XnyqlTP0+AXde010uWWUklYlyKu2RX2ZB iX/fP2g1gpB8sdsB1r9OfI+3p1Q6yAaB5niot1A48m3X17wQ7Y+iFBtFU4Qe8sDS UDK0kPbng+EEUyJIYxcdLzJiFQPe0A1uqU/Q+nVQfYa02T6sIaWCVY6S5GB9+QOz gkIRkOcTOy5PHxZpwdXsSEgF+zTdl0ak290xeHSzRc9ll1IgUhwjM4EdzCehZQvt urKIO15lQV2o9preRiWfjRp/qC2U7G4lbE1s+zNYAfZQFyHKTOckrDEZIRHcZhV0 FOio8AxQ8UgFrw8Coey8RiGyJQEwpw== =6Y5l -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 10 18:34: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 B0B9A3A0E9E for ; Mon, 10 Aug 2020 18:34:26 -0700 (PDT) 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, 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 (2048-bit key) header.d=lowentropy.net header.b=JOSEqZaC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=t6CO7xvo 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 DraiyPbLhi2r for ; Mon, 10 Aug 2020 18:34:24 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783463A0E98 for ; Mon, 10 Aug 2020 18:34:24 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D8C505C01BD; Mon, 10 Aug 2020 21:34:23 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 10 Aug 2020 21:34:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=0GV2tB+hkM8yZ0LnElnD7gTAw+DT HzcF6Pzcg4yN7Sw=; b=JOSEqZaCVrrD3rltwV0F8LSfDZRt5aIvskNDBi90ZFOe 6oDu89EK/k7cx/DgNUCm9csR/MHeWa04cgx/vOJTqKr/QRTOFj29L7NXR3n83DLD LUq9/J9O9+QRRQtT4aRiastkTomrk28X/9EBnNJx/boVBxR9mZsbEUNKy7zodYh/ rRcaccmMr48UzYE+hSDHpAGnBiF8d1YlU5YB/nvqUbhpaPDD+TDbd85zbQgxzIQV 0gSUFbYfVkik/5rsggru1+8/wC6ELK8tTBHy+elq2dvw1DuyBE5FyeQuZMi1uqtW YH85W9i+8LKcbbpe9OJGDkyTSjpz8W+/ZkE3hvqgPQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=0GV2tB +hkM8yZ0LnElnD7gTAw+DTHzcF6Pzcg4yN7Sw=; b=t6CO7xvo76VVAu2WOLLPnA W8A2hf/c/S2E3Kt/adVRkInoOYYxZnx22N5RN9esiSjY118zozU9Nt7Tww6+Ot/N 7XBjulKn2c1x1/tkMxhCD16tf+AEVggQq3SYYq4B/SPVX516aJrXiKNSFcwCMLD9 0c+AlpX4k/44UMj94L464oiqYzSYh55daTGlKm/BumNMecgrcBG780HxllmBGoH1 uJkbApVLXu4JUX5G1A30n72Ze48HkuSf2yqOsA9EsdXmnwnNCMar3W9Ap8uhH5qd r2CKj2GNInzbXtRZ69nt08UAH+Kdl07kZVni+bNiDLTKZBnDZz/XBr2KAMOqxSJg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrkeelgdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnheptdefkedvhfdtvdelgedtff ffgfdugfdufedthfeujeeutdelfeeuvefgledutdehnecuffhomhgrihhnpegvgigrmhhp lhgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A4241E00A6; Mon, 10 Aug 2020 21:34:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-143-g3d58b38-fm-20200806.002-g3d58b387 Mime-Version: 1.0 Message-Id: <12aa68dc-3d37-45a5-ab78-87ddf65eb20b@www.fastmail.com> In-Reply-To: References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> Date: Tue, 11 Aug 2020 11:34:04 +1000 From: "Martin Thomson" To: "Ted Hardie" Cc: "ADD Mailing list" Content-Type: text/plain Archived-At: Subject: Re: [Add] DNS URI scheme (was SVCB for DNS) 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 Aug 2020 01:34:27 -0000 On Tue, Aug 11, 2020, at 04:25, Ted Hardie wrote: > RFC 3986 says this in it discussion of the authority component: > > Many URI schemes include a hierarchical element for a naming > authority so that governance of the name space defined by the > remainder of the URI is delegated to that authority (which may, in > turn, delegate it further). > > I suspect this is the source of your discomfort. Yep. > But that use of the hierarchical element is not the only > use, as further reading in the description of "host" would make clear. I'm not picking up on anything there. Care to point to it? Interpreting this particular document has never been easy. > There are cases where it is intended to be the host you connect to and > not the controller of a subsidiary namespace. Skype doesn't appear to use the authority form, so that isn't relevant here. But delegating to E.164 as part of a scheme is entirely reasonable. (In this regard, I'm curious as to why tel: is not tel://; the syntax would seem to fit reg-name.) The XMPP usage is a stronger example, so I guess it's good for my argument that it's now a defunct protocol. telnet:// clearly indicates a resource with a clear authority, even if it can't be authenticated. (The same might be said for ssh:// if the 2006 secsh draft is representative; and for vnc://, both of which fit your model here.) > > It would have been clearer for me if dns://example.com/ was tied to the QNAME and the authority were the authoritative server for the name. > > > As noted above, that would not have met some of the use cases desired. I personally see negative utility in those use cases, but I appreciate that others have those use cases. > I think it would be fairer to say that its use case and the one you are > concerned with overlap but are not congruent. This is a fine conclusion :) > But it not only does not imply that > the resolver confers authority, it does not even imply which resolution > method you are using to get at the data. That is clearly true for the definition of the scheme. I still believe that it is a bad idea to define a scheme that way. From nobody Mon Aug 10 19:09: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 00DDA3A0EDB for ; Mon, 10 Aug 2020 19:09:18 -0700 (PDT) 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 n8ByYmSXVl20 for ; Mon, 10 Aug 2020 19:09:16 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 471123A0EC2 for ; Mon, 10 Aug 2020 19:09:16 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id 25so10872934oir.0 for ; Mon, 10 Aug 2020 19:09:16 -0700 (PDT) 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=EaJcohsmttzWKRjvPXcGJtztOCQqMX2x3gqJisSXHvI=; b=szkTNbcvnoVZ9rN3d+dWutgiRzsajWbSqN2zqnV9DrY9dsz/UqDfZTRb6jfcvk92Gt A2y1tgxw2+1V4dYYEDQSzfFp5Pm6+C1OFnI9YK5AdzLqMxrTomxyrm/sFILqwdOlYdND OEzdKGvAQHB3j28PtanQvLV8chNEBjzey8RUnyuhyyPrcyR/Jr9HFHtv/IroFPgLsE5R ONfMWN9Oa3qJknxmLsn5+HHxZ6U/8e3IDgNJvIoAeBaR5/681Ga/PaGXnO+tnQkGRes0 72h9UwDgjTPu33LFb3sx8H5QiOVikPllpizjTjQxqw5YKS7nlBMO3j3g0a7lk6wu8McR 5n4Q== 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=EaJcohsmttzWKRjvPXcGJtztOCQqMX2x3gqJisSXHvI=; b=GiTLJNygDk25/VP7XhxKrTs0cwpFFoQSCIAGUVW9sXdm3JEwpRgAZG3Cn8UIVk6JV7 pJAsSYfEIZL2nUZRa9XkFcqSWtZf6xP8yBcDuT9lZhfnh4sL2r+OhfJqb7VVxndqaSIZ /+mFvs+4Z2Z0rru3NY3NDjaxqkoRRMSts61MhCHtxbCV7kfw+irkSHWUBPAxlBZdqSky mVEluQYQ0L+7BRjRSzjdX64Q6a9gf9Hk5vNQXYa+ylhrZDe6yxo1T8wuMdBtNy0RUz7t 3SFC0zTzhE6hlxLn3qDoLJzhEiKX7aDXxYQ/AtMajKDgjfo4KkEeU+kdg8ACTk0AZYqZ YY7A== X-Gm-Message-State: AOAM532gZBPs5vZbVbzWccxj3ib28m9Sc0emsSvId38CwWbJ//6e1kgl MebNUOqG5rYqwF3V+K4NsR7Olm/TPFQktKNSgiKR6WPorZ0= X-Google-Smtp-Source: ABdhPJyZ3eTny1cX8sdZ2Pm5sELdEYN06m+7OgTwD6OZr1OT5n8pTtJLPuIA5sWvyrdDWf0aCSLEigfJ1CAnfFl+mUY= X-Received: by 2002:aca:d4d3:: with SMTP id l202mr1837301oig.167.1597111755530; Mon, 10 Aug 2020 19:09:15 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> <12aa68dc-3d37-45a5-ab78-87ddf65eb20b@www.fastmail.com> In-Reply-To: <12aa68dc-3d37-45a5-ab78-87ddf65eb20b@www.fastmail.com> From: Ted Hardie Date: Mon, 10 Aug 2020 19:08:49 -0700 Message-ID: To: Martin Thomson Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000dae56505ac908e3d" Archived-At: Subject: Re: [Add] DNS URI scheme (was SVCB for DNS) 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 Aug 2020 02:09:21 -0000 --000000000000dae56505ac908e3d Content-Type: text/plain; charset="UTF-8" On Mon, Aug 10, 2020 at 6:34 PM Martin Thomson wrote: > On Tue, Aug 11, 2020, at 04:25, Ted Hardie wrote: > > RFC 3986 says this in it discussion of the authority component: > > > > Many URI schemes include a hierarchical element for a naming > > authority so that governance of the name space defined by the > > remainder of the URI is delegated to that authority (which may, in > > turn, delegate it further). > > > > I suspect this is the source of your discomfort. > > Yep. > > > But that use of the hierarchical element is not the only > > use, as further reading in the description of "host" would make clear. > > I'm not picking up on anything there. Care to point to it? Interpreting > this particular document has never been easy. > > The presence of a host subcomponent within a URI does not imply that the scheme requires access to the given host on the Internet. In many cases, the host syntax is used only for the sake of reusing the existing registration process created and deployed for DNS, thus obtaining a globally unique name without the cost of deploying another registry. However, such use comes with its own costs: domain name ownership may change over time for reasons not anticipated by the URI producer. This implies to me that there are times when the scheme require access to a given host for the relevant protocol operations. > > There are cases where it is intended to be the host you connect to and > > not the controller of a subsidiary namespace. > > Skype doesn't appear to use the authority form, so that isn't relevant > here. But delegating to E.164 as part of a scheme is entirely reasonable. > (In this regard, I'm curious as to why tel: is not tel://; the syntax would > seem to fit reg-name.) The XMPP usage is a stronger example, so I guess > it's good for my argument that it's now a defunct protocol. I prefer beer to bait, thanks. best, Ted telnet:// clearly indicates a resource with a clear authority, even if it > can't be authenticated. (The same might be said for ssh:// if the 2006 > secsh draft is representative; and for vnc://, both of which fit your model > here.) > > > > It would have been clearer for me if dns://example.com/ was tied to > the QNAME and the authority were the authoritative server for the name. > > > > > As noted above, that would not have met some of the use cases desired. > > I personally see negative utility in those use cases, but I appreciate > that others have those use cases. > > > I think it would be fairer to say that its use case and the one you are > > concerned with overlap but are not congruent. > > This is a fine conclusion :) > > > But it not only does not imply that > > the resolver confers authority, it does not even imply which resolution > > method you are using to get at the data. > > That is clearly true for the definition of the scheme. I still believe > that it is a bad idea to define a scheme that way. > --000000000000dae56505ac908e3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 10, 2020 at 6:34 PM Martin Th= omson <mt@lowentropy.net> wr= ote:
On Tue, Aug 11, 2020, at 04:25, Ted Hardie wrote:
> RFC 3986 says this in it discussion of the authority component:
>
>=C2=A0 =C2=A0 Many URI schemes include a hierarchical element for a nam= ing
>=C2=A0 =C2=A0 authority so that governance of the name space defined by= the
>=C2=A0 =C2=A0 remainder of the URI is delegated to that authority (whic= h may, in
>=C2=A0 =C2=A0 turn, delegate it further).
>
> I suspect this is the source of your discomfort.=C2=A0

Yep.

> But that use of the hierarchical element is not the only
> use, as further reading in the description of "host" would m= ake clear.=C2=A0

I'm not picking up on anything there.=C2=A0 Care to point to it?=C2=A0 = Interpreting this particular document has never been easy.


   The pr=
esence of a host subcomponent within a URI does
   not imply that the scheme requires access to the given host on the
   Internet.  In many cases, the host syntax is used only for the sake
   of reusing the existing registration process created and deployed for
   DNS, thus obtaining a globally unique name without the cost of
   deploying another registry.  However, such use comes with its own
   costs: domain name ownership may change over time for reasons not
   anticipated by the URI producer.
This implies to me that= there are times when the scheme require access to a given host for the rel= evant protocol operations.
=C2=A0
> There are cases where it is intended to be the host you connect to and=
> not the controller of a subsidiary namespace.

Skype doesn't appear to use the authority form, so that isn't relev= ant here.=C2=A0 But delegating to E.164 as part of a scheme is entirely rea= sonable.=C2=A0 (In this regard, I'm curious as to why tel: is not tel:/= /; the syntax would seem to fit reg-name.)=C2=A0 The XMPP usage is a strong= er example, so I guess it's good for my argument that it's now a de= funct protocol.=C2=A0


I pre= fer beer to bait, thanks.

best,

Ted


telnet:// clearly indicates a resource with a clear au= thority, even if it can't be authenticated.=C2=A0 (The same might be sa= id for ssh:// if the 2006 secsh draft is representative; and for vnc://, bo= th of which fit your model here.)

> > It would have been clearer for me if dns://example.com/ was tied to= the QNAME and the authority were the authoritative server for the name.=C2= =A0
> >
> As noted above, that would not have met some of the use cases desired.=

I personally see negative utility in those use cases, but I appreciate that= others have those use cases.

> I think it would be fairer to say that its use case and the one you ar= e
> concerned with overlap but are not congruent.=C2=A0

This is a fine conclusion :)

> But it not only does not imply that
> the resolver confers authority, it does not even imply which resolutio= n
> method you are using to get at the data.=C2=A0

That is clearly true for the definition of the scheme.=C2=A0 I still believ= e that it is a bad idea to define a scheme that way.
--000000000000dae56505ac908e3d-- From nobody Mon Aug 10 23:13:29 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 8E3A13A0CBB for ; Mon, 10 Aug 2020 23:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 2-68zrY8esc8 for ; Mon, 10 Aug 2020 23:13:26 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 37C533A0CBA for ; Mon, 10 Aug 2020 23:13:26 -0700 (PDT) Received: from xse212.mail2web.com ([66.113.196.212] helo=xse.mail2web.com) by mx13.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1k5MCV-0003f9-8z for add@ietf.org; Tue, 11 Aug 2020 06:50:15 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4BQgLH2MTBz1xXT for ; Mon, 10 Aug 2020 21:47:35 -0700 (PDT) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1k5MCF-00007c-7B for add@ietf.org; Mon, 10 Aug 2020 21:47:35 -0700 Received: (qmail 7788 invoked from network); 11 Aug 2020 04:47:34 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.61]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Aug 2020 04:47:34 -0000 To: Ted Hardie , Martin Thomson Cc: ADD Mailing list References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> <12aa68dc-3d37-45a5-ab78-87ddf65eb20b@www.fastmail.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <8f008a6f-2f8c-02de-f662-d832763e77eb@huitema.net> Date: Mon, 10 Aug 2020 21:47:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AB0DBEB50E74352523AC2D36" Content-Language: en-US X-Originating-IP: 66.113.196.212 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.212/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.212/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0X2OOYwfFINEXkW0Te3GMuqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDNzOpszOkW3faMySFwG163+fH zJ6mVE7ewsipSVIfs4ajCtHeu6vMDHvIzpwkoASdgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+drtT1wK6ppwERo35un0Ie1mdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdLn4jABaJqtNDIuGYj2WGeveXgFMyx0sD4hRS2uyMFprER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnFWB11dhDcan IFpyAO2lFVu7nh8N8M+WXoHXpIPrYDFDGc0XzGuvl78+eFS+idlBiSSiu9HJCv8jGw92eqwMcytU PVcmx1QL+XiKf76y/BgK1s8EDyWEQczdIkMoGoTHA/KY2AXNZGS5G93aGyH8MqMlOQRMVMd0HCeT skOZ5TL8RKMOaHU1TptyC0YaJYnAgTXg724gFzhHYUe+7aKm0vUjWp8TZ3jel57Ck6sNdOw3Ti+J 2sBvM/O0p+zizleC4va6FPcpDHjXMKZJK8+chiaetNomKj8I3vp0VX3mspNB7cTs80/2FnZg/IMs IAdedSzLrjsyfTPCYbMCLdmf5h2vfxw3Qvb2Glio5Cia/9Kfg4kJ0WtAYbrpe3OOAtQNb87OBHCz Hbokiue7PjVB1S6AQRz4SqXhOP5fdiQt7lu5Jm5nk4BSgYHOJJgUtm67rBRli6kULE5BQDZnPvvF VsQ= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Add] DNS URI scheme (was SVCB for DNS) 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 Aug 2020 06:13:28 -0000 This is a multi-part message in MIME format. --------------AB0DBEB50E74352523AC2D36 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/10/2020 7:08 PM, Ted Hardie wrote: > The presence of a host subcomponent within a URI does > not imply that the scheme requires access to the given host on the > Internet. In many cases, the host syntax is used only for the sake > of reusing the existing registration process created and deployed fo= r > DNS, thus obtaining a globally unique name without the cost of > deploying another registry. However, such use comes with its own > costs: domain name ownership may change over time for reasons not > anticipated by the URI producer. > This implies to me that there are times when the scheme require access > to a given host for the relevant protocol operations. Not really. Supposes the Zoo of Example starts a registry of wild beasts under net.zoo:, but then following some kind of name ownership dispute the "zoo.net" domain gets transferred to the Zoo of Another Example. Under the previous regimen, Zoo of Example had the authority to decide whether "shipworm" could be registered in this zoo registry. Post transfer, the Zoo of Another Example acquires that authority. It could also change pre-existing registrations, and decide that "bigfoot" does not belong there anymore. -- Christian Huitema --------------AB0DBEB50E74352523AC2D36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/10/2020 7:08 PM, Ted Hardie wrote:

   The presence of a host subcomponent within a URI does
   not imply that the scheme requires access to the given host on the
   Internet.  In many cases, the host syntax is used only for the sake
   of reusing the existing registration process created and deployed for
   DNS, thus obtaining a globally unique name without the cost of
   deploying another registry.  However, such use comes with its own
   costs: domain name ownership may change over time for reasons not
   anticipated by the URI producer.
This implies to me that there are times when the scheme require access to a given host for the relevant protocol operations.


Not really. Supposes the Zoo of Example starts a registry of wild beasts under net.zoo:, but then following some kind of name ownership dispute the "zoo.net" domain gets transferred to the Zoo of Another Example. Under the previous regimen, Zoo of Example had the authority to decide whether "shipworm" could be registered in this zoo registry. Post transfer, the Zoo of Another Example acquires that authority. It could also change pre-existing registrations, and decide that "bigfoot" does not belong there anymore.

-- Christian Huitema

--------------AB0DBEB50E74352523AC2D36-- From nobody Tue Aug 11 09:49:23 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 B11273A07C0 for ; Tue, 11 Aug 2020 09:49:21 -0700 (PDT) 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 TOidXJLliUXU for ; Tue, 11 Aug 2020 09:49:19 -0700 (PDT) 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 B279E3A07C5 for ; Tue, 11 Aug 2020 09:49:19 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id 25so12869154oir.0 for ; Tue, 11 Aug 2020 09:49:19 -0700 (PDT) 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=uAuWCHzsfItErga7Qomww8VUJFXC2s13c/rytgYQkG4=; b=AsDYuFJRy9ZPmB6NBzgc7o1/+HlcWpXkrpqN5Fi3TElRUVkGP4YLIR5duyZ2eCmJQ1 02dFACmORKySNbT0QUIDZvW0kRiSYKUfvgkHYD3ZbvFQZvKPs0faqC/3zpLM4DpGto1+ 35bJJGmqau769JIR9VEudUxRziiHFWO77U74mJ3Ivw7k/dGki/8LiVQTl6yDmvs4QdaP dHuUyPqVSzlZGvC5X0pm49+J3pNCTbWWabP9gcpxGMPLOh831vEs3GELw+c9/D+U0uZS pAwmf+jYzxeyCUoECAAFm1NJYfR/P1dghH7O+HsUyjpFEdxfnvhZQnvkDl0nxOVX3+V/ a0VA== 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=uAuWCHzsfItErga7Qomww8VUJFXC2s13c/rytgYQkG4=; b=j9kPNgprU6ZNf4vDTGcpGYhRoFjT4zonyXP4kaHQ+tzFfTCumBGHDb/Q3OzI6H5oEs nnBkb9fWxBJyB5DNqqa6C1M3okgxt0eyMCQNtjMlcEDj6usWlR9Le8q4cJUc+aEJa0ps FZ9Faeq+ZeQ6VjKboNSy1hkINg6xtQJl/Dy6LdjG05V0dtpx45sEU2O5DvGA/Qh4Q738 iwxdiXAGSWD96eo16IEJF5UZAUNfMabEhQJ/vNjj8TLWkezWyf6Wz9d3wAA/nGk46Epv po61OinKd5ZbYtkYue8slgY8K5/cAJVXOj4S57ifuAkF63qag9gr/D72wB/6pppLla9n dGzw== X-Gm-Message-State: AOAM5335JIu8ePdbLLbFtxfFqjWoN+peahk3z+7c29H/wFzFgGGx1BJE 3FSt7OhdjQjalA+SR+PUmT65VfCRAQ/DfUO+ZnBFRjaQGzg= X-Google-Smtp-Source: ABdhPJwb9KoSnAU2tgwuw+gLxfaHEQEt5cGPYKu+dR9Gn9Gb1pavulSsXvGBshDjArFQxp7wY8+wnWJO2r4gL5USyQs= X-Received: by 2002:aca:4e0c:: with SMTP id c12mr4110854oib.74.1597164559000; Tue, 11 Aug 2020 09:49:19 -0700 (PDT) MIME-Version: 1.0 References: <159656272783.7072.6229544475907348131@ietfa.amsl.com> <12aa68dc-3d37-45a5-ab78-87ddf65eb20b@www.fastmail.com> <8f008a6f-2f8c-02de-f662-d832763e77eb@huitema.net> In-Reply-To: <8f008a6f-2f8c-02de-f662-d832763e77eb@huitema.net> From: Ted Hardie Date: Tue, 11 Aug 2020 09:48:52 -0700 Message-ID: To: Christian Huitema Cc: Martin Thomson , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000002fe92e05ac9cdaea" Archived-At: Subject: Re: [Add] DNS URI scheme (was SVCB for DNS) 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 Aug 2020 16:49:22 -0000 --0000000000002fe92e05ac9cdaea Content-Type: text/plain; charset="UTF-8" Howdy, On Mon, Aug 10, 2020 at 11:12 PM Christian Huitema wrote: > On 8/10/2020 7:08 PM, Ted Hardie wrote: > > The presence of a host subcomponent within a URI does > not imply that the scheme requires access to the given host on the > Internet. In many cases, the host syntax is used only for the sake > of reusing the existing registration process created and deployed for > DNS, thus obtaining a globally unique name without the cost of > deploying another registry. However, such use comes with its own > costs: domain name ownership may change over time for reasons not > anticipated by the URI producer. > > This implies to me that there are times when the scheme require access to > a given host for the relevant protocol operations. > > > Not really. Supposes the Zoo of Example starts a registry of wild beasts > under net.zoo:, but then following some kind of name ownership dispute the " > zoo.net" domain gets transferred to the Zoo of Another Example. Under the > previous regimen, Zoo of Example had the authority to decide whether > "shipworm" could be registered in this zoo registry. Post transfer, the Zoo > of Another Example acquires that authority. It could also change > pre-existing registrations, and decide that "bigfoot" does not belong there > anymore. > > > I think perhaps I wasn't clear, so maybe a slightly different take will help. If you go back to RFC 1738 and look at some of the earliest registered schemes, there are a number where the clear intent of the authority is to name a specific network host at which an operation will take place (ftp and gopher, for example). There's also an interesting split in news and nntp (sections 3.6 and 3.7), where news provides you a reference to a newsgroup or message article that is location independent and nntp provides a location-specific reference. This distinction is called out in RFC 1738. The DNS scheme provides the ability to make a reference that is location independent (and resolution independent). It also provides the ability to turn that reference into a location specific reference. The first form has no authority; the second form does. The second form doesn't reflect a different authority. Just like news and nntp share newsgroup names and message ids, the two forms both refer to the data stored in the DNS. One simply provides a location specific version of the same reference. regards, Ted --0000000000002fe92e05ac9cdaea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Mon, Aug 10, 2020 at 11:12 PM Christian = Huitema <huitema@huitema.net&= gt; wrote:
=20 =20 =20

On 8/10/2020 7:08 PM, Ted Hardie wrote:

   The presence of a host subcomponent within a URI does
   not imply that the scheme requires access to the given host on the
   Internet.  In many cases, the host syntax is used only for the sake
   of reusing the existing registration process created and deployed for
   DNS, thus obtaining a globally unique name without the cost of
   deploying another registry.  However, such use comes with its own
   costs: domain name ownership may change over time for reasons not
   anticipated by the URI producer.
This implies to me that there are times when the scheme require access to a given host for the relevant protocol operations.


Not really. Supposes the Zoo of Example starts a registry of wild beasts under net.zoo:, but then following some kind of name ownership dispute the "zoo.net" domain gets transferred to the Zoo of Another Example. Under the previous regimen, Zoo of Example had the authority to decide whether "shipworm" could be registe= red in this zoo registry. Post transfer, the Zoo of Another Example acquires that authority. It could also change pre-existing registrations, and decide that "bigfoot" does not belong th= ere anymore.


I think perhaps I wasn't clear, = so maybe a slightly different take will help.=C2=A0 If you go back to RFC 1= 738 and look at some of the earliest registered schemes, there are a number= where the clear intent of the authority is to name a specific network host= at which an operation will take place (ftp and gopher, for example).=C2=A0= There's also an interesting split in news and nntp (sections 3.6 and 3= .7), where news provides you a reference to a newsgroup or message article = that is location independent and nntp provides a location-specific referenc= e.=C2=A0 This distinction is called out in RFC 1738.

The DNS scheme provides the ability to make a reference that is location= independent (and resolution independent).=C2=A0 It also provides the abili= ty to turn that reference into a location specific reference.=C2=A0 The fir= st form has no authority; the second form does. The second form doesn't= reflect a different authority.=C2=A0 Just like news and nntp share newsgro= up names and message ids, the two forms both refer to the data stored in th= e DNS.=C2=A0 One simply provides a location specific version of the same re= ference.
regards,

Ted
--0000000000002fe92e05ac9cdaea-- From nobody Fri Aug 14 10:12:09 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 09DDC3A0E57 for ; Fri, 14 Aug 2020 10:12:05 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 VBZivVYjrU3m for ; Fri, 14 Aug 2020 10:12:03 -0700 (PDT) Received: from sjmda10.webex.com (sjmda10.webex.com [64.68.124.127]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68493A0E5B for ; Fri, 14 Aug 2020 10:12:02 -0700 (PDT) Received: from rva2rmd102.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda10.webex.com (Postfix) with ESMTP id 91C8B300AB2B for ; Fri, 14 Aug 2020 17:12:02 +0000 (GMT) Received: from rva2rmd102.webex.com (localhost [127.0.0.1]) by rva2rmd102.webex.com (Postfix) with ESMTP id 31B86103C532 for ; Fri, 14 Aug 2020 17:12:02 +0000 (GMT) Date: Fri, 14 Aug 2020 17:12:02 +0000 (GMT) From: ADD Working Group Reply-To: add-chairs@ietf.org To: add@ietf.org Message-ID: <1599284582.4535551597425122201.JavaMail.nobody@rva2rmd102.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_907105_1605724786.1597425122200" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=169571809473081090, X-WBX-TID=4vz19b55hxahpaj2ad7aotetdbr29olihta8bnljpqh1w7ty1y08b7lk, X-WBX-RID=bccd5e03e8754eb6b53d4409a535d619, X-WBX-SVC:Meeting Center, X-WBX-TT:Meeting Invitation, Date:Fri Aug 14 17:12:02 GMT 2020 reminder-40.8.0-3226 Archived-At: Subject: [Add] Webex meeting invitation: Session 1: IETF ADD Sept Interim 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: Fri, 14 Aug 2020 17:12:05 -0000 ------=_Part_907105_1605724786.1597425122200 Content-Type: multipart/Alternative; boundary="----=_Part_907106_1468901867.1597425122200" ------=_Part_907106_1468901867.1597425122200 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBhZGRAaWV0Zi5vcmcsCgpBREQgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2lu IHRoaXMgV2ViZXggbWVldGluZy4KCgpTZXNzaW9uIDE6IElFVEYgQUREIFNlcHQgSW50ZXJpbQpU dWVzZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMjAKMTowMCBwbSAgfCAgKFVUQyswMDowMCkgQXpvcmVz ICB8ICAyIGhycyAzMCBtaW5zCk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDE3MSAyODkg ODg1MSAKTWVldGluZyBwYXNzd29yZDogMkpBcG11WnM4UjgKCgoKV2hlbiBpdCdzIHRpbWUsIGpv aW4gdGhlIG1lZXRpbmcuCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0w MWMyOWE5Zjk3N2JiOTY3MmEzMTUzYzlkODUxZTJjMwoKQWRkIHRvIENhbGVuZGFyCmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1lNTZlOTM0ZmRlYTdiN2EwNTRiMzFhMDc1 ZTdmOWQxOQ0KDQoKCg0KVEFQIFRPIEpPSU4gRlJPTSBBIE1PQklMRSBERVZJQ0UgKEFUVEVOREVF UyBPTkxZKQ0KKzEtNjUwLTQ3OS0zMjA4LCwxNzEyODk4ODUxIyMgdGVsOiUyQjEtNjUwLTQ3OS0z MjA4LCwqMDEqMTcxMjg5ODg1MSUyMyUyMyowMSogQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2Fu YWRhKQoNCg0KSk9JTiBCWSBQSE9ORQ0KMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKQoNCkdsb2JhbCBjYWxsLWluIG51bWJlcnMNCmh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01USUQ9bTc4ODgwYjUyZTY0MzVjMmYxMDNlYTlj ZWExYTY2ZTQzDQoNCgpKT0lOIEZST00gQSBWSURFTyBTWVNURU0gT1IgQVBQTElDQVRJT04KRGlh bCBzaXA6MTcxMjg5ODg1MUBpZXRmLndlYmV4LmNvbQpZb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQz LjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuCgoKSm9pbiB1c2luZyBNaWNyb3Nv ZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzCkRpYWwgc2lwOjE3MTI4OTg4 NTEuaWV0ZkBseW5jLndlYmV4LmNvbQoKCgoKCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/Cmh0dHBz Oi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1CgoKSU1Q T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dz IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz aW9uLgo= ------=_Part_907106_1468901867.1597425122200 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KdGFibGUgewoJYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0 ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7fQoKdHIgewoJbGlu ZS1oZWlnaHQ6IDE4cHg7fQoKYSwgdGQgewoJZm9udC1zaXplOiAxNHB4Owlmb250LWZhbWlseTog QXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5v cm1hbDsJcGFkZGluZzogMDt9CgoudGl0bGUgewoJZm9udC1zaXplOiAyOHB4O30KCi5pbWFnZSB7 Cgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO30KCi5mb290ZXIgewoJd2lkdGg6IDYwNHB4 O30KCi5tYWluIHsKCn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgp IHsKCS50aXRsZSB7CgkJZm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX0KCS5pbWFnZSB7CgkJ d2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9Cgku Zm9vdGVyIHsKCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1w b3J0YW50Cgl9CgkubWFpbiB7CgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDog NjA0cHggIWltcG9ydGFudAoJfQp9Cjwvc3R5bGU+Cgo8dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIg c3R5bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFs aWduPSJsZWZ0Ij4KCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3Ry PgoJPHRyPgoJCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2lu OiAwIj4KCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7 IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBh bGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPgoJCQkJPHRyPgoJCQkJCTx0ZCBhbGlnbj0iY2VudGVy IiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD4KCQkJCTwvdHI+CgkJCTwvdGFibGU+LS0+ CgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgIDx0ZCBzdHlsZT0iaGVpZ2h0OiAyMnB4 O2NvbG9yOiAjMDAwMDAwO2ZvbnQtZmFtaWx5OiBBcmlhbDsJZm9udC1zaXplOiAxNnB4O2ZvbnQt d2VpZ2h0OiBib2xkO2xpbmUtaGVpZ2h0OiAyMnB4OyI+CiAgICAgICAgICAgICAgICBBREQgV29y a2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViZXggbWVldGluZy4KICAgICAg ICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoKPHRhYmxl Pjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCiAgICA8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdp ZHRoOmF1dG8haW1wb3J0YW50OyI+CiAgICAgICAgPHRyPgogICAgICAgICAgICA8dGQgc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtc2l6ZTogMTZweDsgbGlu ZS1oZWlnaHQ6IDIycHg7Ij4KICAgICAgICAgICAgICAgIE1lZXRpbmcgbnVtYmVyIChhY2Nlc3Mg Y29kZSk6IDE3MSAyODkgODg1MQogICAgICAgICAgICA8L3RkPgogICAgICAgIDwvdHI+CiAgICA8 L3RhYmxlPgogICAgPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFu dCI+CiAgICAgICAgPHRyID4KICAgICAgICAgICAgPHRkIHN0eWxlPSJmb250LWZhbWlseTogQXJp YWw7IGNvbG9yOiAjMDAwMDAwOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiAyMnB4OyI+ TWVldGluZyBwYXNzd29yZDogMkpBcG11WnM4Ujg8L3RkPgogICAgICAgIDwvdHI+CiAgICA8L3Rh YmxlPgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoKICAgIDx0YWJsZSAgd2lkdGg9IjEw MCUiPgogICAgICAgIDx0ciBzdHlsZT0ibWFyZ2luOjBweDtjb2xvcjogIzY2NjY2Njtmb250LWZh bWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyMnB4OyI+CiAgICAgICAg ICAgIDx0ZCBzdHlsZT0ibWFyZ2luOjBweDtjb2xvcjogIzY2NjY2Njtmb250LWZhbWlseTogQXJp YWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyMnB4OyI+VHVlc2RheSwgU2VwdGVtYmVy IDE1LCAyMDIwCiAgICAgICAgICAgIDwvdGQ+CiAgICAgICAgPC90cj4KICAgICAgICA8dHIgc3R5 bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsiPgogICAgICAgICAgICA8dGQgc3R5bGU9Im1hcmdp bjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDts aW5lLWhlaWdodDogMjJweDsiPjE6MDAgcG0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7KFVUQysw MDowMCkgQXpvcmVzJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzIgaHJzIDMwIG1pbnMKICAgICAg ICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KCiA8Rk9OVCBzaXplPSIyIiBD T0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD4KCiAgICAK CgkJCTx0YWJsZSBzdHlsZT0icGFkZGluZy1ib3R0b206IDRweDtmb250LWZhbWlseTogQXJpYWw7 Ij48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlIHN0eWxlPSd3aWR0aDphdXRvO3dpZHRo OmF1dG8haW1wb3J0YW50Oyc+PHRyPjx0ZCBzdHlsZT0nd2lkdGg6YXV0byFpbXBvcnRhbnQ7ICc+ PHRhYmxlIGJvcmRlcj0nMCcgY2VsbHBhZGRpbmc9JzAnIGNlbGxzcGFjaW5nPScwJyBzdHlsZT0n d2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjojNDNBOTQy OyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjBweDsgbWluLXdpZHRo OjE2MHB4IWltcG9ydGFudDsnPjx0Ym9keT48dHI+PHRkIGFsaWduPSdjZW50ZXInIHN0eWxlPSdw YWRkaW5nOjEwcHggMzZweDtmb250LWZhbWlseTogQXJpYWw7Jz48YSBocmVmPSdodHRwczovL2ll dGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMDFjMjlhOWY5NzdiYjk2NzJhMzE1M2M5ZDg1 MWUyYzMnIHN0eWxlPSdjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0 aW9uOm5vbmU7Jz5Kb2luIG1lZXRpbmc8L2E+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L3Rk PjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDQ4cHgiPjx0 ZCBzdHlsZT0iaGVpZ2h0OjQ4cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoKCgk8dGFibGU+ PHRyPjx0ZCBzdHlsZT0iY29sb3I6ICMwMDAwMDA7Zm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNp emU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPlRhcCB0 byBqb2luIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSk8L2I+PC90ZD48L3Ry Pjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Zm9u dC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4OyI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3 OS0zMjA4LCwqMDEqMTcxMjg5ODg1MSUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAg dGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7 bGluZS1oZWlnaHQ6IDI0cHg7Jz4rMS02NTAtNDc5LTMyMDgsLDE3MTI4OTg4NTEjIzwvYT4gQ2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9ImxpbmUtaGVp Z2h0OiAyNHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyNHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJs ZT48dGFibGU+PHRib2R5Pjx0cj48dGQgc3R5bGU9ImNvbG9yOiAjMDAwMDAwO2ZvbnQtZmFtaWx5 OiBBcmlhbDsgZm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6 IDI0cHg7Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjow cHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsiPjEtNjUwLTQ3OS0zMjA4Jm5ic3A7PHNwYW4gc3R5 bGU9ImNvbG9yOiAjMzMzMzMzOyI+Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvc3Bh bj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Ij48YSBocmVmPSJodHRw czovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW03ODg4MGI1MmU2 NDM1YzJmMTAzZWE5Y2VhMWE2NmU0MyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQt c2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkdsb2JhbCBjYWxsLWluIG51bWJlcnM8L2E+PC90ZD48 L3RyPjwvdGJvZHk+PC90YWJsZT48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIw Ij48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjhweCI+ Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+Cgk8dGFibGU+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAj MDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDog Ym9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0gb3Ig YXBwbGljYXRpb248L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxl PSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxp bmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjE3MTI4OTg4NTFAaWV0Zi53ZWJl eC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjE3MTI4 OTg4NTFAaWV0Zi53ZWJleC5jb208L2E+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+ PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6 IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4 IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48 dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5i c3A7PC90ZD48L3RyPjwvdGFibGU+CiAgICA8dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIwIj48dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlh bDtmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsi PjxiPkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNp bmVzczwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9y OiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWln aHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9IiBzaXA6MTcxMjg5ODg1MS5pZXRmQGx5bmMud2ViZXgu Y29tIiAgIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij4xNzEyODk4 ODUxLmlldGZAbHluYy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+CgoJPHRhYmxlPjx0 ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNw OzwvdGQ+PC90cj48L3RhYmxlPgoJCgoJCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxp Z249ImxlZnQiIGNsYXNzPSJtYWluIj4KICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0 OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPgoJCQkJPHRyPgoJCQkJCTx0ZCBzdHlsZT0iaGVp Z2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTog MTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6 Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpu b25lOyI+aHR0cDovL2hlbHAud2ViZXguY29tPC9hPgoJCQkJCTwvdGQ+CgkJCQk8L3RyPgogICAg ICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+ CgkJCTwvdGFibGU+CgkJPC90ZD4KCTwvdHI+CjwvdGFibGU+Cg== ------=_Part_907106_1468901867.1597425122200 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL0F6b3Jlcw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25l aW5mby1vdXRsb29rL0F0bGFudGljL0F6b3Jlcw0KWC1MSUMtTE9DQVRJT046QXRsYW50aWMvQXpv cmVzDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wMTAwDQpUWk9GRlNFVFRPOiswMDAw DQpUWk5BTUU6KzAwDQpEVFNUQVJUOjE5NzAwMzI5VDAwMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7 QllNT05USD0zO0JZREFZPS0xU1UNCkVORDpEQVlMSUdIVA0KQkVHSU46U1RBTkRBUkQNClRaT0ZG U0VURlJPTTorMDAwMA0KVFpPRkZTRVRUTzotMDEwMA0KVFpOQU1FOi0wMQ0KRFRTVEFSVDoxOTcw MTAyNVQwMTAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9OVEg9MTA7QllEQVk9LTFTVQ0KRU5E OlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDA4MTRU MTcxMjAyWg0KQVRURU5ERUU7Q049ImFkZEBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzphZGRAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQUREIFdvcmtpbmcg R3JvdXAiOk1BSUxUTzphZGQtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QXRsYW50aWMv QXpvcmVzOjIwMjAwOTE1VDEzMDAwMA0KRFRFTkQ7VFpJRD1BdGxhbnRpYy9Bem9yZXM6MjAyMDA5 MTVUMTUzMDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tMDFjMjlhOWY5NzdiYjk2NzJhMzE1M2M5ZDg1MWUyYzMNClRSQU5TUDpPUEFRVUUNClNFUVVF TkNFOjE1OTc0MjUxMjINClVJRDo0OTk5NzM3ZS05Y2NmLTQ5Y2MtODlmMC0zNjk4ZGQyMjQ5ZTEN CkRFU0NSSVBUSU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tMDFjMjlhOWY5NzdiYjk2NzJhMzE1M2M5ZDg1MWUyYzNc bk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDE3MSAyODkgODg1MVxuXG5NZWV0aW5nIHBh c3N3b3JkOiAySkFwbXVaczhSOFxuXG5cblxuVEFQIFRPIEpPSU4gRlJPTSBBIE1PQklMRSBERVZJ Q0UgKEFUVEVOREVFUyBPTkxZKVxuKzEtNjUwLTQ3OS0zMjA4LCwxNzEyODk4ODUxIyMgdGVsOiUy QjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcxMjg5ODg1MSUyMyUyMyowMSogQ2FsbC1pbiB0b2xsIG51 bWJlciAoVVMvQ2FuYWRhKVxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwt aW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuR2xvYmFsIGNhbGwtaW4gbnVtYmVyc1xuaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tNzg4ODBiNTJl NjQzNWMyZjEwM2VhOWNlYTFhNjZlNDNcblxuXG5KT0lOIEZST00gQSBWSURFTyBTWVNURU0gT1Ig QVBQTElDQVRJT05cbkRpYWwgc2lwOjE3MTI4OTg4NTFAaWV0Zi53ZWJleC5jb21cbllvdSBjYW4g YWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci5cblxu XG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5l c3NcbkRpYWwgc2lwOjE3MTI4OTg4NTEuaWV0ZkBseW5jLndlYmV4LmNvbVxuXG5cblxuXG5cbkNh bid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNv bS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3Rl IHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRp b24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBk aXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5 b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5v dCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0 aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVTQztGTVRUWVBF PXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxudGFibGUge1xuCWJvcmRlci1jb2xs YXBzZTogc2VwYXJhdGU7IHdpZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAw O31cblxudHIge1xuCWxpbmUtaGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTog MTRweDsJZm9udC1mYW1pbHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13 b3JkOwl3b3JkLWJyZWFrOiBub3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQt c2l6ZTogMjhweDt9XG5cbi5pbWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9 XG5cbi5mb290ZXIge1xuCXdpZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3Jl ZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6 ZTogMjJweCAhaW1wb3J0YW50Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFu dDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAx MDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4g e1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50 XG4JfVxufVxuPC9zdHlsZT5cblxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRk aW5nOiAwOyBtYXJnaW46IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+ XG4JPHRyIHN0eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxu CQk8dGQgYWxpZ249ImxlZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4J CQk8IS0tPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6 IDEwMCU7IHBhZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJs ZWZ0IiBjbGFzcz0ibWFpbiI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFs aWduPSJ0b3AiID4mbmJzcDsJCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5c blxuXG5cblxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0la RT0iNCIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGltZSwgam9pbiB0 aGUgV2ViZXggbWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJ CTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29k ZSk6IDE3MSAyODkgODg1MTwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJs ZT5cbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MkpBcG11WnM4Ujg8L0ZPTlQ+PC90ZD48L3Ry PjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJ CTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3aWR0 aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0MjsgYm9y ZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDoxNjBw eCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgc3R5 bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bTAxYzI5YTlmOTc3YmI5NjcyYTMxNTNjOWQ4NTFlMmMzIiBzdHlsZT0i Y29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Sm9p biBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwvdGQ+ XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAi IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBGQUNF PSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZPTlQg U0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+VGFwIHRvIGpvaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5 KTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE3MTI4OTg4NTElMjMl MjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250 LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+KzEtNjUw LTQ3OS0zMjA4LCwxNzEyODk4ODUxIyM8L2E+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSk8L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9O VD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZu YnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW03 ODg4MGI1MmU2NDM1YzJmMTAzZWE5Y2VhMWE2NmU0MyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpu b25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkdsb2JhbCBjYWxsLWluIG51bWJlcnM8 L2E+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1o ZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90 YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxp Y2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDoxNzEyODk4ODUxQGlldGYud2ViZXguY29tIj48 Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjE3MTI4OTg4NTFAaWV0 Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVu dGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05UPiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsg PEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBz dHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7 IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWlj cm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZh bWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxh IGhyZWY9IiBzaXA6MTcxMjg5ODg1MS5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij4xNzEyODk4ODUxLmlldGZAbHluYy53ZWJl eC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFi bGU+XG4JXG5cbgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xh c3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+ Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7 IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2Vi ZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRw Oi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAg ICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwv dGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFibGU+XG4NClNVTU1BUlk6U2Vzc2lvbiAxOiBJ RVRGIEFERCBTZXB0IEludGVyaW0NClBSSU9SSVRZOjUNCkNMQVNTOlBVQkxJQw0KQkVHSU46VkFM QVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJT046UmVtaW5kZXIN CkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== ------=_Part_907106_1468901867.1597425122200-- ------=_Part_907105_1605724786.1597425122200 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL0F6b3Jlcw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25l aW5mby1vdXRsb29rL0F0bGFudGljL0F6b3Jlcw0KWC1MSUMtTE9DQVRJT046QXRsYW50aWMvQXpv cmVzDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wMTAwDQpUWk9GRlNFVFRPOiswMDAw DQpUWk5BTUU6KzAwDQpEVFNUQVJUOjE5NzAwMzI5VDAwMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7 QllNT05USD0zO0JZREFZPS0xU1UNCkVORDpEQVlMSUdIVA0KQkVHSU46U1RBTkRBUkQNClRaT0ZG U0VURlJPTTorMDAwMA0KVFpPRkZTRVRUTzotMDEwMA0KVFpOQU1FOi0wMQ0KRFRTVEFSVDoxOTcw MTAyNVQwMTAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9OVEg9MTA7QllEQVk9LTFTVQ0KRU5E OlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDA4MTRU MTcxMjAyWg0KQVRURU5ERUU7Q049ImFkZEBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzphZGRAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQUREIFdvcmtpbmcg R3JvdXAiOk1BSUxUTzphZGQtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QXRsYW50aWMv QXpvcmVzOjIwMjAwOTE1VDEzMDAwMA0KRFRFTkQ7VFpJRD1BdGxhbnRpYy9Bem9yZXM6MjAyMDA5 MTVUMTUzMDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tMDFjMjlhOWY5NzdiYjk2NzJhMzE1M2M5ZDg1MWUyYzMNClRSQU5TUDpPUEFRVUUNClNFUVVF TkNFOjE1OTc0MjUxMjINClVJRDo0OTk5NzM3ZS05Y2NmLTQ5Y2MtODlmMC0zNjk4ZGQyMjQ5ZTEN CkRFU0NSSVBUSU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tMDFjMjlhOWY5NzdiYjk2NzJhMzE1M2M5ZDg1MWUyYzNc bk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDE3MSAyODkgODg1MVxuXG5NZWV0aW5nIHBh c3N3b3JkOiAySkFwbXVaczhSOFxuXG5cblxuVEFQIFRPIEpPSU4gRlJPTSBBIE1PQklMRSBERVZJ Q0UgKEFUVEVOREVFUyBPTkxZKVxuKzEtNjUwLTQ3OS0zMjA4LCwxNzEyODk4ODUxIyMgdGVsOiUy QjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcxMjg5ODg1MSUyMyUyMyowMSogQ2FsbC1pbiB0b2xsIG51 bWJlciAoVVMvQ2FuYWRhKVxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwt aW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuR2xvYmFsIGNhbGwtaW4gbnVtYmVyc1xuaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tNzg4ODBiNTJl NjQzNWMyZjEwM2VhOWNlYTFhNjZlNDNcblxuXG5KT0lOIEZST00gQSBWSURFTyBTWVNURU0gT1Ig QVBQTElDQVRJT05cbkRpYWwgc2lwOjE3MTI4OTg4NTFAaWV0Zi53ZWJleC5jb21cbllvdSBjYW4g YWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci5cblxu XG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5l c3NcbkRpYWwgc2lwOjE3MTI4OTg4NTEuaWV0ZkBseW5jLndlYmV4LmNvbVxuXG5cblxuXG5cbkNh bid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNv bS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3Rl IHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRp b24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBk aXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5 b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5v dCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0 aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVTQztGTVRUWVBF PXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxudGFibGUge1xuCWJvcmRlci1jb2xs YXBzZTogc2VwYXJhdGU7IHdpZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAw O31cblxudHIge1xuCWxpbmUtaGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTog MTRweDsJZm9udC1mYW1pbHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13 b3JkOwl3b3JkLWJyZWFrOiBub3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQt c2l6ZTogMjhweDt9XG5cbi5pbWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9 XG5cbi5mb290ZXIge1xuCXdpZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3Jl ZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6 ZTogMjJweCAhaW1wb3J0YW50Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFu dDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAx MDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4g e1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50 XG4JfVxufVxuPC9zdHlsZT5cblxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRk aW5nOiAwOyBtYXJnaW46IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+ XG4JPHRyIHN0eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxu CQk8dGQgYWxpZ249ImxlZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4J CQk8IS0tPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6 IDEwMCU7IHBhZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJs ZWZ0IiBjbGFzcz0ibWFpbiI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFs aWduPSJ0b3AiID4mbmJzcDsJCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5c blxuXG5cblxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0la RT0iNCIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGltZSwgam9pbiB0 aGUgV2ViZXggbWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJ CTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29k ZSk6IDE3MSAyODkgODg1MTwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJs ZT5cbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MkpBcG11WnM4Ujg8L0ZPTlQ+PC90ZD48L3Ry PjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJ CTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3aWR0 aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0MjsgYm9y ZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDoxNjBw eCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgc3R5 bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bTAxYzI5YTlmOTc3YmI5NjcyYTMxNTNjOWQ4NTFlMmMzIiBzdHlsZT0i Y29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Sm9p biBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwvdGQ+ XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAi IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBGQUNF PSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZPTlQg U0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+VGFwIHRvIGpvaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5 KTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE3MTI4OTg4NTElMjMl MjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250 LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+KzEtNjUw LTQ3OS0zMjA4LCwxNzEyODk4ODUxIyM8L2E+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSk8L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9O VD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZu YnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW03 ODg4MGI1MmU2NDM1YzJmMTAzZWE5Y2VhMWE2NmU0MyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpu b25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkdsb2JhbCBjYWxsLWluIG51bWJlcnM8 L2E+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1o ZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90 YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxp Y2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDoxNzEyODk4ODUxQGlldGYud2ViZXguY29tIj48 Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjE3MTI4OTg4NTFAaWV0 Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVu dGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05UPiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsg PEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBz dHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7 IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWlj cm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZh bWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxh IGhyZWY9IiBzaXA6MTcxMjg5ODg1MS5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij4xNzEyODk4ODUxLmlldGZAbHluYy53ZWJl eC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFi bGU+XG4JXG5cbgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xh c3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+ Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7 IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2Vi ZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRw Oi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAg ICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwv dGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFibGU+XG4NClNVTU1BUlk6U2Vzc2lvbiAxOiBJ RVRGIEFERCBTZXB0IEludGVyaW0NClBSSU9SSVRZOjUNCkNMQVNTOlBVQkxJQw0KQkVHSU46VkFM QVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJT046UmVtaW5kZXIN CkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== ------=_Part_907105_1605724786.1597425122200-- From nobody Fri Aug 14 10:13: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 BCFC23A0E5C for ; Fri, 14 Aug 2020 10:13:53 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 RLQ05fqFSTAG for ; Fri, 14 Aug 2020 10:13:51 -0700 (PDT) Received: from sjmda11.webex.com (sjmda11.webex.com [64.68.124.128]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1183A0E61 for ; Fri, 14 Aug 2020 10:13:51 -0700 (PDT) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda11.webex.com (Postfix) with ESMTP id B395A3021854 for ; Fri, 14 Aug 2020 17:13:51 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id 4BC60100CEBB for ; Fri, 14 Aug 2020 17:13:51 +0000 (GMT) Date: Fri, 14 Aug 2020 17:13:51 +0000 (GMT) From: ADD Working Group Reply-To: add-chairs@ietf.org To: add@ietf.org Message-ID: <178508431.8975971597425231308.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1795170_1326298668.1597425231308" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=169571809473081090, X-WBX-TID=4s4ev6eyn2iffupuhazijup5f5v3wfmy8bjej106sebms1h34kkowmd5, X-WBX-RID=902d01c952e648a98e08a5b004cb5ee0, X-WBX-SVC:Meeting Center, X-WBX-TT:Updated Meeting Invitation, Date:Fri Aug 14 17:13:51 GMT 2020 reminder-40.8.0-3226 Archived-At: Subject: [Add] Webex meeting changed: Session 1: IETF ADD Sept Interim 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: Fri, 14 Aug 2020 17:13:54 -0000 ------=_Part_1795170_1326298668.1597425231308 Content-Type: multipart/Alternative; boundary="----=_Part_1795171_781921190.1597425231308" ------=_Part_1795171_781921190.1597425231308 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBhZGRAaWV0Zi5vcmcsCgpBREQgV29ya2luZyBHcm91cCBjaGFuZ2VkIHRoZSBXZWJleCBt ZWV0aW5nIGluZm9ybWF0aW9uLgoKClNlc3Npb24gMTogSUVURiBBREQgU2VwdCBJbnRlcmltClRo dXJzZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMjAKMTowMCBwbSAgfCAgKFVUQyswMDowMCkgQXpvcmVz ICB8ICAyIGhycyAzMCBtaW5zCk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDE3MSAyODkg ODg1MSAKTWVldGluZyBwYXNzd29yZDogMkpBcG11WnM4UjgKCgoKV2hlbiBpdCdzIHRpbWUsIGpv aW4gdGhlIG1lZXRpbmcuCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0w MWMyOWE5Zjk3N2JiOTY3MmEzMTUzYzlkODUxZTJjMwoKQWRkIHRvIENhbGVuZGFyCmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xYzIyNTQ2MjYzZGRkZTBhZDRjZDFhOWNk Mzc0NzQ1NQ0KDQoKCg0KVEFQIFRPIEpPSU4gRlJPTSBBIE1PQklMRSBERVZJQ0UgKEFUVEVOREVF UyBPTkxZKQ0KKzEtNjUwLTQ3OS0zMjA4LCwxNzEyODk4ODUxIyMgdGVsOiUyQjEtNjUwLTQ3OS0z MjA4LCwqMDEqMTcxMjg5ODg1MSUyMyUyMyowMSogQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2Fu YWRhKQoNCg0KSk9JTiBCWSBQSE9ORQ0KMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKQoNCkdsb2JhbCBjYWxsLWluIG51bWJlcnMNCmh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01USUQ9bTc4ODgwYjUyZTY0MzVjMmYxMDNlYTlj ZWExYTY2ZTQzDQoNCgpKT0lOIEZST00gQSBWSURFTyBTWVNURU0gT1IgQVBQTElDQVRJT04KRGlh bCBzaXA6MTcxMjg5ODg1MUBpZXRmLndlYmV4LmNvbQpZb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQz LjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuCgoKSm9pbiB1c2luZyBNaWNyb3Nv ZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzCkRpYWwgc2lwOjE3MTI4OTg4 NTEuaWV0ZkBseW5jLndlYmV4LmNvbQoKCgoKCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/Cmh0dHBz Oi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1CgoKSU1Q T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dz IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz aW9uLgo= ------=_Part_1795171_781921190.1597425231308 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KdGFibGUgewoJYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0 ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7fQoKdHIgewoJbGlu ZS1oZWlnaHQ6IDE4cHg7fQoKYSwgdGQgewoJZm9udC1zaXplOiAxNHB4Owlmb250LWZhbWlseTog QXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5v cm1hbDsJcGFkZGluZzogMDt9CgoudGl0bGUgewoJZm9udC1zaXplOiAyOHB4O30KCi5pbWFnZSB7 Cgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO30KCi5mb290ZXIgewoJd2lkdGg6IDYwNHB4 O30KCi5tYWluIHsKCn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgp IHsKCS50aXRsZSB7CgkJZm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX0KCS5pbWFnZSB7CgkJ d2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9Cgku Zm9vdGVyIHsKCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1w b3J0YW50Cgl9CgkubWFpbiB7CgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDog NjA0cHggIWltcG9ydGFudAoJfQp9Cjwvc3R5bGU+Cgo8dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIg c3R5bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFs aWduPSJsZWZ0Ij4KCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3Ry PgoJPHRyPgoJCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2lu OiAwIj4KCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7 IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBh bGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPgoJCQkJPHRyPgoJCQkJCTx0ZCBhbGlnbj0iY2VudGVy IiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD4KCQkJCTwvdHI+CgkJCTwvdGFibGU+LS0+ CgoKPHRhYmxlPgogICAgICAgIDx0cj4KICAgICAgICAgICAgPHRkPgoJCQkJPHAgc3R5bGU9ImZv bnQtc2l6ZTogMTZweDtmb250LWZhbWlseTogYXJpYWw7Y29sb3I6IzAwMDAwMDtmb250LXdlaWdo dDogYm9sZDtsaW5lLWhlaWdodDogMjJweDsiPgogICAgICAgICAgICAgICAgICAgIEFERCBXb3Jr aW5nIEdyb3VwIGNoYW5nZWQgdGhlIFdlYmV4IG1lZXRpbmcgaW5mb3JtYXRpb24uCiAgICAgICAg ICAgICAgICA8L3A+CiAgICAgICAgICAgIDwvdGQ+CiAgICAgICAgPC90cj4KICAgICAgICA8dHIg c3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+CgkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyMHB4OyI+ Jm5ic3A7PC90ZD4KCQk8L3RyPgogICAgICAgIDx0cj4KICAgICAgICAgICAgPHRkPgoJCQkJPHAg c3R5bGU9ImZvbnQtc2l6ZTogMTZweDtmb250LWZhbWlseTogYXJpYWw7Y29sb3I6IzAwMDAwMDts aW5lLWhlaWdodDogMjJweDsiPgogICAgICAgICAgICAgICAgICAgIFdoZW4gaXQncyB0aW1lLCBq b2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuCiAgICAgICAgICAgICAgICA8L3A+CiAgICAgICAg ICAgIDwvdGQ+CiAgICAgICAgPC90cj4KICAgICAgICA8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+CgkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyMHB4OyI+Jm5ic3A7PC90ZD4KCQk8L3RyPgo8 L3RhYmxlPgoKCgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1w b3J0YW50OyI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LWZhbWlseTogYXJp YWw7IGNvbG9yOiAjMDAwMDAwOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiAyMnB4OyI+ CgkJCQkJCQkJCU1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDE3MSAyODkgODg1MQoJCQkJ CQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9 IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0ciA+CgkJCQkJCQkJ PHRkIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGNvbG9yOiAjMDAwMDAwOyBmb250LXNpemU6 IDE2cHg7IGxpbmUtaGVpZ2h0OiAyMnB4OyI+TWVldGluZyBwYXNzd29yZDogMkpBcG11WnM4Ujg8 L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCgkJCQkJCTx0YWJsZSAgd2lkdGg9IjEw MCUiPgoJCQkJCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMTZweDsiPgoJCQkJCQkJCTx0ZCBz dHlsZT0iaGVpZ2h0OiAxNnB4OyI+Jm5ic3A7PC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIg PgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHg7IGNvbG9yOiM2NjY2NjY7IGZvbnQt ZmFtaWx5OiBhcmlhbDsgbGluZS1oZWlnaHQ6IDIycHg7IG1hcmdpbjogMDsiPlRodXJzZGF5LCBT ZXB0ZW1iZXIgMTAsIDIwMjAKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJCTx0cj4K CQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjojNjY2NjY2OyBmb250LWZh bWlseTogYXJpYWw7IGxpbmUtaGVpZ2h0OiAyMnB4OyBtYXJnaW46IDA7Ij4KCQkJCQkJCQkJMTow MCBwbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsoVVRDKzAwOjAwKSBBem9yZXMmbmJzcDsmbmJz cDt8Jm5ic3A7Jm5ic3A7MiBocnMgMzAgbWlucwoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJ CQkJCQk8L3RhYmxlPgoKCiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZv bnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD4KCiAgICAKCgkJCTx0YWJsZSBzdHlsZT0icGFkZGlu Zy1ib3R0b206IDRweDtmb250LWZhbWlseTogQXJpYWw7Ij48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0 OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4K CQkJPHRhYmxlIHN0eWxlPSd3aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50Oyc+PHRyPjx0 ZCBzdHlsZT0nd2lkdGg6YXV0byFpbXBvcnRhbnQ7ICc+PHRhYmxlIGJvcmRlcj0nMCcgY2VsbHBh ZGRpbmc9JzAnIGNlbGxzcGFjaW5nPScwJyBzdHlsZT0nd2lkdGg6YXV0bzt3aWR0aDphdXRvIWlt cG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4IHNvbGlkICM0M0E5 NDI7IGJvcmRlci1yYWRpdXM6MjBweDsgbWluLXdpZHRoOjE2MHB4IWltcG9ydGFudDsnPjx0Ym9k eT48dHI+PHRkIGFsaWduPSdjZW50ZXInIHN0eWxlPSdwYWRkaW5nOjEwcHggMzZweDtmb250LWZh bWlseTogQXJpYWw7Jz48YSBocmVmPSdodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/ TVRJRD1tMDFjMjlhOWY5NzdiYjk2NzJhMzE1M2M5ZDg1MWUyYzMnIHN0eWxlPSdjb2xvcjojRkZG RkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Jz5Kb2luIG1lZXRpbmc8 L2E+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT4KCQkJPHRhYmxl Pjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDQ4cHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjQ4cHgiPiZu YnNwOzwvdGQ+PC90cj48L3RhYmxlPgoKCgk8dGFibGU+PHRyPjx0ZCBzdHlsZT0iY29sb3I6ICMw MDAwMDA7Zm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBi b2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPlRhcCB0byBqb2luIGZyb20gYSBtb2JpbGUgZGV2 aWNlIChhdHRlbmRlZXMgb25seSk8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+ PHRkIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0 OiAyNHB4OyI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcxMjg5ODg1MSUy MyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZv bnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4rMS02 NTAtNDc5LTMyMDgsLDE3MTI4OTg4NTEjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2Fu YWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyNHB4Ij48dGQgc3R5bGU9Imhl aWdodDoyNHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRib2R5Pjx0cj48dGQg c3R5bGU9ImNvbG9yOiAjMDAwMDAwO2ZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxMnB4 OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIGJ5IHBob25l PC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMz MzMzMzM7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRw eDsiPjEtNjUwLTQ3OS0zMjA4Jm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyI+Q2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvc3Bhbj48L3RkPjwvdHI+PHRyIHN0eWxlPSJt YXJnaW46MHB4Ij48dGQgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7 bGluZS1oZWlnaHQ6IDI0cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYv Z2xvYmFsY2FsbGluLnBocD9NVElEPW03ODg4MGI1MmU2NDM1YzJmMTAzZWE5Y2VhMWE2NmU0MyIg c3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjki Pkdsb2JhbCBjYWxsLWluIG51bWJlcnM8L2E+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48dGFi bGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0 OiAyOHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjhweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+ Cgk8dGFibGU+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJp YWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7 Ij48Yj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRpb248L2I+PC90ZD48L3Ry Pjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1m YW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8 YSBocmVmPSIgc2lwOjE3MTI4OTg4NTFAaWV0Zi53ZWJleC5jb20iICAgc3R5bGU9InRleHQtZGVj b3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjE3MTI4OTg4NTFAaWV0Zi53ZWJleC5jb208L2E+ PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMz MzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4 OyI+WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcg bnVtYmVyLjwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CiAg ICA8dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBzdHlsZT0i Y29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7IGZvbnQt d2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWljcm9zb2Z0 IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+PHRyIHN0 eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTog QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9 IiBzaXA6MTcxMjg5ODg1MS5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij4xNzEyODk4ODUxLmlldGZAbHluYy53ZWJleC5jb208 L2E+PC90ZD48L3RyPjwvdGFibGU+CgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIw cHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCgoJ CQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj4K ICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48 L3RyPgoJCQkJPHRyPgoJCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAwMDAw MDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7 Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9 ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2ViZXgu Y29tPC9hPgoJCQkJCTwvdGQ+CgkJCQk8L3RyPgogICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJo ZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+CgkJCTwvdGFibGU+CgkJPC90ZD4KCTwv dHI+CjwvdGFibGU+Cg== ------=_Part_1795171_781921190.1597425231308 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL0F6b3Jlcw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25l aW5mby1vdXRsb29rL0F0bGFudGljL0F6b3Jlcw0KWC1MSUMtTE9DQVRJT046QXRsYW50aWMvQXpv cmVzDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wMTAwDQpUWk9GRlNFVFRPOiswMDAw DQpUWk5BTUU6KzAwDQpEVFNUQVJUOjE5NzAwMzI5VDAwMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7 QllNT05USD0zO0JZREFZPS0xU1UNCkVORDpEQVlMSUdIVA0KQkVHSU46U1RBTkRBUkQNClRaT0ZG U0VURlJPTTorMDAwMA0KVFpPRkZTRVRUTzotMDEwMA0KVFpOQU1FOi0wMQ0KRFRTVEFSVDoxOTcw MTAyNVQwMTAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9OVEg9MTA7QllEQVk9LTFTVQ0KRU5E OlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDA4MTRU MTcxMzUxWg0KQVRURU5ERUU7Q049ImFkZEBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzphZGRAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQUREIFdvcmtpbmcg R3JvdXAiOk1BSUxUTzphZGQtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QXRsYW50aWMv QXpvcmVzOjIwMjAwOTEwVDEzMDAwMA0KRFRFTkQ7VFpJRD1BdGxhbnRpYy9Bem9yZXM6MjAyMDA5 MTBUMTUzMDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tMDFjMjlhOWY5NzdiYjk2NzJhMzE1M2M5ZDg1MWUyYzMNClRSQU5TUDpPUEFRVUUNClNFUVVF TkNFOjE1OTc0MjUyMzENClVJRDo0OTk5NzM3ZS05Y2NmLTQ5Y2MtODlmMC0zNjk4ZGQyMjQ5ZTEN CkRFU0NSSVBUSU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tMDFjMjlhOWY5NzdiYjk2NzJhMzE1M2M5ZDg1MWUyYzNc bk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDE3MSAyODkgODg1MVxuXG5NZWV0aW5nIHBh c3N3b3JkOiAySkFwbXVaczhSOFxuXG5cblxuVEFQIFRPIEpPSU4gRlJPTSBBIE1PQklMRSBERVZJ Q0UgKEFUVEVOREVFUyBPTkxZKVxuKzEtNjUwLTQ3OS0zMjA4LCwxNzEyODk4ODUxIyMgdGVsOiUy QjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcxMjg5ODg1MSUyMyUyMyowMSogQ2FsbC1pbiB0b2xsIG51 bWJlciAoVVMvQ2FuYWRhKVxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwt aW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuR2xvYmFsIGNhbGwtaW4gbnVtYmVyc1xuaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tNzg4ODBiNTJl NjQzNWMyZjEwM2VhOWNlYTFhNjZlNDNcblxuXG5KT0lOIEZST00gQSBWSURFTyBTWVNURU0gT1Ig QVBQTElDQVRJT05cbkRpYWwgc2lwOjE3MTI4OTg4NTFAaWV0Zi53ZWJleC5jb21cbllvdSBjYW4g YWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci5cblxu XG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5l c3NcbkRpYWwgc2lwOjE3MTI4OTg4NTEuaWV0ZkBseW5jLndlYmV4LmNvbVxuXG5cblxuXG5cbkNh bid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNv bS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3Rl IHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRp b24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBk aXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5 b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5v dCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0 aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVTQztGTVRUWVBF PXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxudGFibGUge1xuCWJvcmRlci1jb2xs YXBzZTogc2VwYXJhdGU7IHdpZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAw O31cblxudHIge1xuCWxpbmUtaGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTog MTRweDsJZm9udC1mYW1pbHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13 b3JkOwl3b3JkLWJyZWFrOiBub3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQt c2l6ZTogMjhweDt9XG5cbi5pbWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9 XG5cbi5mb290ZXIge1xuCXdpZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3Jl ZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6 ZTogMjJweCAhaW1wb3J0YW50Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFu dDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAx MDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4g e1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50 XG4JfVxufVxuPC9zdHlsZT5cblxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRk aW5nOiAwOyBtYXJnaW46IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+ XG4JPHRyIHN0eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxu CQk8dGQgYWxpZ249ImxlZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4J CQk8IS0tPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6 IDEwMCU7IHBhZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJs ZWZ0IiBjbGFzcz0ibWFpbiI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFs aWduPSJ0b3AiID4mbmJzcDsJCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5c blxuXG5cblxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0la RT0iNCIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGltZSwgam9pbiB0 aGUgV2ViZXggbWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJ CTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29k ZSk6IDE3MSAyODkgODg1MTwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJs ZT5cbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MkpBcG11WnM4Ujg8L0ZPTlQ+PC90ZD48L3Ry PjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJ CTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3aWR0 aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0MjsgYm9y ZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDoxNjBw eCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgc3R5 bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bTAxYzI5YTlmOTc3YmI5NjcyYTMxNTNjOWQ4NTFlMmMzIiBzdHlsZT0i Y29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Sm9p biBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwvdGQ+ XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAi IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBGQUNF PSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZPTlQg U0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+VGFwIHRvIGpvaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5 KTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE3MTI4OTg4NTElMjMl MjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250 LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+KzEtNjUw LTQ3OS0zMjA4LCwxNzEyODk4ODUxIyM8L2E+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSk8L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9O VD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZu YnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW03 ODg4MGI1MmU2NDM1YzJmMTAzZWE5Y2VhMWE2NmU0MyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpu b25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkdsb2JhbCBjYWxsLWluIG51bWJlcnM8 L2E+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1o ZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90 YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxp Y2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDoxNzEyODk4ODUxQGlldGYud2ViZXguY29tIj48 Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjE3MTI4OTg4NTFAaWV0 Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVu dGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05UPiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsg PEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBz dHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7 IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWlj cm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZh bWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxh IGhyZWY9IiBzaXA6MTcxMjg5ODg1MS5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij4xNzEyODk4ODUxLmlldGZAbHluYy53ZWJl eC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFi bGU+XG4JXG5cbgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xh c3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+ Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7 IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2Vi ZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRw Oi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAg ICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwv dGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFibGU+XG4NClNVTU1BUlk6U2Vzc2lvbiAxOiBJ RVRGIEFERCBTZXB0IEludGVyaW0NClBSSU9SSVRZOjUNCkNMQVNTOlBVQkxJQw0KQkVHSU46VkFM QVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJT046UmVtaW5kZXIN CkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== ------=_Part_1795171_781921190.1597425231308-- ------=_Part_1795170_1326298668.1597425231308 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL0F6b3Jlcw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25l aW5mby1vdXRsb29rL0F0bGFudGljL0F6b3Jlcw0KWC1MSUMtTE9DQVRJT046QXRsYW50aWMvQXpv cmVzDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wMTAwDQpUWk9GRlNFVFRPOiswMDAw DQpUWk5BTUU6KzAwDQpEVFNUQVJUOjE5NzAwMzI5VDAwMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7 QllNT05USD0zO0JZREFZPS0xU1UNCkVORDpEQVlMSUdIVA0KQkVHSU46U1RBTkRBUkQNClRaT0ZG U0VURlJPTTorMDAwMA0KVFpPRkZTRVRUTzotMDEwMA0KVFpOQU1FOi0wMQ0KRFRTVEFSVDoxOTcw MTAyNVQwMTAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9OVEg9MTA7QllEQVk9LTFTVQ0KRU5E OlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDA4MTRU MTcxMzUxWg0KQVRURU5ERUU7Q049ImFkZEBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzphZGRAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQUREIFdvcmtpbmcg R3JvdXAiOk1BSUxUTzphZGQtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QXRsYW50aWMv QXpvcmVzOjIwMjAwOTEwVDEzMDAwMA0KRFRFTkQ7VFpJRD1BdGxhbnRpYy9Bem9yZXM6MjAyMDA5 MTBUMTUzMDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tMDFjMjlhOWY5NzdiYjk2NzJhMzE1M2M5ZDg1MWUyYzMNClRSQU5TUDpPUEFRVUUNClNFUVVF TkNFOjE1OTc0MjUyMzENClVJRDo0OTk5NzM3ZS05Y2NmLTQ5Y2MtODlmMC0zNjk4ZGQyMjQ5ZTEN CkRFU0NSSVBUSU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tMDFjMjlhOWY5NzdiYjk2NzJhMzE1M2M5ZDg1MWUyYzNc bk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDE3MSAyODkgODg1MVxuXG5NZWV0aW5nIHBh c3N3b3JkOiAySkFwbXVaczhSOFxuXG5cblxuVEFQIFRPIEpPSU4gRlJPTSBBIE1PQklMRSBERVZJ Q0UgKEFUVEVOREVFUyBPTkxZKVxuKzEtNjUwLTQ3OS0zMjA4LCwxNzEyODk4ODUxIyMgdGVsOiUy QjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcxMjg5ODg1MSUyMyUyMyowMSogQ2FsbC1pbiB0b2xsIG51 bWJlciAoVVMvQ2FuYWRhKVxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwt aW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuR2xvYmFsIGNhbGwtaW4gbnVtYmVyc1xuaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tNzg4ODBiNTJl NjQzNWMyZjEwM2VhOWNlYTFhNjZlNDNcblxuXG5KT0lOIEZST00gQSBWSURFTyBTWVNURU0gT1Ig QVBQTElDQVRJT05cbkRpYWwgc2lwOjE3MTI4OTg4NTFAaWV0Zi53ZWJleC5jb21cbllvdSBjYW4g YWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci5cblxu XG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5l c3NcbkRpYWwgc2lwOjE3MTI4OTg4NTEuaWV0ZkBseW5jLndlYmV4LmNvbVxuXG5cblxuXG5cbkNh bid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNv bS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3Rl IHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRp b24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBk aXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5 b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5v dCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0 aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVTQztGTVRUWVBF PXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxudGFibGUge1xuCWJvcmRlci1jb2xs YXBzZTogc2VwYXJhdGU7IHdpZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAw O31cblxudHIge1xuCWxpbmUtaGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTog MTRweDsJZm9udC1mYW1pbHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13 b3JkOwl3b3JkLWJyZWFrOiBub3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQt c2l6ZTogMjhweDt9XG5cbi5pbWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9 XG5cbi5mb290ZXIge1xuCXdpZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3Jl ZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6 ZTogMjJweCAhaW1wb3J0YW50Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFu dDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAx MDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4g e1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50 XG4JfVxufVxuPC9zdHlsZT5cblxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRk aW5nOiAwOyBtYXJnaW46IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+ XG4JPHRyIHN0eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxu CQk8dGQgYWxpZ249ImxlZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4J CQk8IS0tPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6 IDEwMCU7IHBhZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJs ZWZ0IiBjbGFzcz0ibWFpbiI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFs aWduPSJ0b3AiID4mbmJzcDsJCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5c blxuXG5cblxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0la RT0iNCIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGltZSwgam9pbiB0 aGUgV2ViZXggbWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJ CTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29k ZSk6IDE3MSAyODkgODg1MTwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJs ZT5cbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MkpBcG11WnM4Ujg8L0ZPTlQ+PC90ZD48L3Ry PjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJ CTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3aWR0 aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0MjsgYm9y ZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDoxNjBw eCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgc3R5 bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bTAxYzI5YTlmOTc3YmI5NjcyYTMxNTNjOWQ4NTFlMmMzIiBzdHlsZT0i Y29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Sm9p biBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwvdGQ+ XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAi IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBGQUNF PSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZPTlQg U0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+VGFwIHRvIGpvaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5 KTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE3MTI4OTg4NTElMjMl MjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250 LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+KzEtNjUw LTQ3OS0zMjA4LCwxNzEyODk4ODUxIyM8L2E+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSk8L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9O VD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZu YnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW03 ODg4MGI1MmU2NDM1YzJmMTAzZWE5Y2VhMWE2NmU0MyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpu b25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkdsb2JhbCBjYWxsLWluIG51bWJlcnM8 L2E+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1o ZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90 YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxp Y2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDoxNzEyODk4ODUxQGlldGYud2ViZXguY29tIj48 Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjE3MTI4OTg4NTFAaWV0 Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVu dGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05UPiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsg PEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBz dHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7 IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWlj cm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZh bWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxh IGhyZWY9IiBzaXA6MTcxMjg5ODg1MS5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij4xNzEyODk4ODUxLmlldGZAbHluYy53ZWJl eC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFi bGU+XG4JXG5cbgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xh c3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+ Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7 IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2Vi ZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRw Oi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAg ICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwv dGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFibGU+XG4NClNVTU1BUlk6U2Vzc2lvbiAxOiBJ RVRGIEFERCBTZXB0IEludGVyaW0NClBSSU9SSVRZOjUNCkNMQVNTOlBVQkxJQw0KQkVHSU46VkFM QVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJT046UmVtaW5kZXIN CkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== ------=_Part_1795170_1326298668.1597425231308-- From nobody Fri Aug 14 10:15: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 A9EDF3A0E9C for ; Fri, 14 Aug 2020 10:15:00 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 VP8ae7ooFi7z for ; Fri, 14 Aug 2020 10:14:59 -0700 (PDT) Received: from sjmda09.webex.com (sjmda09.webex.com [64.68.122.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361343A0FF3 for ; Fri, 14 Aug 2020 10:14:59 -0700 (PDT) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda09.webex.com (Postfix) with ESMTP id 241C0300CDFE for ; Fri, 14 Aug 2020 17:14:59 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id A0491100CEA2 for ; Fri, 14 Aug 2020 17:14:58 +0000 (GMT) Date: Fri, 14 Aug 2020 17:14:58 +0000 (GMT) From: ADD Working Group Reply-To: add-chairs@ietf.org To: add@ietf.org Message-ID: <1303183167.8976171597425298653.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1795210_99939614.1597425298653" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=169571457136864688, X-WBX-TID=4u6t6iejyhq9ouq4lo5ksg37556hwicjvxsppcpraplfjqpaat904e9g, X-WBX-RID=80d1fb6d408e4dcab8e43778d037050c, X-WBX-SVC:Meeting Center, X-WBX-TT:Meeting Invitation, Date:Fri Aug 14 17:14:58 GMT 2020 reminder-40.8.0-3226 Archived-At: Subject: [Add] Webex meeting invitation: Session 2: IETF ADD WG Sept Interim 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: Fri, 14 Aug 2020 17:15:01 -0000 ------=_Part_1795210_99939614.1597425298653 Content-Type: multipart/Alternative; boundary="----=_Part_1795211_688953079.1597425298653" ------=_Part_1795211_688953079.1597425298653 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBhZGRAaWV0Zi5vcmcsCgpBREQgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2lu IHRoaXMgV2ViZXggbWVldGluZy4KCgpTZXNzaW9uIDI6IElFVEYgQUREIFdHIFNlcHQgSW50ZXJp bSAKVHVlc2RheSwgU2VwdGVtYmVyIDE1LCAyMDIwCjE6MDAgcG0gIHwgIChVVEMrMDA6MDApIEF6 b3JlcyAgfCAgMiBocnMgMzAgbWlucwpNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiAxNzEg NDY0IDY5NDEgCk1lZXRpbmcgcGFzc3dvcmQ6IDJKQXBtdVpzOFI4CgoKCldoZW4gaXQncyB0aW1l LCBqb2luIHRoZSBtZWV0aW5nLgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tYjNhYzRjZjU4MWQ5YmQ3MjYzYWExZDY0YzIzYzMwZDYKCkFkZCB0byBDYWxlbmRhcgpodHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMGFkYTI0ZGExM2EzMGZkNGMxZDM0 MWMxZGUxNDYxOGQNCg0KCgoNClRBUCBUTyBKT0lOIEZST00gQSBNT0JJTEUgREVWSUNFIChBVFRF TkRFRVMgT05MWSkNCisxLTY1MC00NzktMzIwOCwsMTcxNDY0Njk0MSMjIHRlbDolMkIxLTY1MC00 NzktMzIwOCwsKjAxKjE3MTQ2NDY5NDElMjMlMjMqMDEqIENhbGwtaW4gdG9sbCBudW1iZXIgKFVT L0NhbmFkYSkKDQoNCkpPSU4gQlkgUEhPTkUNCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBu dW1iZXIgKFVTL0NhbmFkYSkKDQpHbG9iYWwgY2FsbC1pbiBudW1iZXJzDQpodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW00Y2QwYjFiZDlmMzNhZDFiZGFm NGI0ZmE5MGI2MmIyZQ0KDQoKSk9JTiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9O CkRpYWwgc2lwOjE3MTQ2NDY5NDFAaWV0Zi53ZWJleC5jb20KWW91IGNhbiBhbHNvIGRpYWwgMTcz LjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLgoKCkpvaW4gdXNpbmcgTWlj cm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzcwpEaWFsIHNpcDoxNzE0 NjQ2OTQxLmlldGZAbHluYy53ZWJleC5jb20KCgoKCgpDYW4ndCBqb2luIHRoZSBtZWV0aW5nPwpo dHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NQoK CklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFs bG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24g dG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0 ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRv IHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVk LCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUg c2Vzc2lvbi4K ------=_Part_1795211_688953079.1597425298653 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KdGFibGUgewoJYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0 ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7fQoKdHIgewoJbGlu ZS1oZWlnaHQ6IDE4cHg7fQoKYSwgdGQgewoJZm9udC1zaXplOiAxNHB4Owlmb250LWZhbWlseTog QXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5v cm1hbDsJcGFkZGluZzogMDt9CgoudGl0bGUgewoJZm9udC1zaXplOiAyOHB4O30KCi5pbWFnZSB7 Cgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO30KCi5mb290ZXIgewoJd2lkdGg6IDYwNHB4 O30KCi5tYWluIHsKCn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgp IHsKCS50aXRsZSB7CgkJZm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX0KCS5pbWFnZSB7CgkJ d2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9Cgku Zm9vdGVyIHsKCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1w b3J0YW50Cgl9CgkubWFpbiB7CgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDog NjA0cHggIWltcG9ydGFudAoJfQp9Cjwvc3R5bGU+Cgo8dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIg c3R5bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFs aWduPSJsZWZ0Ij4KCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3Ry PgoJPHRyPgoJCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2lu OiAwIj4KCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7 IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBh bGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPgoJCQkJPHRyPgoJCQkJCTx0ZCBhbGlnbj0iY2VudGVy IiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD4KCQkJCTwvdHI+CgkJCTwvdGFibGU+LS0+ CgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgIDx0ZCBzdHlsZT0iaGVpZ2h0OiAyMnB4 O2NvbG9yOiAjMDAwMDAwO2ZvbnQtZmFtaWx5OiBBcmlhbDsJZm9udC1zaXplOiAxNnB4O2ZvbnQt d2VpZ2h0OiBib2xkO2xpbmUtaGVpZ2h0OiAyMnB4OyI+CiAgICAgICAgICAgICAgICBBREQgV29y a2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViZXggbWVldGluZy4KICAgICAg ICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoKPHRhYmxl Pjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCiAgICA8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdp ZHRoOmF1dG8haW1wb3J0YW50OyI+CiAgICAgICAgPHRyPgogICAgICAgICAgICA8dGQgc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtc2l6ZTogMTZweDsgbGlu ZS1oZWlnaHQ6IDIycHg7Ij4KICAgICAgICAgICAgICAgIE1lZXRpbmcgbnVtYmVyIChhY2Nlc3Mg Y29kZSk6IDE3MSA0NjQgNjk0MQogICAgICAgICAgICA8L3RkPgogICAgICAgIDwvdHI+CiAgICA8 L3RhYmxlPgogICAgPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFu dCI+CiAgICAgICAgPHRyID4KICAgICAgICAgICAgPHRkIHN0eWxlPSJmb250LWZhbWlseTogQXJp YWw7IGNvbG9yOiAjMDAwMDAwOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiAyMnB4OyI+ TWVldGluZyBwYXNzd29yZDogMkpBcG11WnM4Ujg8L3RkPgogICAgICAgIDwvdHI+CiAgICA8L3Rh YmxlPgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoKICAgIDx0YWJsZSAgd2lkdGg9IjEw MCUiPgogICAgICAgIDx0ciBzdHlsZT0ibWFyZ2luOjBweDtjb2xvcjogIzY2NjY2Njtmb250LWZh bWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyMnB4OyI+CiAgICAgICAg ICAgIDx0ZCBzdHlsZT0ibWFyZ2luOjBweDtjb2xvcjogIzY2NjY2Njtmb250LWZhbWlseTogQXJp YWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyMnB4OyI+VHVlc2RheSwgU2VwdGVtYmVy IDE1LCAyMDIwCiAgICAgICAgICAgIDwvdGQ+CiAgICAgICAgPC90cj4KICAgICAgICA8dHIgc3R5 bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsiPgogICAgICAgICAgICA8dGQgc3R5bGU9Im1hcmdp bjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDts aW5lLWhlaWdodDogMjJweDsiPjE6MDAgcG0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7KFVUQysw MDowMCkgQXpvcmVzJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzIgaHJzIDMwIG1pbnMKICAgICAg ICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KCiA8Rk9OVCBzaXplPSIyIiBD T0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD4KCiAgICAK CgkJCTx0YWJsZSBzdHlsZT0icGFkZGluZy1ib3R0b206IDRweDtmb250LWZhbWlseTogQXJpYWw7 Ij48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlIHN0eWxlPSd3aWR0aDphdXRvO3dpZHRo OmF1dG8haW1wb3J0YW50Oyc+PHRyPjx0ZCBzdHlsZT0nd2lkdGg6YXV0byFpbXBvcnRhbnQ7ICc+ PHRhYmxlIGJvcmRlcj0nMCcgY2VsbHBhZGRpbmc9JzAnIGNlbGxzcGFjaW5nPScwJyBzdHlsZT0n d2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjojNDNBOTQy OyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjBweDsgbWluLXdpZHRo OjE2MHB4IWltcG9ydGFudDsnPjx0Ym9keT48dHI+PHRkIGFsaWduPSdjZW50ZXInIHN0eWxlPSdw YWRkaW5nOjEwcHggMzZweDtmb250LWZhbWlseTogQXJpYWw7Jz48YSBocmVmPSdodHRwczovL2ll dGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tYjNhYzRjZjU4MWQ5YmQ3MjYzYWExZDY0YzIz YzMwZDYnIHN0eWxlPSdjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0 aW9uOm5vbmU7Jz5Kb2luIG1lZXRpbmc8L2E+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L3Rk PjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDQ4cHgiPjx0 ZCBzdHlsZT0iaGVpZ2h0OjQ4cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoKCgk8dGFibGU+ PHRyPjx0ZCBzdHlsZT0iY29sb3I6ICMwMDAwMDA7Zm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNp emU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPlRhcCB0 byBqb2luIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSk8L2I+PC90ZD48L3Ry Pjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Zm9u dC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4OyI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3 OS0zMjA4LCwqMDEqMTcxNDY0Njk0MSUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAg dGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7 bGluZS1oZWlnaHQ6IDI0cHg7Jz4rMS02NTAtNDc5LTMyMDgsLDE3MTQ2NDY5NDEjIzwvYT4gQ2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9ImxpbmUtaGVp Z2h0OiAyNHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyNHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJs ZT48dGFibGU+PHRib2R5Pjx0cj48dGQgc3R5bGU9ImNvbG9yOiAjMDAwMDAwO2ZvbnQtZmFtaWx5 OiBBcmlhbDsgZm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6 IDI0cHg7Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjow cHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsiPjEtNjUwLTQ3OS0zMjA4Jm5ic3A7PHNwYW4gc3R5 bGU9ImNvbG9yOiAjMzMzMzMzOyI+Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvc3Bh bj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Ij48YSBocmVmPSJodHRw czovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW00Y2QwYjFiZDlm MzNhZDFiZGFmNGI0ZmE5MGI2MmIyZSIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQt c2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkdsb2JhbCBjYWxsLWluIG51bWJlcnM8L2E+PC90ZD48 L3RyPjwvdGJvZHk+PC90YWJsZT48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIw Ij48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjhweCI+ Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+Cgk8dGFibGU+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAj MDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDog Ym9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0gb3Ig YXBwbGljYXRpb248L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxl PSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxp bmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjE3MTQ2NDY5NDFAaWV0Zi53ZWJl eC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjE3MTQ2 NDY5NDFAaWV0Zi53ZWJleC5jb208L2E+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+ PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6 IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4 IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48 dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5i c3A7PC90ZD48L3RyPjwvdGFibGU+CiAgICA8dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIwIj48dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlh bDtmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsi PjxiPkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNp bmVzczwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9y OiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWln aHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9IiBzaXA6MTcxNDY0Njk0MS5pZXRmQGx5bmMud2ViZXgu Y29tIiAgIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij4xNzE0NjQ2 OTQxLmlldGZAbHluYy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+CgoJPHRhYmxlPjx0 ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNw OzwvdGQ+PC90cj48L3RhYmxlPgoJCgoJCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxp Z249ImxlZnQiIGNsYXNzPSJtYWluIj4KICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0 OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPgoJCQkJPHRyPgoJCQkJCTx0ZCBzdHlsZT0iaGVp Z2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTog MTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6 Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpu b25lOyI+aHR0cDovL2hlbHAud2ViZXguY29tPC9hPgoJCQkJCTwvdGQ+CgkJCQk8L3RyPgogICAg ICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+ CgkJCTwvdGFibGU+CgkJPC90ZD4KCTwvdHI+CjwvdGFibGU+Cg== ------=_Part_1795211_688953079.1597425298653 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL0F6b3Jlcw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25l aW5mby1vdXRsb29rL0F0bGFudGljL0F6b3Jlcw0KWC1MSUMtTE9DQVRJT046QXRsYW50aWMvQXpv cmVzDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wMTAwDQpUWk9GRlNFVFRPOiswMDAw DQpUWk5BTUU6KzAwDQpEVFNUQVJUOjE5NzAwMzI5VDAwMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7 QllNT05USD0zO0JZREFZPS0xU1UNCkVORDpEQVlMSUdIVA0KQkVHSU46U1RBTkRBUkQNClRaT0ZG U0VURlJPTTorMDAwMA0KVFpPRkZTRVRUTzotMDEwMA0KVFpOQU1FOi0wMQ0KRFRTVEFSVDoxOTcw MTAyNVQwMTAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9OVEg9MTA7QllEQVk9LTFTVQ0KRU5E OlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDA4MTRU MTcxNDU4Wg0KQVRURU5ERUU7Q049ImFkZEBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzphZGRAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQUREIFdvcmtpbmcg R3JvdXAiOk1BSUxUTzphZGQtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QXRsYW50aWMv QXpvcmVzOjIwMjAwOTE1VDEzMDAwMA0KRFRFTkQ7VFpJRD1BdGxhbnRpYy9Bem9yZXM6MjAyMDA5 MTVUMTUzMDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tYjNhYzRjZjU4MWQ5YmQ3MjYzYWExZDY0YzIzYzMwZDYNClRSQU5TUDpPUEFRVUUNClNFUVVF TkNFOjE1OTc0MjUyOTgNClVJRDpkM2YyOGVlOS0xZjY2LTRkNDYtOWMyZS1jZDA1ZmE5ZDk1MWQN CkRFU0NSSVBUSU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tYjNhYzRjZjU4MWQ5YmQ3MjYzYWExZDY0YzIzYzMwZDZc bk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDE3MSA0NjQgNjk0MVxuXG5NZWV0aW5nIHBh c3N3b3JkOiAySkFwbXVaczhSOFxuXG5cblxuVEFQIFRPIEpPSU4gRlJPTSBBIE1PQklMRSBERVZJ Q0UgKEFUVEVOREVFUyBPTkxZKVxuKzEtNjUwLTQ3OS0zMjA4LCwxNzE0NjQ2OTQxIyMgdGVsOiUy QjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcxNDY0Njk0MSUyMyUyMyowMSogQ2FsbC1pbiB0b2xsIG51 bWJlciAoVVMvQ2FuYWRhKVxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwt aW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuR2xvYmFsIGNhbGwtaW4gbnVtYmVyc1xuaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tNGNkMGIxYmQ5 ZjMzYWQxYmRhZjRiNGZhOTBiNjJiMmVcblxuXG5KT0lOIEZST00gQSBWSURFTyBTWVNURU0gT1Ig QVBQTElDQVRJT05cbkRpYWwgc2lwOjE3MTQ2NDY5NDFAaWV0Zi53ZWJleC5jb21cbllvdSBjYW4g YWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci5cblxu XG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5l c3NcbkRpYWwgc2lwOjE3MTQ2NDY5NDEuaWV0ZkBseW5jLndlYmV4LmNvbVxuXG5cblxuXG5cbkNh bid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNv bS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3Rl IHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRp b24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBk aXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5 b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5v dCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0 aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVTQztGTVRUWVBF PXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxudGFibGUge1xuCWJvcmRlci1jb2xs YXBzZTogc2VwYXJhdGU7IHdpZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAw O31cblxudHIge1xuCWxpbmUtaGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTog MTRweDsJZm9udC1mYW1pbHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13 b3JkOwl3b3JkLWJyZWFrOiBub3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQt c2l6ZTogMjhweDt9XG5cbi5pbWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9 XG5cbi5mb290ZXIge1xuCXdpZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3Jl ZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6 ZTogMjJweCAhaW1wb3J0YW50Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFu dDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAx MDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4g e1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50 XG4JfVxufVxuPC9zdHlsZT5cblxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRk aW5nOiAwOyBtYXJnaW46IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+ XG4JPHRyIHN0eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxu CQk8dGQgYWxpZ249ImxlZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4J CQk8IS0tPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6 IDEwMCU7IHBhZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJs ZWZ0IiBjbGFzcz0ibWFpbiI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFs aWduPSJ0b3AiID4mbmJzcDsJCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5c blxuXG5cblxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0la RT0iNCIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGltZSwgam9pbiB0 aGUgV2ViZXggbWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJ CTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29k ZSk6IDE3MSA0NjQgNjk0MTwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJs ZT5cbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MkpBcG11WnM4Ujg8L0ZPTlQ+PC90ZD48L3Ry PjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJ CTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3aWR0 aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0MjsgYm9y ZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDoxNjBw eCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgc3R5 bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bWIzYWM0Y2Y1ODFkOWJkNzI2M2FhMWQ2NGMyM2MzMGQ2IiBzdHlsZT0i Y29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Sm9p biBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwvdGQ+ XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAi IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBGQUNF PSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZPTlQg U0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+VGFwIHRvIGpvaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5 KTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE3MTQ2NDY5NDElMjMl MjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250 LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+KzEtNjUw LTQ3OS0zMjA4LCwxNzE0NjQ2OTQxIyM8L2E+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSk8L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9O VD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZu YnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW00 Y2QwYjFiZDlmMzNhZDFiZGFmNGI0ZmE5MGI2MmIyZSIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpu b25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkdsb2JhbCBjYWxsLWluIG51bWJlcnM8 L2E+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1o ZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90 YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxp Y2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDoxNzE0NjQ2OTQxQGlldGYud2ViZXguY29tIj48 Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjE3MTQ2NDY5NDFAaWV0 Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVu dGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05UPiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsg PEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBz dHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7 IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWlj cm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZh bWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxh IGhyZWY9IiBzaXA6MTcxNDY0Njk0MS5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij4xNzE0NjQ2OTQxLmlldGZAbHluYy53ZWJl eC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFi bGU+XG4JXG5cbgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xh c3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+ Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7 IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2Vi ZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRw Oi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAg ICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwv dGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFibGU+XG4NClNVTU1BUlk6U2Vzc2lvbiAyOiBJ RVRGIEFERCBXRyBTZXB0IEludGVyaW0gDQpQUklPUklUWTo1DQpDTEFTUzpQVUJMSUMNCkJFR0lO OlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJlbWlu ZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= ------=_Part_1795211_688953079.1597425298653-- ------=_Part_1795210_99939614.1597425298653 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL0F6b3Jlcw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25l aW5mby1vdXRsb29rL0F0bGFudGljL0F6b3Jlcw0KWC1MSUMtTE9DQVRJT046QXRsYW50aWMvQXpv cmVzDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wMTAwDQpUWk9GRlNFVFRPOiswMDAw DQpUWk5BTUU6KzAwDQpEVFNUQVJUOjE5NzAwMzI5VDAwMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7 QllNT05USD0zO0JZREFZPS0xU1UNCkVORDpEQVlMSUdIVA0KQkVHSU46U1RBTkRBUkQNClRaT0ZG U0VURlJPTTorMDAwMA0KVFpPRkZTRVRUTzotMDEwMA0KVFpOQU1FOi0wMQ0KRFRTVEFSVDoxOTcw MTAyNVQwMTAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9OVEg9MTA7QllEQVk9LTFTVQ0KRU5E OlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDA4MTRU MTcxNDU4Wg0KQVRURU5ERUU7Q049ImFkZEBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzphZGRAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQUREIFdvcmtpbmcg R3JvdXAiOk1BSUxUTzphZGQtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QXRsYW50aWMv QXpvcmVzOjIwMjAwOTE1VDEzMDAwMA0KRFRFTkQ7VFpJRD1BdGxhbnRpYy9Bem9yZXM6MjAyMDA5 MTVUMTUzMDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tYjNhYzRjZjU4MWQ5YmQ3MjYzYWExZDY0YzIzYzMwZDYNClRSQU5TUDpPUEFRVUUNClNFUVVF TkNFOjE1OTc0MjUyOTgNClVJRDpkM2YyOGVlOS0xZjY2LTRkNDYtOWMyZS1jZDA1ZmE5ZDk1MWQN CkRFU0NSSVBUSU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tYjNhYzRjZjU4MWQ5YmQ3MjYzYWExZDY0YzIzYzMwZDZc bk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDE3MSA0NjQgNjk0MVxuXG5NZWV0aW5nIHBh c3N3b3JkOiAySkFwbXVaczhSOFxuXG5cblxuVEFQIFRPIEpPSU4gRlJPTSBBIE1PQklMRSBERVZJ Q0UgKEFUVEVOREVFUyBPTkxZKVxuKzEtNjUwLTQ3OS0zMjA4LCwxNzE0NjQ2OTQxIyMgdGVsOiUy QjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcxNDY0Njk0MSUyMyUyMyowMSogQ2FsbC1pbiB0b2xsIG51 bWJlciAoVVMvQ2FuYWRhKVxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwt aW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuR2xvYmFsIGNhbGwtaW4gbnVtYmVyc1xuaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tNGNkMGIxYmQ5 ZjMzYWQxYmRhZjRiNGZhOTBiNjJiMmVcblxuXG5KT0lOIEZST00gQSBWSURFTyBTWVNURU0gT1Ig QVBQTElDQVRJT05cbkRpYWwgc2lwOjE3MTQ2NDY5NDFAaWV0Zi53ZWJleC5jb21cbllvdSBjYW4g YWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci5cblxu XG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5l c3NcbkRpYWwgc2lwOjE3MTQ2NDY5NDEuaWV0ZkBseW5jLndlYmV4LmNvbVxuXG5cblxuXG5cbkNh bid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNv bS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3Rl IHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRp b24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBk aXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5 b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5v dCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0 aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbg0KWC1BTFQtREVTQztGTVRUWVBF PXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxudGFibGUge1xuCWJvcmRlci1jb2xs YXBzZTogc2VwYXJhdGU7IHdpZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAw O31cblxudHIge1xuCWxpbmUtaGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTog MTRweDsJZm9udC1mYW1pbHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13 b3JkOwl3b3JkLWJyZWFrOiBub3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQt c2l6ZTogMjhweDt9XG5cbi5pbWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9 XG5cbi5mb290ZXIge1xuCXdpZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3Jl ZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6 ZTogMjJweCAhaW1wb3J0YW50Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFu dDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAx MDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4g e1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50 XG4JfVxufVxuPC9zdHlsZT5cblxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRk aW5nOiAwOyBtYXJnaW46IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+ XG4JPHRyIHN0eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxu CQk8dGQgYWxpZ249ImxlZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4J CQk8IS0tPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6 IDEwMCU7IHBhZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJs ZWZ0IiBjbGFzcz0ibWFpbiI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFs aWduPSJ0b3AiID4mbmJzcDsJCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5c blxuXG5cblxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0la RT0iNCIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGltZSwgam9pbiB0 aGUgV2ViZXggbWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJ CTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29k ZSk6IDE3MSA0NjQgNjk0MTwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJs ZT5cbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MkpBcG11WnM4Ujg8L0ZPTlQ+PC90ZD48L3Ry PjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJ CTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3aWR0 aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0MjsgYm9y ZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDoxNjBw eCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgc3R5 bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bWIzYWM0Y2Y1ODFkOWJkNzI2M2FhMWQ2NGMyM2MzMGQ2IiBzdHlsZT0i Y29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Sm9p biBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwvdGQ+ XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAi IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBGQUNF PSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZPTlQg U0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+VGFwIHRvIGpvaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5 KTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE3MTQ2NDY5NDElMjMl MjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250 LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+KzEtNjUw LTQ3OS0zMjA4LCwxNzE0NjQ2OTQxIyM8L2E+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSk8L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9O VD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZu YnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW00 Y2QwYjFiZDlmMzNhZDFiZGFmNGI0ZmE5MGI2MmIyZSIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpu b25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkdsb2JhbCBjYWxsLWluIG51bWJlcnM8 L2E+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1o ZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90 YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxp Y2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDoxNzE0NjQ2OTQxQGlldGYud2ViZXguY29tIj48 Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjE3MTQ2NDY5NDFAaWV0 Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVu dGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05UPiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsg PEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBz dHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7 IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWlj cm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZh bWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxh IGhyZWY9IiBzaXA6MTcxNDY0Njk0MS5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij4xNzE0NjQ2OTQxLmlldGZAbHluYy53ZWJl eC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFi bGU+XG4JXG5cbgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xh c3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+ Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7 IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2Vi ZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRw Oi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAg ICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwv dGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFibGU+XG4NClNVTU1BUlk6U2Vzc2lvbiAyOiBJ RVRGIEFERCBXRyBTZXB0IEludGVyaW0gDQpQUklPUklUWTo1DQpDTEFTUzpQVUJMSUMNCkJFR0lO OlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJlbWlu ZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= ------=_Part_1795210_99939614.1597425298653-- From nobody Fri Aug 14 10:32: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 DB08F3A0F85 for ; Fri, 14 Aug 2020 10:32:33 -0700 (PDT) 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=comcast.com header.b=iDQd6et8; dkim=pass (2048-bit key) header.d=comcast.com header.b=3azI3Qsq; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=NRpXr6d5 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 utir9Xcr6AmL for ; Fri, 14 Aug 2020 10:32:32 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.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 BE7E23A11DB for ; Fri, 14 Aug 2020 10:32:23 -0700 (PDT) Received: from pps.filterd (m0184893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07EHV9Wq011300 for ; Fri, 14 Aug 2020 13:32:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : mime-version; s=20190412; bh=f+pfXjNLQi1/6UIycDcdEhQ6V6zG5bQ4reVI3NkFrY0=; b=iDQd6et8mV5xoZaRd64kAzqexZpjAPQ9l/xRvj5plc4O1Ggu/shJWljBNC4KTPq4FJMx RjfkUrssZIxt8QU7mVxPYGyfBsniGVDU/5oPXlTBVLoCfUH0ggHVJysxRtFAYTNqckWq Tyog+I8r8X4SYPIfcArrh7onMA1kLBsfN1TCGMI+M3WC6VNCNImkgtOKzBQ7C6oMKHM9 obXRMWucZkfras075avCPPkxGO0l0mXMMGQLC0Ytrq9MKpCGyWgagQfYMYsd2W3k2YSU Kj7Xud4gX9ZwCrTCeRzPFS6JCz2wLisvBH+a+1ATqDizrcZWn5HduT/1M7Y68ltUu5ux YQ== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 32srmckyc7-223 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 14 Aug 2020 13:32:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1597426342; x=2461339942; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=f+pfXjNLQi1/6UIycDcdEhQ6V6zG5bQ4reVI3NkFrY0=; b=3azI3QsqeBgIEeV4R3W7pug4wlT79IFwpE9GgdtSxNWW7EmF+zKYV9LUBozl3z9u qL9h3RxXNC8rV4FjNDpywgG7ZSwkvEFDtSNIda9PZOG/LVSytaAD4OG2Nu9w/yF4 jAcYNP4sgWOQIzbGnifF1VVEZDzQrN4FXxKqfLcHjAIbrAQpYeVCO0XHaqS87t98 kTS8jjdnKstA6Z4rad+JZdBm/5k7JxOBkqncWi/QVo3Whgc58sXmg85AH5Y6uJyc B7aVtHhl2Nvuwng+DxWHTr6VzwPHLPd4sEDxd2GND8Gc9knKiw/kUCcDfVqi0+q8 +s1qBoIdm6LY0NCHwDqFjA==; X-AuditID: 60729ed4-fd70c9e000003048-18-5f36caa65be7 Received: from copdcexc34.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id CB.13.12360.6AAC63F5; Fri, 14 Aug 2020 11:32:22 -0600 (MDT) Received: from COPDCEX10.cable.comcast.com (147.191.124.141) by copdcexc34.cable.comcast.com (147.191.125.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 14 Aug 2020 11:32:21 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX10.cable.comcast.com (147.191.124.141) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 14 Aug 2020 11:32:21 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.45) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 14 Aug 2020 13:31:59 -0400 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BY5PR11MB4225.namprd11.prod.outlook.com (2603:10b6:a03:1ba::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Fri, 14 Aug 2020 17:31:58 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6%7]) with mapi id 15.20.3261.024; Fri, 14 Aug 2020 17:31:58 +0000 From: "Deen, Glenn" To: ADD Mailing list Thread-Topic: ADD September Interim sessions Thread-Index: AQHWcmDP/9Caxc3fz0GHnnBP16zC0A== Date: Fri, 14 Aug 2020 17:31:57 +0000 Message-ID: <362B1409-17A1-4B44-AEA7-A13837290B9B@comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:f54f:45e5:51a2:6be4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 494e1082-e134-45c2-0d59-08d84077f229 x-ms-traffictypediagnostic: BY5PR11MB4225: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tH6XULWSwpDZ+KTUrVdfDYo0xFFLaJHd+4zPPSI4WJm7JSao+TgfkYsPfRm06gurXARGmWIw9mtEsWO5WRW/i88QIleVb7m2XfsBJXGTzD1gG2W8sT8kUp2zthGJDhEnGicZIXAKgc/KvoYgJHpGuccLwCq8AU9tHaaifTgIYXxz3E0XklMsG7JCinAoj+WhdapReKGR/nRffqlHVB1dstl2JRCPsYjHGo++ep4yvaST2Gqeq4sM7zdVh9M563hCpbYYCLnO/B8CPA4ld2gVpohqIFNR7xRC1s8wzVgC/bPWjuFxVZdylfBAt8iY+m+07VDZvNBoXLRxuDk5jXU0ZIsu6RWedwmtmHs3gdt3GyZTh/YgkHC7MxSacH0s44qZytkkPxgt87MghLk3I23vPQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(346002)(136003)(396003)(39860400002)(64756008)(66446008)(66946007)(71200400001)(5660300002)(8676002)(45080400002)(6506007)(186003)(2906002)(76116006)(8936002)(66476007)(66556008)(16799955002)(966005)(83380400001)(6512007)(33656002)(316002)(6486002)(6916009)(166002)(3480700007)(36756003)(2616005)(478600001)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: KcRJi/NVJKscTY1qvsCq4qKiKwdHdnmLz4Z6Yd60qRl1/l4eOWbtRHT84grv5Sugm+BRD4o2/yo/5qTg+glOUGrmHNGLNzE9tzut5MSbdsrSAHi0Wkr42WllEPMxMtWcFtx+LtTQsXOX/DJ34ePfD59jw98SCC6yAB77k/F1oVANjILkyWg/Dairbj1GCa8YPsCe1SnrtDbqOmh+RIeEQz5jy20FuP5+o+13DEXZxeMjGbP82kPeNTPSn9XEKWA1imKA9dEhSiPnzqvKNtX2wP67omdylcn3gsXQ/ryr6bGdkzwpwuLCVtDcBZipVGEce0R/XKasL6O7m9HmnEqDH70PR3/zBAvFTi9MwoLJqVT/Zi6XdE5XIW/6Ci+VNAYASlODJuLQ/c7YBU9ZeA7fsHkKhHmXfbys1k1F6SIdA80mv52CxFFrn1KZg9VGF0yHzSCm17wK1kx0aZJw5arsgRxoHOd83O8yx8qoaaWZP6yRnfpKmlbc+1PDKBvOtp2swhxgoRN/7IT6zRIo/JsEFybfZz6Qvr4g90azj25uXmc0M+HhsN2gijoPmbpjQsepJLmk+BPmWUCvv9PYldg9xIWN8nidmoDfcC1OyfXxddUYBd0maciMyJN1k8L6DUtkxpye8hA+xxYkB/kOreSFFeI3NeGnSwGI8tf79CxQOBfHbbNSxzynw3lX6ZKtbPTbeoOV94rb37FwsyqsqhOrHg== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bj3Ab3hPH8Cr1Ufx+ontEjfW6yQPhjdeFgKHyB5xFkZUdcRPOwhgmaGX65PgprCOPNLqDegIWGUvExj3HYEhIw6KebapcS6FPZoUWH6h7AuyhIf2oPQbBa8+r2gQ7shLlCj0B7oU8h3HrNnF8rTkLgDe4tsV8RrVs9atRlg2Gi4HpVyEJS5JKSJ311Gihj9N2VGPyttRxHBRld5vB6+sEIIENUkKRX7wkjuAfJfgeXd2Gfhmez6YjhrUzh7vFMz0SBQIrRmSDgfq5ZKjfzsRdnPwclV2K1A1+N6X6kIhRM48GPRYs3OmW8eC3Tj+n6eqWkZlChP+xVG7183W6IgH3A== 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=RWuiIFYzgX8BGsY6JCcUV2BeiDDZsOZxsw3flCyiHRk=; b=c2G6PPfOT1BBcvu79loSTkmNODwYKmRE2PB3x0/C2nw7LxoKWd7WjdHvW1gkSSYllQ31CbaAGg6qZNwXhTkeD+GShPp+fHWMyVVXlp66/V47RQNA3wqiY9TUxVF5ee3YiC7f82wSBJLjnfR7msRGbw3aswPOUwyICM8mPJsd7qzX9BBmr/74f0L7TQsAfRc7ZriO0eRMYyHRRK4SZmaJeebT9sZ9PRDzeRIL54NZsZjNUKy741vFApugVWXhQ+4UUBYOHlQdMHWxf9vJQ4P4pn18WLSvPxpYrYEiB8LSlxCLGIg8GqNoZH0ZRpNd3OIIeGt5BpXa5ZbM7SGMaJV3gg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RWuiIFYzgX8BGsY6JCcUV2BeiDDZsOZxsw3flCyiHRk=; b=NRpXr6d5WueT5uG+61XLIC/Y/NvULozqdpR4I5ESmnpJdK00WIRG9/AvGo3k0wXTcXBgkwPd4vy398W9eoZq1ToptKK14rBKxStMVKwfBQwiYDi76QEQtNbxFaTcTxuOcFw4R5Nw7uyNXdEei727M9k7SVFBZe8nk57+k+1GspU= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 494e1082-e134-45c2-0d59-08d84077f229 x-ms-exchange-crosstenant-originalarrivaltime: 14 Aug 2020 17:31:57.9468 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: FilnmGLwH9ub4g22dQnrlqld7TIVCiJ1HxjrRkbxZ9SsPJcHGIeN01koQOWxLbrVxblNyEHwMJ7yCDA5Nh0azUAwNEEghhrx0AbMXo/fzJw= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4225 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_362B140917A14B44AEA7A13837290B9Bcomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHed733fYqLZ6m5mGW1bQ0MXXe0Cjrgx/8IvghiAKdC19UNC/T LDVqVsaYaeYl0eYlW4KzXJq0ULEUDS+Z2pTKtLyXGkUJSpha754Ffvv9/+d/OOc8PCwteSCQ svFJ6ZwqSZkoE9oy0Spd8ZG6/kCFT+OsX9DWQKPwJArT639TEeis7bEYLjE+g1N5h0Tbxs23 jQtS3r1Cl9YmXlNq1NKJtMiGBewPujKNSItsWQnupmC+fBYRcZ2Cqrsr1soEgrHiXzQRvQjy 6n/SfL8E6yn4thBCCjMINJU6SotYVog94dnTE3zGHrvAw0kTxbMddgNjR7+I+J4w3HuLJuwF Cw0llgyDD8KS5gvDsxiHQI+5z+IjvBvW+h9ZmMaOMD5XTZEbMOjbh2jCDrA4uyngV3DA3rD0 KZRfDWEtgiXtS8T7gI/CemkGie+Ft9V51qcIh/zqDSGJeEDO/QBiJ4DpxbB10iFYmR+1TnIG Q/40Q3gPTL03CflRgNtoyJ9pp4hQM3Dt66KIiD8CqHjcLSITXGGzK7MQySu2nUP4HPRs3RZU WM7fBX3lc0zFvw4aHwZjqzeJHICSvGkRYXfI1VVaOQxWi3TM9kwNYg1oZ3Cgl1zu7yUPCPLy lfs2I8vXqRp9jsxlYV0Is0i2Q+x5L1AhESgz0jLPdyFgaZm9mDb7KSTiGGVmFqdKVqguJHJp XciJZWSO4sjIwSgJjlWmcwkcl8Kp/lcp1kaqRlVhA7nLzPKk9sNwDmqp80kpXK82ro4kGyP2 DdZTdzpa2/IbY6UJOrNDbcOTjlNFdlm7socufm/KiSj4+EZTO1jwozTVWZoeOtl55cZyc9TN YLXBoD+T7TTimpsa7jaOBSP705XHx6JrOPnqVcNG0+fLLib305Tr1NCcKqs5uFfGpMUp5R60 Kk35F7Pxm7A2AwAA X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-14_12:2020-08-14, 2020-08-14 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Add] ADD September Interim sessions 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: Fri, 14 Aug 2020 17:32:34 -0000 --_000_362B140917A14B44AEA7A13837290B9Bcomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQUREDQoNClRoZSBoaWdoZXN0IHBpY2tlZCBkb29kbGUgcG9sbCBjaG9pY2UgZm9yIHRoZSBT ZXB0ZW1iZXIgSW50ZXJpbSBzZXNzaW9ucyB3YXMuOg0KDQpTZXNzaW9uIDE6ICAgVGh1cnNkYXkg U2VwdCAxMCBAIDE6MDAtMzozMHBtIEdNVA0KU2Vzc2lvbiAyOiAgIFR1ZXNkYXkgU2VwdCAxNSBA IDE6MDAtMzozMHBtIEdNVA0KDQoNClJlZ2lzdHJhdGlvbjoNCi0tLS0tLS0tLS0tLS0tLS0tDQog ICBOTyByZWdpc3RyYXRpb24gaXMgbmVlZGVkIGZvciB0aGUgQUREIFNlcHRlbWJlciBJbnRlcmlt IG1lZXRpbmdzLiBBdHRlbmRhbmNlIGlzIGZyZWUuDQoNCg0KUmVjb3JkaW5nczoNCi0tLS0tLS0t LS0tLS0tLS0NCiAgQm90aCBzZXNzaW9ucyB3aWxsIGJlIHJlY29yZGVkIGFuZCBtYWRlIGF2YWls YWJsZSBmb3IgdGhvc2Ugd2hvIGNhbuKAmXQgYXR0ZW5kLg0KDQoNCkFnZW5kYToNCi0tLS0tLS0t LS0tDQogICBUaGVzZSBzZXNzaW9ucyB3aWxsIGJlIHN0cnVjdHVyZWQgdG8gcGVybWl0IGEgaGln aCBhbW91bnQgb2YgZGlzY3Vzc2lvbi4NCg0KICAgRGV0YWlsZWQgYWdlbmRhIHRvIGZvbGxvdyBi dXQgd2lsbCBiZSBoZWF2aWx5IGluZmx1ZW5jZWQgYnkgd2hhdCBpcyBnZXR0aW5nIG9uLWxpc3Qg ZGlzY3Vzc2lvbiAodGhhdOKAmXMgYSBub24tc3VidGxlIGhpbnQgb24gaG93IHRvIGluZmx1ZW5j ZSB0aGUgYWdlbmRhKS4NCg0KDQpDYWxlbmRhciBJbnZpdGU6DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQogICAgIENhbGVuZGFyIGludml0ZXMgZm9yIFNlc3Npb24gMSBhbmQgU2Vzc2lvbiAyIGhh dmUgYmVlbiBzZW50IHRvIHRoZSBBREQgbWFpbGluZyBsaXN0LCBidXQgZm9yIGFueW9uZSB3aG8g bmVlZHMgaXQgdGhlIG1lZXRpbmcgaW5mbyBmb3IgYm90aCBzZXNzaW9ucyBhbHNvIGFwcGVhcnMg YmVsb3cuDQoNCg0KDQpSZWdhcmRzDQogICAgQUREIENoYWlycyAtIEdsZW5uIERlZW4gJiBEYXZp ZCBMYXdyZW5jZQ0KDQoNCg0KTWVldGluZyBJbmZvOg0KPT09PT09PT09PT0NCg0KTm90ZTogQm90 aCBzZXNzaW9ucyBoYXZlIHRoZSBzYW1lIHBhc3N3b3JkLg0KDQoNClNlc3Npb24gMTogSUVURiBB REQgU2VwdCBJbnRlcmltDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNClRodXJzZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMjANCg0KMTowMCBwbSB8IChVVEMr MDA6MDApIEF6b3JlcyB8IDIgaHJzIDMwIG1pbnMNCk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29k ZSk6IDE3MSAyODkgODg1MQ0KTWVldGluZyBwYXNzd29yZDogMkpBcG11WnM4UjgNCg0KV2hlbiBp dCdzIHRpbWUsIGpvaW4gdGhlIG1lZXRpbmcuDQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/TVRJRD1tMDFjMjlhOWY5NzdiYjk2NzJhMzE1M2M5ZDg1MWUyYzMNCkFkZCB0byBDYWxl bmRhcg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTFjMjI1NDYyNjNk ZGRlMGFkNGNkMWE5Y2QzNzQ3NDU1DQoNClRBUCBUTyBKT0lOIEZST00gQSBNT0JJTEUgREVWSUNF IChBVFRFTkRFRVMgT05MWSkNCisxLTY1MC00NzktMzIwOCwsMTcxMjg5ODg1MSMjIHRlbDolMkIx LTY1MC00NzktMzIwOCwsKjAxKjE3MTI4OTg4NTElMjMlMjMqMDEqIENhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSkNCg0KSk9JTiBCWSBQSE9ORQ0KMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0 b2xsIG51bWJlciAoVVMvQ2FuYWRhKQ0KR2xvYmFsIGNhbGwtaW4gbnVtYmVycw0KaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tNzg4ODBiNTJlNjQzNWMy ZjEwM2VhOWNlYTFhNjZlNDMNCg0KSk9JTiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FU SU9ODQpEaWFsIHNpcDoxNzEyODk4ODUxQGlldGYud2ViZXguY29tDQpZb3UgY2FuIGFsc28gZGlh bCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuDQpKb2luIHVzaW5n IE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3MNCkRpYWwgc2lw OjE3MTI4OTg4NTEuaWV0ZkBseW5jLndlYmV4LmNvbQ0KDQoNCg0KDQpTZXNzaW9uIDI6IElFVEYg QUREIFdHIFNlcHQgSW50ZXJpbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpUdWVzZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMjANCg0KMTowMCBw bSB8IChVVEMrMDA6MDApIEF6b3JlcyB8IDIgaHJzIDMwIG1pbnMNCk1lZXRpbmcgbnVtYmVyIChh Y2Nlc3MgY29kZSk6IDE3MSA0NjQgNjk0MQ0KTWVldGluZyBwYXNzd29yZDogMkpBcG11WnM4UjgN Cg0KVEFQIFRPIEpPSU4gRlJPTSBBIE1PQklMRSBERVZJQ0UgKEFUVEVOREVFUyBPTkxZKQ0KKzEt NjUwLTQ3OS0zMjA4LCwxNzE0NjQ2OTQxIyMgdGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcx NDY0Njk0MSUyMyUyMyowMSogQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKQ0KDQpKT0lO IEJZIFBIT05FDQoxLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEp DQpHbG9iYWwgY2FsbC1pbiBudW1iZXJzDQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xv YmFsY2FsbGluLnBocD9NVElEPW00Y2QwYjFiZDlmMzNhZDFiZGFmNGI0ZmE5MGI2MmIyZQ0KDQpK T0lOIEZST00gQSBWSURFTyBTWVNURU0gT1IgQVBQTElDQVRJT04NCkRpYWwgc2lwOjE3MTQ2NDY5 NDFAaWV0Zi53ZWJleC5jb20NCllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50 ZXIgeW91ciBtZWV0aW5nIG51bWJlci4NCkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWlj cm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzcw0KRGlhbCBzaXA6MTcxNDY0Njk0MS5pZXRmQGx5bmMu d2ViZXguY29tDQoNCg0KDQoNCg== --_000_362B140917A14B44AEA7A13837290B9Bcomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCWNvbG9yOndp bmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SGkg QUREPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRoZSBoaWdoZXN0IHBpY2tlZCBkb29k bGUgcG9sbCBjaG9pY2UgZm9yIHRoZSBTZXB0ZW1iZXIgSW50ZXJpbSBzZXNzaW9ucyB3YXMuOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5TZXNzaW9uIDE6Jm5ic3A7Jm5ic3A7IFRodXJz ZGF5IFNlcHQgMTAgQCAxOjAwLTM6MzBwbSBHTVQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpIZWx2ZXRpY2EiPlNlc3Npb24gMjombmJzcDsmbmJzcDsgVHVlc2RheSBTZXB0IDE1IEAgMTow MC0zOjMwcG0gR01UPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+UmVnaXN0cmF0aW9uOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyBOTyByZWdpc3RyYXRp b24gaXMgbmVlZGVkIGZvciB0aGUgQUREIFNlcHRlbWJlciBJbnRlcmltIG1lZXRpbmdzLiBBdHRl bmRhbmNlIGlzIGZyZWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+UmVjb3JkaW5nczo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPi0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwO0JvdGggc2Vzc2lvbnMg d2lsbCBiZSByZWNvcmRlZCBhbmQgbWFkZSBhdmFpbGFibGUgZm9yIHRob3NlIHdobyBjYW7igJl0 IGF0dGVuZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5BZ2VuZGE6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhIj4tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7IFRoZXNlIHNlc3Npb25zIHdpbGwgYmUgc3RydWN0 dXJlZCB0byBwZXJtaXQgYSBoaWdoIGFtb3VudCBvZiBkaXNjdXNzaW9uLiZuYnNwOw0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyBEZXRhaWxlZCBhZ2VuZGEgdG8g Zm9sbG93IGJ1dCB3aWxsIGJlIGhlYXZpbHkgaW5mbHVlbmNlZCBieSB3aGF0IGlzIGdldHRpbmcg b24tbGlzdCBkaXNjdXNzaW9uICh0aGF04oCZcyBhIG5vbi1zdWJ0bGUgaGludCBvbiBob3cgdG8g aW5mbHVlbmNlIHRoZSBhZ2VuZGEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkNhbGVuZGFyIEludml0 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBDYWxlbmRhciBpbnZpdGVzIGZvciBTZXNzaW9uIDEgYW5kIFNlc3Np b24gMiBoYXZlIGJlZW4gc2VudCB0byB0aGUgQUREIG1haWxpbmcgbGlzdCwgYnV0IGZvciBhbnlv bmUgd2hvIG5lZWRzIGl0IHRoZSBtZWV0aW5nIGluZm8gZm9yIGJvdGggc2Vzc2lvbnMgYWxzbyBh cHBlYXJzIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFERCBDaGFpcnMgLSBHbGVubiBEZWVu ICZhbXA7IERhdmlkIExhd3JlbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5NZWV0aW5nIEluZm86PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj49PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6SGVsdmV0aWNhIj5Ob3RlOiBCb3RoIHNlc3Npb25zIGhhdmUgdGhlIHNhbWUgcGFzc3dvcmQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TZXNzaW9uIDE6IElFVEYgQUREIFNl cHQgSW50ZXJpbQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PlRodXJzZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMjANCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MTowMCBwbSB8IChVVEMmIzQzOzAwOjAw KSBBem9yZXMgfCAyIGhycyAzMCBtaW5zDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMTcx IDI4OSA4ODUxDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+TWVldGluZyBwYXNzd29yZDogMkpBcG11WnM4UjgNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+V2hlbiBpdCdzIHRpbWUs IGpvaW4gdGhlIG1lZXRpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bTAxYzI5YTlmOTc3YmI5NjcyYTMxNTNjOWQ4NTFlMmMzIj48c3BhbiBzdHlsZT0i Y29sb3I6IzM5ODNDNCI+aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTAx YzI5YTlmOTc3YmI5NjcyYTMxNTNjOWQ4NTFlMmMzPC9zcGFuPjwvYT4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5BZGQgdG8gQ2FsZW5kYXIN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMWMyMjU0NjI2 M2RkZGUwYWQ0Y2QxYTljZDM3NDc0NTUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzk4M0M0Ij5odHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMWMyMjU0NjI2M2RkZGUwYWQ0Y2Qx YTljZDM3NDc0NTU8L3NwYW4+PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UQVAgVE8gSk9JTiBGUk9NIEEgTU9CSUxFIERFVklD RSAoQVRURU5ERUVTIE9OTFkpDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+JiM0MzsxLTY1MC00NzktMzIwOCwsMTcxMjg5ODg1MSMjIHRlbDol MkIxLTY1MC00NzktMzIwOCwsKjAxKjE3MTI4OTg4NTElMjMlMjMqMDEqIENhbGwtaW4gdG9sbCBu dW1iZXIgKFVTL0NhbmFkYSkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Sk9JTiBCWSBQSE9ORQ0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4g dG9sbCBudW1iZXIgKFVTL0NhbmFkYSkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5HbG9iYWwgY2FsbC1pbiBudW1iZXJzDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tNzg4ODBiNTJl NjQzNWMyZjEwM2VhOWNlYTFhNjZlNDMiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzk4M0M0Ij5odHRw czovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW03ODg4MGI1MmU2 NDM1YzJmMTAzZWE5Y2VhMWE2NmU0Mzwvc3Bhbj48L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkpPSU4gRlJPTSBBIFZJREVPIFNZ U1RFTSBPUiBBUFBMSUNBVElPTg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkRpYWwgc2lwOjE3MTI4OTg4NTFAaWV0Zi53ZWJleC5jb20NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Zb3Ug Y2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Sm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNz DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ RGlhbCBzaXA6MTcxMjg5ODg1MS5pZXRmQGx5bmMud2ViZXguY29tDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPlNlc3Npb24gMjogSUVURiBBREQgV0cgU2VwdCBJbnRlcmltDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VHVlc2RheSwgU2VwdGVtYmVy IDE1LCAyMDIwDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4xOjAwIHBtIHwg KFVUQyYjNDM7MDA6MDApIEF6b3JlcyB8IDIgaHJzIDMwIG1pbnMNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1l ZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDE3MSA0NjQgNjk0MQ0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ TWVldGluZyBwYXNzd29yZDogMkpBcG11WnM4Ujg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KVEFQIFRPIEpPSU4gRlJPTSBBIE1PQklM RSBERVZJQ0UgKEFUVEVOREVFUyBPTkxZKSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+JiM0MzsxLTY1MC00NzktMzIwOCwsMTcxNDY0Njk0MSMj IHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE3MTQ2NDY5NDElMjMlMjMqMDEqIENhbGwtaW4g dG9sbCBudW1iZXIgKFVTL0NhbmFkYSkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Sk9JTiBCWSBQSE9ORQ0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjEtNjUwLTQ3OS0zMjA4IENh bGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5HbG9iYWwgY2FsbC1pbiBudW1iZXJzDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGEgaHJl Zj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tNGNk MGIxYmQ5ZjMzYWQxYmRhZjRiNGZhOTBiNjJiMmUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzk4M0M0 Ij5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW00Y2Qw YjFiZDlmMzNhZDFiZGFmNGI0ZmE5MGI2MmIyZTwvc3Bhbj48L2E+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkpPSU4gRlJPTSBBIFZJ REVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkRpYWwgc2lwOjE3MTQ2NDY5NDFAaWV0Zi53ZWJleC5j b20NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBu dW1iZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Sm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1 c2luZXNzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+RGlhbCBzaXA6MTcxNDY0Njk0MS5pZXRmQGx5bmMud2ViZXguY29tDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_362B140917A14B44AEA7A13837290B9Bcomcastcom_-- From nobody Fri Aug 14 11:44:11 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 421423A10BD; Fri, 14 Aug 2020 11:44:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: add@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159743064499.17030.11699443654372854059@ietfa.amsl.com> Date: Fri, 14 Aug 2020 11:44:05 -0700 Archived-At: Subject: [Add] Adaptive DNS Discovery (add) WG Virtual Meeting: 2020-09-10 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, 14 Aug 2020 18:44:05 -0000 The Adaptive DNS Discovery (add) WG will hold a virtual interim meeting on 2020-09-10 from 13:00 to 15:30 UTC. Agenda: Registration: ----------------- NO registration is needed for the ADD September Interim meetings. Attendance is free. Recordings: ---------------- Both sessions will be recorded and made available for those who can’t attend. Agenda: ----------- These sessions will be structured to permit a high amount of discussion. Detailed agenda to follow but will be heavily influenced by what is getting on-list discussion (that’s a non-subtle hint on how to influence the agenda). Calendar Invite: ---------------------- Calendar invites for Session 1 and Session 2 have been sent to the ADD mailing list, but for anyone who needs it the meeting info for both sessions also appears below. Regards ADD Chairs - Glenn Deen & David Lawrence Meeting Info: =========== Note: Both sessions have the same password. Session 1: IETF ADD Sept Interim ---------------------------------------------- Thursday, September 10, 2020 1:00 pm | (UTC+00:00) Azores | 2 hrs 30 mins Meeting number (access code): 171 289 8851 Meeting password: 2JApmuZs8R8 When it's time, join the meeting. https://ietf.webex.com/ietf/j.php?MTID=m01c29a9f977bb9672a3153c9d851e2c3 Add to Calendar https://ietf.webex.com/ietf/j.php?MTID=m1c22546263ddde0ad4cd1a9cd3747455 TAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY) +1-650-479-3208,,1712898851## tel:%2B1-650-479-3208,,*01*1712898851%23%23*01* Call-in toll number (US/Canada) JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Global call-in numbers https://ietf.webex.com/ietf/globalcallin.php?MTID=m78880b52e6435c2f103ea9cea1a66e43 JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial sip:1712898851@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for Business Dial sip:1712898851.ietf@lync.webex.com Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m01c29a9f977bb9672a3153c9d851e2c3 From nobody Fri Aug 14 11:44:31 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 BE5E63A124C; Fri, 14 Aug 2020 11:44:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: add@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159743066267.14554.1261587573085501785@ietfa.amsl.com> Date: Fri, 14 Aug 2020 11:44:22 -0700 Archived-At: Subject: [Add] Adaptive DNS Discovery (add) WG Virtual Meeting: 2020-09-15 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, 14 Aug 2020 18:44:30 -0000 The Adaptive DNS Discovery (add) WG will hold a virtual interim meeting on 2020-09-15 from 13:00 to 15:30 UTC. Agenda: Registration: ----------------- NO registration is needed for the ADD September Interim meetings. Attendance is free. Recordings: ---------------- Both sessions will be recorded and made available for those who can’t attend. Agenda: ----------- These sessions will be structured to permit a high amount of discussion. Detailed agenda to follow but will be heavily influenced by what is getting on-list discussion (that’s a non-subtle hint on how to influence the agenda). Calendar Invite: ---------------------- Calendar invites for Session 1 and Session 2 have been sent to the ADD mailing list, but for anyone who needs it the meeting info for both sessions also appears below. Regards ADD Chairs - Glenn Deen & David Lawrence Meeting Info: =========== Session 2: IETF ADD WG Sept Interim ---------------------------------------------------- Tuesday, September 15, 2020 1:00 pm | (UTC+00:00) Azores | 2 hrs 30 mins Meeting number (access code): 171 464 6941 Meeting password: 2JApmuZs8R8 When it's time, join the meeting. https://ietf.webex.com/ietf/j.php?MTID=mcf596c63ad88ee204beada8351a0f015 TAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY) +1-650-479-3208,,1714646941## tel:%2B1-650-479-3208,,*01*1714646941%23%23*01* Call-in toll number (US/Canada) JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Global call-in numbers https://ietf.webex.com/ietf/globalcallin.php?MTID=m4cd0b1bd9f33ad1bdaf4b4fa90b62b2e JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial sip:1714646941@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for Business Dial sip:1714646941.ietf@lync.webex.com Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mcf596c63ad88ee204beada8351a0f015 From nobody Sun Aug 16 13:05:43 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 15B7D3A10F5 for ; Sun, 16 Aug 2020 13:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=andreasschulze.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 WDSg49wiojqY for ; Sun, 16 Aug 2020 13:05:38 -0700 (PDT) Received: from mta.somaf.de (mta.somaf.de [IPv6:2001:470:77b3:103::25]) (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 3CB403A10F2 for ; Sun, 16 Aug 2020 13:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=202008-766672F4; t=1597608333; x=1602608333; bh=M0z8WKbewiXyIz6Dnh+OLzXcmkN/QMaN53Gl8HxK5GI=; h=Subject:To:From:Message-ID:Date:Content-Type:MIME-Version: Content-Transfer-Encoding:autocrypt:cc:content-transfer-encoding: content-type:date:from:in-reply-to:message-id:mime-version:openpgp: references:subject:to; b=PcDLmk55F692IZsth1f3oLDjGmiuh4oN9uS3BYnp8cfC9WBq2XBbeWcg3BlS4yVYw c1Bl3jc9p7dEesLMF7f6zgAmdOBEVVGB/8nwTJxxBQru9++ajcvgQga645aZd26XWT LerK6OLW/u8Q8vhQL/TFTRZfIvr4gXewnTWZ3iGFOL02ubmkvyPLb2fdE8aYfUdSxa j5Gvd3xobOBiPP5U3Fx3Fa3VkMY/AFRi4AyqDWRmuCLYto/jD3DmWtu/6KIaXXlgGe jiayM6nkgQqzmerD9TVcnTZaUZtLTCFQs842enFNJZJgh6G7QZ6BK2ZY7S6L17N9UC Q4/hPMzPEzWiQ== To: add@ietf.org From: "A. Schulze" Message-ID: <20200816220533.Horde.zGsmWPQbCdLY26mV0-0fcZm@andreasschulze.de> Date: Sun, 16 Aug 2020 22:05:33 +0200 Content-Type: multipart/mixed; boundary="=_53DUOaBgbKgTm68yOQgTjbQ" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Add] Session 1: IETF ADD Sept Interim 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, 16 Aug 2020 20:05:41 -0000 This message is in MIME format. --=_53DUOaBgbKgTm68yOQgTjbQ Content-Type: multipart/alternative; boundary="=_g7wTtsIapDNrL4nJj3IJKjP" Content-Transfer-Encoding: 8bit This message is in MIME format. --=_g7wTtsIapDNrL4nJj3IJKjP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Session 1: IETF ADD Sept Interim (am 10.09.2020 um 15:00:00) Position: https://ietf.webex.com/ietf/j.php?MTID=m01c29a9f977bb9672a3153c9d851e2c3 Teilnehmer: add@ietf.org, sca@andreasschulze.de Hier ist eine detailliertere Beschreibung des Termins: JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m01c29a9f977bb9672a3153c9d851e2c3 Meeting number (access code): 171 289 8851 Meeting password: 2JApmuZs8R8 TAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY) +1-650-479-3208,,1712898851## tel:%2B1-650-479-3208,,*01*1712898851%23%23*01* Call-in toll number (US/Canada) JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Global call-in numbers https://ietf.webex.com/ietf/globalcallin.php?MTID=m78880b52e6435c2f103ea9cea1a66e43 JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial sip:1712898851@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for Business Dial sip:1712898851.ietf@lync.webex.com Can't join the meeting? https://collaborationhelp.cisco.com/article/WBX000029055 IMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. Im Anhang befindet sich eine iCalendar-Datei mit mehr Informationen zu diesem Termin. Wenn Ihr E-Mail-Programm iTip-Anfragen beherrscht, können Sie diese Datei dazu benutzen, Ihre lokale Version des Termins zu aktualisieren. Falls Ihr E-Mail-Programm keine iTip-Anfragen unterstützt, können Sie einen der folgenden Links verwenden, um den Termin zu bestätigen oder abzulehnen. Um den Termin zu bestätigen: https://andreasschulze.de/horde/kronolith/attend.php?c=6nMga1DQzt7lKHJxru8KrTr&e=kQA0K7thtZk-ETzB_2JqXXa&u=add%40ietf.org&a=accept Um den Termin unter Vorbehalt zu bestätigen: https://andreasschulze.de/horde/kronolith/attend.php?c=6nMga1DQzt7lKHJxru8KrTr&e=kQA0K7thtZk-ETzB_2JqXXa&u=add%40ietf.org&a=tentative Um den Termin abzulehnen: https://andreasschulze.de/horde/kronolith/attend.php?c=6nMga1DQzt7lKHJxru8KrTr&e=kQA0K7thtZk-ETzB_2JqXXa&u=add%40ietf.org&a=decline --=_g7wTtsIapDNrL4nJj3IJKjP Content-Type: multipart/related; boundary="=_cxypyTTN9N64leZfi3i1chm"; start="Zyp3mvs6SqFErbyiXGQlIWK@horde-full.somaf.de" Content-Transfer-Encoding: 8bit This message is in MIME format. --=_cxypyTTN9N64leZfi3i1chm Content-Type: text/html; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-ID:

A. Schulze möchte Sie auf "Session 1: IETF ADD Sept Interim" aufmerksam machen.

Session 1: IETF ADD Sept Interim
Beginn:   10.09.2020 15:00:00
Ende:   10.09.2020 17:30:00
Position:   https://ietf.webex.com/ietf/j.php?MTID=m01c29a9f977bb9672a3153c9d851e2c3
Teilnehmer:   add@ietf.org
sca@andreasschulze.de
Beschreibung:   JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=m01c29a9f977bb9672a3153c9d851e2c3
Meeting number (access code): 171 289 8851

Meeting password: 2JApmuZs8R8



TAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY)
+1-650-479-3208,,1712898851## tel:%2B1-650-479-3208,,*01*1712898851%23%23*01* Call-in toll number (US/Canada)


JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)

Global call-in numbers
https://ietf.webex.com/ietf/globalcallin.php?MTID=m78880b52e6435c2f103ea9cea1a66e43


JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:1712898851@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.


Join using Microsoft Lync or Microsoft Skype for Business
Dial sip:1712898851.ietf@lync.webex.com





Can't join the meeting?
https://collaborationhelp.cisco.com/article/WBX000029055


IMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.

Im Anhang befindet sich eine iCalendar-Datei mit mehr Informationen zu diesem Termin. Wenn Ihr E-Mail-Programm iTip-Anfragen beherrscht, können Sie diese Datei dazu benutzen, Ihre lokale Version des Termins zu aktualisieren.

Falls Ihr E-Mail-Programm keine iTip-Anfragen unterstützt, können Sie die folgenden Links verwenden, um den Termin: zu bestätigen, unter Vorbehalt zu bestätigen oder abzulehnen.

--=_cxypyTTN9N64leZfi3i1chm Content-Type: image/png Content-Disposition: attachment Content-Transfer-Encoding: base64 Content-ID: <85upWCSEHBv7UxllAwRw89p@horde-full.somaf.de> iVBORw0KGgoAAAANSUhEUgAAAG4AAACACAYAAADqFVwJAAAJcklEQVR4AezRVXLbUByF8S6uZuiW KrAkCyxLKmyjdSHMDHs6OZnJQyYTMAiurv4PvwV8830CoKWf91++PtK1T8uoH3djg/DEkHE18P12 bBBeMGScwr7djE3CG0wZp+K065FF+IAl4xSSXY0swpIsGaeA9HJkE1Zky7gKpRfDCWFNExlXgeR8 6BA25Mi4Es3PBg4hJ46MK0F8OnAJOXNlXIHik4FHKIgn4wowO+57hIJ5Mi5H0VF/SijJVMblIDzs +4SS+TJuA+FBLyBUJJBxawj2ewGhYoGMW4G/1w0Jighl3BL83W5EUEwk494x3elGBEVFMu4V3nZn RlDcTMY94251YkJNxDKO3P/tmFAzcaPHOf/ac0JNzRs5bvK3nRBqLmnUOPtPKyFoImnEOHvRSgma SbUeZy1aGUFTmZbjzN+fM4LmMq3Gmb8e2K2z3qjKOI7j55yqQS/Fe6O+AKMx0tKy0LKUAoKIiCbE GHBhgbJQylIKvAIUu7SUltJaWkqX+hKMMb4BjYRrNd62k5B2ZsLP77mrJ51nljOP8zA9F5+LtsnJ 8/99b7q1C1oluqoi3M3Zpm5olel+bsPdmGny0Q2tUt3wn6tw16ebfPRADltCGw4jC1nQA9/9cLg+ 1eijF3LYb3h72Zs/QxayoBe+0+E6HzX66IUc9Qy3sGaFt3+KLGRBL3wnw12bbPTRBznqT2zNc8Mh ZCEL+uA7Fa7j4RYf/ZCjJvFqgbccQhayoB++E+E6Jrb46IccNI/DJdz0CbKQBf3wKxru6vhmH3cg B/2E12PcdhAZyII78CsS7sqDzT4GIMcsoR2BJA9xbjyIDGTBAPz/NdyVsc0+BiDH/I534gaL3Pox MpAFA/Dth8PlHzb5uAs55BluY02cSIabDyADWXAXvtVwl0Y3+RiEHPIXtlsIFr39ADKQBYPwrYRr H9kUYBByyBTWWgwW3eAjZCALBhGUNVz7/Y0BhiBHLOBza5HMW+xHBrJgCEFZwl0c3hhgCHLEz3jD eiTzJvuRhiwYQhArXNu9DQHuQQ5I4zIiR1UG7/gQaciCewhKCtc2tCHAMOSAP/CuA8GiG+1DGrJg GEFR4S4MbggwDDmgCy87FCy61T6kIQuGERQU7vzdhgD3oQr7G82OBotuthdpyIL7CIzhzg00BBiB KmwGax0PFt1uL9KQBSMIVgx37k59gBGoghbwhbuBzHj7B1iCLBhB8J9wZ/vrA4xCFfQL3nQ/kBk3 7MESZMEoiEe4M331NRiFKiSDDtRI8qoBt+zBEmTBKGq81t76ztbe9Y/zeApZ8BjvSfKqDXftxhJU pKd5e9DM23X25hhq8jyiASmojHrwivsRYsXbVWS8FBpM3wxbYcxrOXNDGIMx3ume9fVYgGL6By3V HCyy2y4sQnmkYIwWNsIY+KH1uiA8gDHeqe66eixAJZrDa9UaybBbCxahHFIwR6MNHkCQt7O1U8uM wxyvq249FqAipHCk+iMZd2vBYo5tjNHCJhiHIPDL052KGIcx3snva+uwABXgV7y1WoNFdtuJRQhC CuZotMA4tAx/OHVNUZiAMd6J27V1mIdyyKATy76TYI9mLCIFczQaYAKK8ppPdSiHCbxg+vDx72pr MQ9FPMH7Saicu+2AMVq4PSaglXjNJ6/K4CHM8b5dV4t5CEIfYvybnwg3x0MoF2/HiSvKYxLGeMdu rVuHJ9idDB9PuDUmIZNouDjx/GR469EAeNuPX1aBHsEQL45EuC0eQYXwth+7pCJMoczxEuGmmIIK 5W071q4iTaFM8RLhlpiCiuFt+6ZdJZhGzHiJcENMQ8Xytn59USWaxotJgNKE22EaKgUfaFMMMygy XiLcDDNQifjIVxcU0ywKjJcIt8IsFIfX9OV5lcEs8sRLhBthForLazp6XmUyhxzxEuE2mIPKwWs8 ek5lNIdIvES4CeagcvEaj5xVmf2Il5Jg/5JLN0lNBGEYx99ioTcSEAS8guKHUUlAJJlkJnAUrxJA vF3/fbpq9j2L/sj0LH67tyr9nyci/lvITojJ3t88kMBOJj+e/wayE2JLNZz3KK8mPtqjkIJdXN+T 0JNMbjzf3LeTil0stiT2JJMZz7f2zaRk54uODJ6l+vF8Y99KanY+78jkWV5XO5ra+kZysLOrloz+ SnXj+aa+jVz0oxsye5FqxvMtfRM52dnPNQW8yOjH8w19C7nZux8NhfyT0Y7n3943UEA/XNnxDkY4 2kHJ0Tw7/b6ioAfAxsi/XSjFTmdLCrkHbMx8g1CCnczuKGALWA18i5CbnXy7I7MOsJr4JiEne/v1 NxkFR9PNTP7smdmAd3dCLvrBWzJpw/G3jThhzzhpBry/FXKw4y+/yGATitbNWpywp5ysB3RshNTs +PMNiQVH081aGInweGoWUko5nCseWf7P6JINd/TpmgScNKE43bTCSLUD+hpxQmx2dLkgMifB0XTT CiPXDuhsxAkx2eHlnIicrEIxuumESnQDelfihFjs8OOcSJwsQxG66YTKdAO6l+KEGOzNhysicBIc TTdboVLbAf3L/+3d21IaQRSF4XkejTnnPiYxiaCIMWchhCjeIoggIvLidq/8UJWqaNDdMxMVpS++ qgFW7+na6wGAh/JiWFU5eezZl642oXuuGbCHPXgoj+TFZkU5eDSsy5JpQnPCLI9MAx7KiCHlijLy MEsjsw/Nmf2AvTTgoSyS5+VtZeCxa12OTAuaU62A/ezCQylxeOO7UvLYsS5FpgXNObs8dgkPpcDB 0jel4GGWRqYNTUTtgH3twEOhkmelrwrk8cu6BJk2dE5kljfeLTwUgAPrPNgc6tbLyRxA0VQHAfur w0GW5OnaFxkczNLIdMxZUSdgj3U4Yw7B4mddweGn9TIyHShIZJfHzuGgyyRPip90CYea9RIyh1Aq 0WHAXmtw0BQECjz8y8EsjUwXyiTqBuy3BgddlDxe/agLHH5YQ8l0oVwis7xxF3AQAPDDlv7iULWH bfWg/CL0AvZdhYP+SB69/yAIDmZpZHrQfxWZ5ZGpwkHgi3ebgkPFOkzmCLoW0VHA/itwmHw4Cyyt D12rqB9Y3lny8G152wqT6UM3IjLLG3eWmKGVjWPoRkXHuf55f2mlNIBuRTTIVNzSm9IAulXRIFVx D16vn0AzIToJKY7S1obQTImGVxa3+Ko4hGZSNJxa3OJy4RSaadHpueIWlgsj6E6IRpPiFl6ujqA7 JRr9BtId2UJuUp+KAAAAAElFTkSuQmCC --=_cxypyTTN9N64leZfi3i1chm-- --=_g7wTtsIapDNrL4nJj3IJKjP Content-Type: text/calendar; charset=utf-8; name=event-invitation.ics; METHOD=REQUEST Content-Disposition: attachment; filename=event-invitation.ics BEGIN:VCALENDAR VERSION:2.0 METHOD:REQUEST X-WR-CALNAME:Kalender von A. Schulze PRODID:-//The Horde Project//Horde iCalendar Library//EN BEGIN:VEVENT DTSTART:20200910T130000Z DTEND:20200910T153000Z DTSTAMP:20200816T200532Z UID:4999737e-9ccf-49cc-89f0-3698dd2249e1 SUMMARY:Session 1: IETF ADD Sept Interim ORGANIZER;CN=A. Schulze:mailto:sca@andreasschulze.de DESCRIPTION:JOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=m01c29a9f977bb9672a3153c9 d851e2c3\nMeeting number (access code): 171 289 8851\n\nMeeting password: 2JApmuZs8R8\n\n\n\nTAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY)\n+1-650-479-3208\,\,1712898851## tel:%2B1-650-479-3208\,\,*01*1712898851%23%23*01* Call-in toll number (US/Canada)\n\n\nJOIN BY PHONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal call-in numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=m78880b52e6435 c2f103ea9cea1a66e43\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:1712898851@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting number.\n\n\nJoin using Microsoft Lync or Microsoft Skype for Business\nDial sip:1712898851.ietf@lync.webex.com\n\n\n\n\n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/WBX000029055\n\n\nI MPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded\, which may be discoverable in a legal matter. By joining this session\, you automatically consent to such recordings. If you do not consent to being recorded\, discuss your concerns with the host or do not join the session. LOCATION:https://ietf.webex.com/ietf/j.php?MTID=m01c29a9f977bb9672a3153c9d8 51e2c3 CLASS:PUBLIC STATUS:CONFIRMED TRANSP:OPAQUE ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=add@ietf.o rg:mailto:add@ietf.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED:mailto:sca@andreasschulze.d e END:VEVENT END:VCALENDAR --=_g7wTtsIapDNrL4nJj3IJKjP-- --=_53DUOaBgbKgTm68yOQgTjbQ Content-Type: application/ics; name=event-invitation.ics; METHOD=REQUEST Content-Disposition: attachment; filename=event-invitation.ics Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpWRVJTSU9OOjIuMA0KTUVUSE9EOlJFUVVFU1QNClgtV1ItQ0FMTkFN RTpLYWxlbmRlciB2b24gQS4gU2NodWx6ZQ0KUFJPRElEOi0vL1RoZSBIb3JkZSBQcm9qZWN0Ly9I b3JkZSBpQ2FsZW5kYXIgTGlicmFyeS8vRU4NCkJFR0lOOlZFVkVOVA0KRFRTVEFSVDoyMDIwMDkx MFQxMzAwMDBaDQpEVEVORDoyMDIwMDkxMFQxNTMwMDBaDQpEVFNUQU1QOjIwMjAwODE2VDIwMDUz MloNClVJRDo0OTk5NzM3ZS05Y2NmLTQ5Y2MtODlmMC0zNjk4ZGQyMjQ5ZTENClNVTU1BUlk6U2Vz c2lvbiAxOiBJRVRGIEFERCBTZXB0IEludGVyaW0NCk9SR0FOSVpFUjtDTj1BLiBTY2h1bHplOm1h aWx0bzpzY2FAYW5kcmVhc3NjaHVsemUuZGUNCkRFU0NSSVBUSU9OOkpPSU4gV0VCRVgNCiAgTUVF VElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTAxYzI5YTlmOTc3 YmI5NjcyYTMxNTNjOQ0KIGQ4NTFlMmMzXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOg0K ICAxNzEgMjg5IDg4NTFcblxuTWVldGluZyBwYXNzd29yZDoNCiAgMkpBcG11WnM4UjhcblxuXG5c blRBUCBUTyBKT0lOIEZST00gQSBNT0JJTEUgREVWSUNFIChBVFRFTkRFRVMNCiAgT05MWSlcbisx LTY1MC00NzktMzIwOFwsXCwxNzEyODk4ODUxIyMNCiAgdGVsOiUyQjEtNjUwLTQ3OS0zMjA4XCxc LCowMSoxNzEyODk4ODUxJTIzJTIzKjAxKiBDYWxsLWluIHRvbGwgbnVtYmVyDQogIChVUy9DYW5h ZGEpXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJl cg0KICAoVVMvQ2FuYWRhKVxuXG5HbG9iYWwgY2FsbC1pbg0KICBudW1iZXJzXG5odHRwczovL2ll dGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW03ODg4MGI1MmU2NDM1DQog YzJmMTAzZWE5Y2VhMWE2NmU0M1xuXG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZU1RFTSBPUiBBUFBM SUNBVElPTlxuRGlhbA0KICBzaXA6MTcxMjg5ODg1MUBpZXRmLndlYmV4LmNvbVxuWW91IGNhbiBh bHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlcg0KICB5b3VyIG1lZXRpbmcgbnVtYmVyLlxu XG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlDQogIGZvciBC dXNpbmVzc1xuRGlhbCBzaXA6MTcxMjg5ODg1MS5pZXRmQGx5bmMud2ViZXguY29tXG5cblxuXG5c blxuQ2FuJ3QNCiAgam9pbiB0aGUNCiAgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhl bHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSQ0KIE1QT1JUQU5UIE5PVElD RToNCiAgUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFu ZCBvdGhlciBpbmZvcm1hdGlvbg0KICBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNv cmRlZFwsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYQ0KICBsZWdhbCBtYXR0ZXIuIEJ5 IGpvaW5pbmcgdGhpcyBzZXNzaW9uXCwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0bw0KICBz dWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZFws IGRpc2N1c3MgeW91cg0KICBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRo ZSBzZXNzaW9uLg0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01U SUQ9bTAxYzI5YTlmOTc3YmI5NjcyYTMxNTNjOWQ4DQogNTFlMmMzDQpDTEFTUzpQVUJMSUMNClNU QVRVUzpDT05GSVJNRUQNClRSQU5TUDpPUEFRVUUNCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQ QU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049YWRkQGlldGYubw0KIHJnOm1h aWx0bzphZGRAaWV0Zi5vcmcNCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFU PUFDQ0VQVEVEOm1haWx0bzpzY2FAYW5kcmVhc3NjaHVsemUuZA0KIGUNCkVORDpWRVZFTlQNCkVO RDpWQ0FMRU5EQVINCg== --=_53DUOaBgbKgTm68yOQgTjbQ-- From nobody Sun Aug 16 13:05: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 4F55C3A10FF for ; Sun, 16 Aug 2020 13:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=andreasschulze.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 334Qx7S7TNUY for ; Sun, 16 Aug 2020 13:05:44 -0700 (PDT) Received: from mta.somaf.de (mta.somaf.de [IPv6:2001:470:77b3:103::25]) (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 868A03A10F7 for ; Sun, 16 Aug 2020 13:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=202008-766672F4; t=1597608342; x=1602608342; bh=Z498sl8F7iHSVEESiXcTv8f7rtzGuLuH6Qkri3LQNes=; h=Subject:To:From:Message-ID:Date:Content-Type:MIME-Version: Content-Transfer-Encoding:autocrypt:cc:content-transfer-encoding: content-type:date:from:in-reply-to:message-id:mime-version:openpgp: references:subject:to; b=o43qsS1qnnrUuQFah5/IHZSydtu69T6SJIp7drvLvfhQR4XKlrIKSxY0C30zPo5U/ G/DXW74XzuVGlGOcjBSp3fwV0czGh5nEI+o3urpQtwqcDuQpmdA4XmmGEPwYmGkjEA scIJRbhIvtFkDxU0E0e9RhQfwJQEWX8Q4GRVYXTqh+IsBYlnXR2pB5usb3DD7ZUT7M JHnw6KDPofI38EF9bB3VH+ZBKDtNklGZoOPhbBCQGzYoHpJ0kUm/oPpId2cgllM6+n d2kg7oQo9AeKZvxESVk6OBX/1rDI2JKRfnkjTRpk2Z6VShl4kfB7liCzvHFl6O7rza obYnHpIczMLYg== To: add@ietf.org From: "A. Schulze" Message-ID: <20200816220542.Horde.eB0S-5Aa9qjurL13Q733nM2@andreasschulze.de> Date: Sun, 16 Aug 2020 22:05:42 +0200 Content-Type: multipart/mixed; boundary="=__tT940OW7JFHfNav6WBoCwa" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Add] Session 2: IETF ADD WG Sept Interim 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, 16 Aug 2020 20:05:55 -0000 This message is in MIME format. --=__tT940OW7JFHfNav6WBoCwa Content-Type: multipart/alternative; boundary="=_boNzVscQLYp-OhfuVA24Orz" Content-Transfer-Encoding: 8bit This message is in MIME format. --=_boNzVscQLYp-OhfuVA24Orz Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Session 2: IETF ADD WG Sept Interim (am 15.09.2020 um 15:00:00) Position: https://ietf.webex.com/ietf/j.php?MTID=mb3ac4cf581d9bd7263aa1d64c23c30d6 Teilnehmer: add@ietf.org, sca@andreasschulze.de Hier ist eine detailliertere Beschreibung des Termins: JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=mb3ac4cf581d9bd7263aa1d64c23c30d6 Meeting number (access code): 171 464 6941 Meeting password: 2JApmuZs8R8 TAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY) +1-650-479-3208,,1714646941## tel:%2B1-650-479-3208,,*01*1714646941%23%23*01* Call-in toll number (US/Canada) JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Global call-in numbers https://ietf.webex.com/ietf/globalcallin.php?MTID=m4cd0b1bd9f33ad1bdaf4b4fa90b62b2e JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial sip:1714646941@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for Business Dial sip:1714646941.ietf@lync.webex.com Can't join the meeting? https://collaborationhelp.cisco.com/article/WBX000029055 IMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. Im Anhang befindet sich eine iCalendar-Datei mit mehr Informationen zu diesem Termin. Wenn Ihr E-Mail-Programm iTip-Anfragen beherrscht, können Sie diese Datei dazu benutzen, Ihre lokale Version des Termins zu aktualisieren. Falls Ihr E-Mail-Programm keine iTip-Anfragen unterstützt, können Sie einen der folgenden Links verwenden, um den Termin zu bestätigen oder abzulehnen. Um den Termin zu bestätigen: https://andreasschulze.de/horde/kronolith/attend.php?c=6nMga1DQzt7lKHJxru8KrTr&e=X1Kupp0h7-cWNql5GH4bAs1&u=add%40ietf.org&a=accept Um den Termin unter Vorbehalt zu bestätigen: https://andreasschulze.de/horde/kronolith/attend.php?c=6nMga1DQzt7lKHJxru8KrTr&e=X1Kupp0h7-cWNql5GH4bAs1&u=add%40ietf.org&a=tentative Um den Termin abzulehnen: https://andreasschulze.de/horde/kronolith/attend.php?c=6nMga1DQzt7lKHJxru8KrTr&e=X1Kupp0h7-cWNql5GH4bAs1&u=add%40ietf.org&a=decline --=_boNzVscQLYp-OhfuVA24Orz Content-Type: multipart/related; boundary="=_481Ig5WrQFZPWNH1cl78JXY"; start="bIgCuEi6yoie2Ck_c50cB4x@horde-full.somaf.de" Content-Transfer-Encoding: 8bit This message is in MIME format. --=_481Ig5WrQFZPWNH1cl78JXY Content-Type: text/html; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-ID:

A. Schulze möchte Sie auf "Session 2: IETF ADD WG Sept Interim" aufmerksam machen.

Session 2: IETF ADD WG Sept Interim
Beginn:   15.09.2020 15:00:00
Ende:   15.09.2020 17:30:00
Position:   https://ietf.webex.com/ietf/j.php?MTID=mb3ac4cf581d9bd7263aa1d64c23c30d6
Teilnehmer:   add@ietf.org
sca@andreasschulze.de
Beschreibung:   JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=mb3ac4cf581d9bd7263aa1d64c23c30d6
Meeting number (access code): 171 464 6941

Meeting password: 2JApmuZs8R8



TAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY)
+1-650-479-3208,,1714646941## tel:%2B1-650-479-3208,,*01*1714646941%23%23*01* Call-in toll number (US/Canada)


JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)

Global call-in numbers
https://ietf.webex.com/ietf/globalcallin.php?MTID=m4cd0b1bd9f33ad1bdaf4b4fa90b62b2e


JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:1714646941@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.


Join using Microsoft Lync or Microsoft Skype for Business
Dial sip:1714646941.ietf@lync.webex.com





Can't join the meeting?
https://collaborationhelp.cisco.com/article/WBX000029055


IMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.

Im Anhang befindet sich eine iCalendar-Datei mit mehr Informationen zu diesem Termin. Wenn Ihr E-Mail-Programm iTip-Anfragen beherrscht, können Sie diese Datei dazu benutzen, Ihre lokale Version des Termins zu aktualisieren.

Falls Ihr E-Mail-Programm keine iTip-Anfragen unterstützt, können Sie die folgenden Links verwenden, um den Termin: zu bestätigen, unter Vorbehalt zu bestätigen oder abzulehnen.

--=_481Ig5WrQFZPWNH1cl78JXY Content-Type: image/png Content-Disposition: attachment Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAG4AAACACAYAAADqFVwJAAAJcklEQVR4AezRVXLbUByF8S6uZuiW KrAkCyxLKmyjdSHMDHs6OZnJQyYTMAiurv4PvwV8830CoKWf91++PtK1T8uoH3djg/DEkHE18P12 bBBeMGScwr7djE3CG0wZp+K065FF+IAl4xSSXY0swpIsGaeA9HJkE1Zky7gKpRfDCWFNExlXgeR8 6BA25Mi4Es3PBg4hJ46MK0F8OnAJOXNlXIHik4FHKIgn4wowO+57hIJ5Mi5H0VF/SijJVMblIDzs +4SS+TJuA+FBLyBUJJBxawj2ewGhYoGMW4G/1w0Jighl3BL83W5EUEwk494x3elGBEVFMu4V3nZn RlDcTMY94251YkJNxDKO3P/tmFAzcaPHOf/ac0JNzRs5bvK3nRBqLmnUOPtPKyFoImnEOHvRSgma SbUeZy1aGUFTmZbjzN+fM4LmMq3Gmb8e2K2z3qjKOI7j55yqQS/Fe6O+AKMx0tKy0LKUAoKIiCbE GHBhgbJQylIKvAIUu7SUltJaWkqX+hKMMb4BjYRrNd62k5B2ZsLP77mrJ51nljOP8zA9F5+LtsnJ 8/99b7q1C1oluqoi3M3Zpm5olel+bsPdmGny0Q2tUt3wn6tw16ebfPRADltCGw4jC1nQA9/9cLg+ 1eijF3LYb3h72Zs/QxayoBe+0+E6HzX66IUc9Qy3sGaFt3+KLGRBL3wnw12bbPTRBznqT2zNc8Mh ZCEL+uA7Fa7j4RYf/ZCjJvFqgbccQhayoB++E+E6Jrb46IccNI/DJdz0CbKQBf3wKxru6vhmH3cg B/2E12PcdhAZyII78CsS7sqDzT4GIMcsoR2BJA9xbjyIDGTBAPz/NdyVsc0+BiDH/I534gaL3Pox MpAFA/Dth8PlHzb5uAs55BluY02cSIabDyADWXAXvtVwl0Y3+RiEHPIXtlsIFr39ADKQBYPwrYRr H9kUYBByyBTWWgwW3eAjZCALBhGUNVz7/Y0BhiBHLOBza5HMW+xHBrJgCEFZwl0c3hhgCHLEz3jD eiTzJvuRhiwYQhArXNu9DQHuQQ5I4zIiR1UG7/gQaciCewhKCtc2tCHAMOSAP/CuA8GiG+1DGrJg GEFR4S4MbggwDDmgCy87FCy61T6kIQuGERQU7vzdhgD3oQr7G82OBotuthdpyIL7CIzhzg00BBiB KmwGax0PFt1uL9KQBSMIVgx37k59gBGoghbwhbuBzHj7B1iCLBhB8J9wZ/vrA4xCFfQL3nQ/kBk3 7MESZMEoiEe4M331NRiFKiSDDtRI8qoBt+zBEmTBKGq81t76ztbe9Y/zeApZ8BjvSfKqDXftxhJU pKd5e9DM23X25hhq8jyiASmojHrwivsRYsXbVWS8FBpM3wxbYcxrOXNDGIMx3ume9fVYgGL6By3V HCyy2y4sQnmkYIwWNsIY+KH1uiA8gDHeqe66eixAJZrDa9UaybBbCxahHFIwR6MNHkCQt7O1U8uM wxyvq249FqAipHCk+iMZd2vBYo5tjNHCJhiHIPDL052KGIcx3snva+uwABXgV7y1WoNFdtuJRQhC CuZotMA4tAx/OHVNUZiAMd6J27V1mIdyyKATy76TYI9mLCIFczQaYAKK8ppPdSiHCbxg+vDx72pr MQ9FPMH7Saicu+2AMVq4PSaglXjNJ6/K4CHM8b5dV4t5CEIfYvybnwg3x0MoF2/HiSvKYxLGeMdu rVuHJ9idDB9PuDUmIZNouDjx/GR469EAeNuPX1aBHsEQL45EuC0eQYXwth+7pCJMoczxEuGmmIIK 5W071q4iTaFM8RLhlpiCiuFt+6ZdJZhGzHiJcENMQ8Xytn59USWaxotJgNKE22EaKgUfaFMMMygy XiLcDDNQifjIVxcU0ywKjJcIt8IsFIfX9OV5lcEs8sRLhBthForLazp6XmUyhxzxEuE2mIPKwWs8 ek5lNIdIvES4CeagcvEaj5xVmf2Il5Jg/5JLN0lNBGEYx99ioTcSEAS8guKHUUlAJJlkJnAUrxJA vF3/fbpq9j2L/sj0LH67tyr9nyci/lvITojJ3t88kMBOJj+e/wayE2JLNZz3KK8mPtqjkIJdXN+T 0JNMbjzf3LeTil0stiT2JJMZz7f2zaRk54uODJ6l+vF8Y99KanY+78jkWV5XO5ra+kZysLOrloz+ SnXj+aa+jVz0oxsye5FqxvMtfRM52dnPNQW8yOjH8w19C7nZux8NhfyT0Y7n3943UEA/XNnxDkY4 2kHJ0Tw7/b6ioAfAxsi/XSjFTmdLCrkHbMx8g1CCnczuKGALWA18i5CbnXy7I7MOsJr4JiEne/v1 NxkFR9PNTP7smdmAd3dCLvrBWzJpw/G3jThhzzhpBry/FXKw4y+/yGATitbNWpywp5ysB3RshNTs +PMNiQVH081aGInweGoWUko5nCseWf7P6JINd/TpmgScNKE43bTCSLUD+hpxQmx2dLkgMifB0XTT CiPXDuhsxAkx2eHlnIicrEIxuumESnQDelfihFjs8OOcSJwsQxG66YTKdAO6l+KEGOzNhysicBIc TTdboVLbAf3L/+3d21IaQRSF4XkejTnnPiYxiaCIMWchhCjeIoggIvLidq/8UJWqaNDdMxMVpS++ qgFW7+na6wGAh/JiWFU5eezZl642oXuuGbCHPXgoj+TFZkU5eDSsy5JpQnPCLI9MAx7KiCHlijLy MEsjsw/Nmf2AvTTgoSyS5+VtZeCxa12OTAuaU62A/ezCQylxeOO7UvLYsS5FpgXNObs8dgkPpcDB 0jel4GGWRqYNTUTtgH3twEOhkmelrwrk8cu6BJk2dE5kljfeLTwUgAPrPNgc6tbLyRxA0VQHAfur w0GW5OnaFxkczNLIdMxZUSdgj3U4Yw7B4mddweGn9TIyHShIZJfHzuGgyyRPip90CYea9RIyh1Aq 0WHAXmtw0BQECjz8y8EsjUwXyiTqBuy3BgddlDxe/agLHH5YQ8l0oVwis7xxF3AQAPDDlv7iULWH bfWg/CL0AvZdhYP+SB69/yAIDmZpZHrQfxWZ5ZGpwkHgi3ebgkPFOkzmCLoW0VHA/itwmHw4Cyyt D12rqB9Y3lny8G152wqT6UM3IjLLG3eWmKGVjWPoRkXHuf55f2mlNIBuRTTIVNzSm9IAulXRIFVx D16vn0AzIToJKY7S1obQTImGVxa3+Ko4hGZSNJxa3OJy4RSaadHpueIWlgsj6E6IRpPiFl6ujqA7 JRr9BtId2UJuUp+KAAAAAElFTkSuQmCC --=_481Ig5WrQFZPWNH1cl78JXY-- --=_boNzVscQLYp-OhfuVA24Orz Content-Type: text/calendar; charset=utf-8; name=event-invitation.ics; METHOD=REQUEST Content-Disposition: attachment; filename=event-invitation.ics BEGIN:VCALENDAR VERSION:2.0 METHOD:REQUEST X-WR-CALNAME:Kalender von A. Schulze PRODID:-//The Horde Project//Horde iCalendar Library//EN BEGIN:VEVENT DTSTART:20200915T130000Z DTEND:20200915T153000Z DTSTAMP:20200816T200541Z UID:d3f28ee9-1f66-4d46-9c2e-cd05fa9d951d SUMMARY:Session 2: IETF ADD WG Sept Interim ORGANIZER;CN=A. Schulze:mailto:sca@andreasschulze.de DESCRIPTION:JOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=mb3ac4cf581d9bd7263aa1d64 c23c30d6\nMeeting number (access code): 171 464 6941\n\nMeeting password: 2JApmuZs8R8\n\n\n\nTAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY)\n+1-650-479-3208\,\,1714646941## tel:%2B1-650-479-3208\,\,*01*1714646941%23%23*01* Call-in toll number (US/Canada)\n\n\nJOIN BY PHONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal call-in numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=m4cd0b1bd9f33a d1bdaf4b4fa90b62b2e\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:1714646941@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting number.\n\n\nJoin using Microsoft Lync or Microsoft Skype for Business\nDial sip:1714646941.ietf@lync.webex.com\n\n\n\n\n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/WBX000029055\n\n\nI MPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded\, which may be discoverable in a legal matter. By joining this session\, you automatically consent to such recordings. If you do not consent to being recorded\, discuss your concerns with the host or do not join the session. LOCATION:https://ietf.webex.com/ietf/j.php?MTID=mb3ac4cf581d9bd7263aa1d64c2 3c30d6 CLASS:PUBLIC STATUS:CONFIRMED TRANSP:OPAQUE ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=add@ietf.o rg:mailto:add@ietf.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED:mailto:sca@andreasschulze.d e END:VEVENT END:VCALENDAR --=_boNzVscQLYp-OhfuVA24Orz-- --=__tT940OW7JFHfNav6WBoCwa Content-Type: application/ics; name=event-invitation.ics; METHOD=REQUEST Content-Disposition: attachment; filename=event-invitation.ics Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpWRVJTSU9OOjIuMA0KTUVUSE9EOlJFUVVFU1QNClgtV1ItQ0FMTkFN RTpLYWxlbmRlciB2b24gQS4gU2NodWx6ZQ0KUFJPRElEOi0vL1RoZSBIb3JkZSBQcm9qZWN0Ly9I b3JkZSBpQ2FsZW5kYXIgTGlicmFyeS8vRU4NCkJFR0lOOlZFVkVOVA0KRFRTVEFSVDoyMDIwMDkx NVQxMzAwMDBaDQpEVEVORDoyMDIwMDkxNVQxNTMwMDBaDQpEVFNUQU1QOjIwMjAwODE2VDIwMDU0 MVoNClVJRDpkM2YyOGVlOS0xZjY2LTRkNDYtOWMyZS1jZDA1ZmE5ZDk1MWQNClNVTU1BUlk6U2Vz c2lvbiAyOiBJRVRGIEFERCBXRyBTZXB0IEludGVyaW0NCk9SR0FOSVpFUjtDTj1BLiBTY2h1bHpl Om1haWx0bzpzY2FAYW5kcmVhc3NjaHVsemUuZGUNCkRFU0NSSVBUSU9OOkpPSU4gV0VCRVgNCiAg TUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWIzYWM0Y2Y1 ODFkOWJkNzI2M2FhMWQ2NA0KIGMyM2MzMGQ2XG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUp Og0KICAxNzEgNDY0IDY5NDFcblxuTWVldGluZyBwYXNzd29yZDoNCiAgMkpBcG11WnM4Ujhcblxu XG5cblRBUCBUTyBKT0lOIEZST00gQSBNT0JJTEUgREVWSUNFIChBVFRFTkRFRVMNCiAgT05MWSlc bisxLTY1MC00NzktMzIwOFwsXCwxNzE0NjQ2OTQxIyMNCiAgdGVsOiUyQjEtNjUwLTQ3OS0zMjA4 XCxcLCowMSoxNzE0NjQ2OTQxJTIzJTIzKjAxKiBDYWxsLWluIHRvbGwgbnVtYmVyDQogIChVUy9D YW5hZGEpXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51 bWJlcg0KICAoVVMvQ2FuYWRhKVxuXG5HbG9iYWwgY2FsbC1pbg0KICBudW1iZXJzXG5odHRwczov L2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW00Y2QwYjFiZDlmMzNh DQogZDFiZGFmNGI0ZmE5MGI2MmIyZVxuXG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZU1RFTSBPUiBB UFBMSUNBVElPTlxuRGlhbA0KICBzaXA6MTcxNDY0Njk0MUBpZXRmLndlYmV4LmNvbVxuWW91IGNh biBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlcg0KICB5b3VyIG1lZXRpbmcgbnVtYmVy LlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlDQogIGZv ciBCdXNpbmVzc1xuRGlhbCBzaXA6MTcxNDY0Njk0MS5pZXRmQGx5bmMud2ViZXguY29tXG5cblxu XG5cblxuQ2FuJ3QNCiAgam9pbiB0aGUNCiAgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlv bmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSQ0KIE1QT1JUQU5UIE5P VElDRToNCiAgUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlv IGFuZCBvdGhlciBpbmZvcm1hdGlvbg0KICBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSBy ZWNvcmRlZFwsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYQ0KICBsZWdhbCBtYXR0ZXIu IEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uXCwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0bw0K ICBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRl ZFwsIGRpc2N1c3MgeW91cg0KICBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2lu IHRoZSBzZXNzaW9uLg0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw P01USUQ9bWIzYWM0Y2Y1ODFkOWJkNzI2M2FhMWQ2NGMyDQogM2MzMGQ2DQpDTEFTUzpQVUJMSUMN ClNUQVRVUzpDT05GSVJNRUQNClRSQU5TUDpPUEFRVUUNCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJ Q0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049YWRkQGlldGYubw0KIHJn Om1haWx0bzphZGRAaWV0Zi5vcmcNCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRT VEFUPUFDQ0VQVEVEOm1haWx0bzpzY2FAYW5kcmVhc3NjaHVsemUuZA0KIGUNCkVORDpWRVZFTlQN CkVORDpWQ0FMRU5EQVINCg== --=__tT940OW7JFHfNav6WBoCwa-- From nobody Sun Aug 16 13:08:30 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 9FC1B3A0B99 for ; Sun, 16 Aug 2020 13:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=andreasschulze.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 1lRk3kgLFscD for ; Sun, 16 Aug 2020 13:08:26 -0700 (PDT) Received: from mta.somaf.de (mta.somaf.de [IPv6:2001:470:77b3:103::25]) (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 66B9C3A0B95 for ; Sun, 16 Aug 2020 13:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=202008-766672F4; t=1597608504; x=1602608504; bh=V1sfw4yzGS9JcZpAWOEmn5ajd1MxZy9wtiDKn1y+mV0=; h=Subject:From:To:References:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding:autocrypt:cc: content-transfer-encoding:content-type:date:from:in-reply-to: message-id:mime-version:openpgp:references:subject:to; b=c5Ab5aIWAmHT9tjxImfy0v0fhUYOkYdFG5fSEZy0uAE2GG2tGqdiLbk7JuE7t6elo jh72SEPQyz3WV++EUTDRnE/Hi4jTiU5+dE8aRYa5/bL96aqnqJ0ajoBEEuqvXJYSCw KAyvpYEi7VViOQMCY7Kp6VGqqLkWFYow9RpfFzR7L/GNZzbJP5nFdhCvfXkl+/7/7F eUEc5IEOzGueY0CdFtRgpEjkpfqgzkukEkyvXAiPXkKPMb03qYwHdvMrk/v/cjHdw1 zNIwFGNFITErIxP32Zj5pUtmNiaxhEjDmCb3AyhC9FOEDuZ1cI8ccFXNS82ZI54rtT w5gNd8WmNqUfQ== From: "A. Schulze" To: add@ietf.org References: <20200816220542.Horde.eB0S-5Aa9qjurL13Q733nM2@andreasschulze.de> Message-ID: <15a17694-53ed-ed6c-52c7-da18ab8db792@andreasschulze.de> Date: Sun, 16 Aug 2020 22:07:29 +0200 MIME-Version: 1.0 In-Reply-To: <20200816220542.Horde.eB0S-5Aa9qjurL13Q733nM2@andreasschulze.de> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Add] Session 2: IETF ADD WG Sept Interim 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, 16 Aug 2020 20:08:29 -0000 Am 16.08.20 um 22:05 schrieb A. Schulze: Sorry, somehow Thunderbird misunderstood "accept and don't send an answer" :-/ From nobody Mon Aug 17 00:09:26 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 8814F3A13D3 for ; Mon, 17 Aug 2020 00:09:24 -0700 (PDT) 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 l38TQSawbYoH for ; Mon, 17 Aug 2020 00:09:22 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 D78EC3A13D2 for ; Mon, 17 Aug 2020 00:09:22 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id f12so6053273ils.6 for ; Mon, 17 Aug 2020 00:09:22 -0700 (PDT) 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; bh=Rf0VJfIFYVLCEbZQTB9zMEQ+BMeFXY/VBqJQ+F7rhQ0=; b=nSW7GwlQ7+YmtWWbezHwz+iiZC/4eDgqmy+6WUl/88CuFBPfBn+ZyGhpdvWDZoOuiy niJr99YLgqqxjkuqrsrVVuo2HLparLFMxEPdZzpxilmq/biJjKHO5iO694kGkevR7OoL QYUfQOjVMaw09dZlBX+44y5Fv3ZxMX3uoTtl0Bg6mVk3cbCk53f3Bs81DWLUvY94TFMJ Tk3Vxc0ZF8kLXjU9zaAOXydWmkOo7ol7oM7YlyuJrV+HUQM4fDibelmRvmhFjDoZXeaG 9iJUKbhoNKUYWMlMONfla2Wf1UjgseqmjpGHc/mIPswQQwBTjtAPQ4fEZofWRbiWpoiO yZhg== 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; bh=Rf0VJfIFYVLCEbZQTB9zMEQ+BMeFXY/VBqJQ+F7rhQ0=; b=d0MCSaShnQMJdtRTMyO6VMBv5muZOUpgOnXuxcYYVY/KRYJPLEDb/5dahZyiWMeQP/ zfEP8muhEK/5oreLMMpMGH2z5xsHgQEindxkjZXQPNUZunNA21QlO+tbmGMcEx7+7Jox QtdnVlkvaplDLJpTLXFaxZ5zLuRUatu1/yyxy3FznQAAm5VS8lSLBAYc6tg4VvGH11Mg MuTt9wf8bCve7tT6/4+dlS2+APoSskWvSvwzkU0EkLn00YYwFMJ2KStq6tjg7JLh//tc mPi0zFtAi3u9cXz1i/xEp4YBo8AbRSnSUXkM4oSoSRC9suHupAorRvPuVVfGDB5mVy8g ZqWg== X-Gm-Message-State: AOAM530SbTrFHYuoZRnsO4DE3slPk7Fs21d9sdyu3nGon5eAtPMso5Bh D+gNcSv1lj1UUC18tvSFFZXsqO4m2JnSEm82C5JbwswYcXU= X-Google-Smtp-Source: ABdhPJxjO9xqGTv2kAGXksBqQCNoD27Fb/SrKKUuPZpRaoa3HF65hwfW4MJ5FPdT3mxKxqnwrGgK1c7Xpy0HjCV+WHk= X-Received: by 2002:a92:b70c:: with SMTP id k12mr12288984ili.214.1597648161868; Mon, 17 Aug 2020 00:09:21 -0700 (PDT) MIME-Version: 1.0 References: <159764549172.6667.2825227387264053045@ietfa.amsl.com> In-Reply-To: From: tirumal reddy Date: Mon, 17 Aug 2020 12:39:10 +0530 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000002a11ee05ad0d7343" Archived-At: Subject: Re: [Add] New Version Notification for draft-btw-add-home-08.txt 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, 17 Aug 2020 07:09:25 -0000 --0000000000002a11ee05ad0d7343 Content-Type: text/plain; charset="UTF-8" Hi all, This revision https://tools.ietf.org/html/draft-btw-add-home-08 addresses several comments from the WG. We also updated the security considerations section in the draft to discuss the threat models covered in https://tools.ietf.org/html/rfc3552 and possible mitigations for active attacks. Further comments and suggestions are welcome. Cheers, -Tiru -----Original Message----- From: internet-drafts@ietf.org Sent: Monday, August 17, 2020 11:55 AM To: Konda, Tirumaleswar Reddy ; Mohamed Boucadair ; Dan Wing ; Neil Cook ; Konda, Tirumaleswar Reddy Subject: New Version Notification for draft-btw-add-home-08.txt CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe. A new version of I-D, draft-btw-add-home-08.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-btw-add-home Revision: 08 Title: Encrypted DNS Discovery and Deployment Considerations for Home Networks Document date: 2020-08-16 Group: Individual Submission Pages: 29 URL: https://www.ietf.org/internet-drafts/draft-btw-add-home-08.txt Status: https://datatracker.ietf.org/doc/draft-btw-add-home/ Htmlized: https://tools.ietf.org/html/draft-btw-add-home-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-btw-add-home Diff: https://www.ietf.org/rfcdiff?url2=draft-btw-add-home-08 Abstract: This document discusses encrypted DNS (e.g., DoH, DoT, DoQ) deployment considerations for home networks. It particularly sketches the required steps to use of encrypted DNS capabilities provided by local networks. The document specifies new DHCP and Router Advertisement Options to convey a DNS Authentication Domain Name. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000002a11ee05ad0d7343 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

This revision=C2=A0https://tools.ietf.org/html/draft-btw= -add-home-08=C2=A0addresses several comments from the WG.=C2=A0
We also updated the security considerations section in the draf= t to discuss the threat models covered in https://tools.ietf.org/html/rfc3552 and possible mitigat= ions for active attacks.

Further comments and suggestions are welcom= e.

Cheers,
-Tiru

-----Original Message-----
From: interne= t-drafts@ietf.org <internet-drafts@ietf.org>
Sent: Monday, August 17, 2020 11:55 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; M= ohamed Boucadair <mohamed.boucadair@orange.com>; Dan Wing <dwing-ietf@fuggles.com&= gt;; Neil Cook <neil.cook@noware.co.uk>; Konda, Tirumaleswar Reddy <Tirumales= warReddy_Konda@McAfee.com>
Subject: New Version Notification for draft-btw-add-home-08.txt

CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe.


A new version of I-D, draft-btw-add-home-08.txt has been successfully submi= tted by Tirumaleswar Reddy and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-btw-add-home
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A008
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Encrypted DNS Discovery and Deploy= ment Considerations for Home Networks
Document date:=C2=A0 2020-08-16
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 29
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-btw-add-home-08.txt<= br> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/draft-btw-add-home/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.i= etf.org/html/draft-btw-add-home-08
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= datatracker.ietf.org/doc/html/draft-btw-add-home
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-btw-add-home-08

Abstract:
=C2=A0 =C2=A0This document discusses encrypted DNS (e.g., DoH, DoT, DoQ) =C2=A0 =C2=A0deployment considerations for home networks.=C2=A0 It particul= arly
=C2=A0 =C2=A0sketches the required steps to use of encrypted DNS capabiliti= es
=C2=A0 =C2=A0provided by local networks.

=C2=A0 =C2=A0The document specifies new DHCP and Router Advertisement Optio= ns to
=C2=A0 =C2=A0convey a DNS Authentication Domain Name.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--0000000000002a11ee05ad0d7343-- From nobody Mon Aug 17 09:40: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 26AA83A0D4D for ; Mon, 17 Aug 2020 09:40:10 -0700 (PDT) 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=comcast.com header.b=ugmyrFhr; dkim=pass (2048-bit key) header.d=comcast.com header.b=02HjDgI3; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=Aw22xxSL 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 8m6wWWAVcVXJ for ; Mon, 17 Aug 2020 09:40:08 -0700 (PDT) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.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 F375D3A0D42 for ; Mon, 17 Aug 2020 09:40:07 -0700 (PDT) Received: from pps.filterd (m0184890.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07HGOU4Z026467 for ; Mon, 17 Aug 2020 12:40:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : mime-version; s=20190412; bh=vWzann+78tnBMct1TucmiHjxsUmL0JzZqjCypysj/Eo=; b=ugmyrFhrf2MOB99bmdzsRPehriAxi1i6OBQi+rUmPAjfefH9TvG8tMlMeU+uCc8sIfuS LRlvAyi5oY1osOssY3ClzMnXWc8H6qXL5LZ378DEnOQ7dl5zaGX/W2eC+jSUoV3GPOrN HGNQtwDpFrDSrIIEtTXgTEbahkdqj7WhEvyuWJmZZ0KTrzBF5lPC6mi/jmUX7vFPq9Gq /xwxsI5xxoypueYlzm/mOVWtpJsFRvorbx2b0oDQHssVtri6BjBsCIpZlVYYSnjtKTVt GSxA8F685kGVYZL4Wt1p8bNt5SgwnKC/KsKjoN72p/CmrnuBgrhUme/Oq6VvyoJMA35X 6w== Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) by mx0b-00143702.pphosted.com with ESMTP id 32xbtf9h32-32 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 17 Aug 2020 12:40:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1597682406; x=2461596006; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vWzann+78tnBMct1TucmiHjxsUmL0JzZqjCypysj/Eo=; b=02HjDgI3hPS+8Bz+xRi81M009GiGRqmmpAmYgfq+MQtzGiZ/W3VGPNIdcxZ1qohR ascRAW3ZP3u2BJwlC6BXPfHg5ccoqoBYk3SNZhYuybgSw5U/oTLA3+7hQkaQmj6g tK5R6Ms2vMbgf1Kewclr05dVQqXHRKgpPk7KxoK4cjQmP/ExNaeCo3Tjltu3ulw7 T99je110z6Rmkt3Gmj+WQvTUGIbknq9yLk7uroWyMyIz2Gkugv8ccEvVUDve/6Z7 /2Qa+uY4CECGKNpHrAjIdhY/3E/BhmnN7WcfWoWAqmR68ZO3SLvycFUJi89BpYzp 0HpvgNhXnya6XBkPUXWRfQ==; X-AuditID: 44571fa7-417ff70000018e96-3c-5f3ab2e6fec8 Received: from PACDCEX50.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 29.87.36502.6E2BA3F5; Mon, 17 Aug 2020 12:40:06 -0400 (EDT) Received: from PACDCEX16.cable.comcast.com (24.40.1.139) by PACDCEX50.cable.comcast.com (24.40.2.149) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Aug 2020 12:40:06 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX16.cable.comcast.com (24.40.1.139) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 17 Aug 2020 12:40:06 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.170) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Aug 2020 12:40:01 -0400 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BYAPR11MB2918.namprd11.prod.outlook.com (2603:10b6:a03:92::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.22; Mon, 17 Aug 2020 16:39:59 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6%7]) with mapi id 15.20.3283.027; Mon, 17 Aug 2020 16:39:59 +0000 From: "Deen, Glenn" To: ADD Mailing list Thread-Topic: Draft-pp-add-resinfo Thread-Index: AQHWdLUMPJsi9gPnKEytUcy0M6rB/Q== Date: Mon, 17 Aug 2020 16:39:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:29ff:35a8:5b6f:9c14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f0d82a8-450b-458f-9375-08d842cc2e98 x-ms-traffictypediagnostic: BYAPR11MB2918: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BONmNuRhPJE7cDF9wmhRSdw9fMOcjdiQHMhJiWt5+b5RfimOEwm80NgDt7581LpQetf6OFUWDGjQ2qfWg59RB1ISFlRCMIp9uwoQ/gsD7h3CuhIT/QezTrV3yfK+im7pKjNgXSG/k8zPuevvN7Eqp4x9wagrL1qSZwuv9rBMRM6dGLiY6oqeFIVCBZXVzH/gWXMrpdCR1waEEaOzBbd2NtWnezzW74eo2pd7UezAirpuAj0XTsFUdNVDPfg8pr+k2+VPMWYM1WUxal/PH9M4ALLiaA2cuuPJN8XhMpX6z+S6leLV03d+x7EPu0XdG//PyM8Qhur2fBSPcsf1Jvi+37G9vH0uN6VqZcmXhkT1qPazqF11PbqYKKw0fr7AdM63KhFnG3UX55hV/V7oqZtT/A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(396003)(346002)(39860400002)(376002)(4743002)(316002)(36756003)(66446008)(166002)(186003)(71200400001)(966005)(66556008)(66476007)(66946007)(6486002)(33656002)(6506007)(3480700007)(64756008)(8676002)(2906002)(4744005)(2616005)(6512007)(5660300002)(8936002)(6916009)(76116006)(83380400001)(86362001)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Y1bBc1X3KMdGg9FlPjIhkWriEcFB9bMJ+T53gngPCo1C2/MOZzMXA6xLOv38GHS4V6c6HNXGLhWYJ/3PE+CPnOHCdv49Vvm7DqfSZyD4ljQkmZog2VYZPooDH+gykSHj+b86m2yfaWGmTc1C0ZEE8Ft0cypkBO6Z2QOAq7mbQ621LFmkV8TSSJhHwiyHnVNDLztYyY7Za2YRF9gIti7/1Kcxb1qundb/Ukvuj4qM8MbT7fTx+9hMRy82DA4Yf+AeYmfqu9UkBGMfkgHfuQCNqtZYx2XypncqCZh/44wIlV8Sc4V0/dh6/TWEzdgWrYRu/CuvCFmfArx1FSiL33SIfH8qY8VGWXYqJ8Rl7Rlss69OgdcIvWbjuKycESTED67O/Am+LxrD6efcD93gKo3MaIZ+QlDp2qLhD/YHvF0GCiFKx57XxWDxMzfEuMe4NvKUJJj/e4Sx3/7h08ccB1TLGwcuL4qPO+tiQxFObj+xZZqAF66I2FpLCIdKoegmlX9T/SeWg4O2XS8yNVblVDX61qdVINhUn1dzV5D0ygxaDm2pR1N/dqHxFAZbYLB+flntWJyNf8mmBJBQiNQz6fY804TBnTwsIXBEA3u1mAwDfke5UDHj1yeyoxKQ4Caac4nEkNXg6DODlAmxHjAkZCJi/QHQwdsKTRqOwZO7+omUPQ2UrVemlZTB//mXaENUpqRvPtZJPI8TCXW0dKphIf1Lpg== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CXLmDirqLVdKEmu0rSAFfoCEFh56z3uWkMk34vGiOrvrSxbhdFbIg4aqcJqPTMGxx0NhRS2hrkVGinuzS7FR9W3LSBlF1qCo11HBI1S4FJTYlyOEpntuZVrIoEGLBVeXlD3BOJ1Sb9FulKoFJ9+jqPgP2vXXpCr1aRjqgYrZ7wFgPVnxse2nwMZIqZA+RVga0NtTt2g6OGpqVw/7Q6agcsmaXvWgAH3MwSoA6ljqTUKbxhcq1tZ8NXAPL+gNpvOcJL+gRT2oLIFS0JY/kaSIIye8+7AmPPJDmRDt4IWqZGnFrzK3P+4rOfUFWBnIxgrjcs+iJF/kFyncXW96cjoQyw== 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=RoxbTKVMrc5wdHI0nbnRzDvtXhAzZblD25EYkMXKupg=; b=el/HAp1/Csbp0npaYLNhJoHFHUUIDSL48s87yAvOvVAsjXMFuNR4vQ4MQKfYhkgXc7apGYf8rTrJLe7DW6hCID+Bk5XlAMEEp3uaZaWErh1m/H+8qJgkmLJ1l5p57gAXsZVJMGDe0lT6JmgDGYHV/tqIeFYwqSuZsI5iJQlH8mMoDCckMEKSFveNKvKOzoPq7sIR2TfRoScE5DbDdKGu8+mg5NpAtytXSI0sSzY+XTSruCLlNuUnPSNwrIoe2fC0IY2+0JxY7oRnHruzWszuH/MLKGL6L8urNZ2oQ01hyga1KwdiLDaTXohIdE0QXtoDLQIVCZcLM5HgNTuWyKQK1w== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RoxbTKVMrc5wdHI0nbnRzDvtXhAzZblD25EYkMXKupg=; b=Aw22xxSLbP5Ze71WeKpqZyHFWkgHd2/oNq3ovGIqIC+RdEhQBkAqFW3WOySyBz0Qu3NSZNLcwbG4NLxna4mi9AFnBY0QPsTgwkfkYz7ZFKRUjusG65KNK7Cj7y++ve0fXlbq7SyB685GbdJ1CwxnoijMWpUbuLt2SUay1iOpGhk= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 3f0d82a8-450b-458f-9375-08d842cc2e98 x-ms-exchange-crosstenant-originalarrivaltime: 17 Aug 2020 16:39:59.4158 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: AMCKzkHNCdqhGJH2ndMq5knjj3WChBaALDqXEV59t2mIX/FMK0rgCTz3dGCyzuqm4WkPfIyFUE/YPZg5W1xfKQDHShkfbeK9icRTrRaokig= x-ms-exchange-transport-crosstenantheadersstamped: BYAPR11MB2918 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_B98873C429434D1BB751D7B3A6945323comcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA02SSUxTURSGve+9to9CzbWAnCCiVEBlaG1AqGjQBUYSY+rGEMdSwkMqo2WI sEKECAWUhRgoEiBWTRhaRWJlUlOgAi4wIkKMqMyV4EIJokRRHxcSdt9/7v+fIbksLa0ReLK6 1ExOn6pNlgnFTFSMzCt4piVCs694SKn6+8osPIKiTaZf1El0RnwonkvWZXN6RWSsONGYV4nS LcFXFpda6DxUEGRATizgUPg+YhAZkJiV4h4KnvcWUES0I3h737EmhhFUVOcLiLAj6OuuFBJx l4L+Hw6GbybFEwh6F3cbEMsKcRA8eXyYL7vhXXBvzErx7Iq9Yaq5mFqvzzpmRYTlMGTroPgo g/3ga+NqVIIjwfpniuYZ4a2wNNC0GqWxB7yfqqXICRhMnYM0YXf4Mrki4Nu4YwXMfYzit0TY gGDO8AIRTwRUzE8LCG+HN7Ula/UTMPluhuGzgANgwnSOYBIsvz5GHP4wOl+0NskbGsrGGcJe 8HnUKiTcQUNRm44fC/gnDYXd1QwRvwVQVNUlIk19YcWWU46Uxg3XEI6DviILMq5evwX6q6YY 4/8EjfeCpV1BLD5wq2RcRHgPFN6pWeNoaF4wo42eOsQ2IJcwlVwVLg9RypVh4S1o9dPsePAU WY2JNoRZJHORNNVHaKQCbXZGTooNAUvL3CRxfeEaqSRem5PL6dM0+qxkLsOGtrGMzENSPuy4 IMUXtZlcEselc/r1V4p18sxDDzdRKmPcWIr9Q1CX/4Gj7n7YrHopr/3UGWrqmZ9ojxkRtBbf jg3yyFM7j7cNmU+fmrZEr8SrZ3wipPlMyqWdBch8frDv6rXSb4H2y4osnWtB+6xaY29FB/cH Vp2VzdSrFzITFI8SbsZuXtaVlYQ4P4vMLbxeGlxxo3Eg7bhvnYzJSNQqA2h9hvYfSXoVPDAD AAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-17_13:2020-08-17, 2020-08-17 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Add] Draft-pp-add-resinfo 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, 17 Aug 2020 16:40:10 -0000 --_000_B98873C429434D1BB751D7B3A6945323comcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQURELA0KDQpUaGUgcmVzcG9uc2libGUgQURzIGFuZCBjby1jaGFpcnMgZm9yIHRoZSB2YXJp b3VzIEROUyBXR3MgbWV0IHJlY2VudGx5IHRvIHRhbGsgdGhyb3VnaCB3aGVyZSB2YXJpb3VzIGRy YWZ0cyBtYXkgZml0IGJldHRlciB0aGFuIHdoZXJlIHRoZXkgd2VyZSBvcmlnaW5hbGx5IGJlaW5n IGRpc2N1c3NlZCwgYW5kIHdlIHdhbnRlZCB0byBzdWdnZXN0IHRoYXQgdGhlIGRyYWZ0IERyYWZ0 LXBwLWFkZC1yZXNpbmZvIHdoaWNoIG9yaWdpbmFsbHkgd2FzIGJlaW5nIGRpc2N1c3NlZCBvbiB0 aGUgRFNOT1BTIGxpc3QgYmUgZGlzY3Vzc2VkIGhlcmUgb24gQUREIGFzIGl04oCZcyBhIGNsb3Nl ciBmaXQuICAgICAgIFRoaXMgaGFzIGFscmVhZHkgYmVlbiBoYXBwZW5pbmcgc29tZXdoYXQgYWxy ZWFkeSwgc28gdGhpcyBpcyBtb3N0bHkgYW4gYXR0ZW1wdCBhdCBjbGFyaWZpY2F0aW9uLg0KDQpU aGlzIGlzIG5vdCBhIFdHIGFkb3B0aW9uIG9mIHRoZSBkcmFmdCwganVzdCByZWNvZ25pemluZyB0 aGF0IHRoZSBBREQgbGlzdCB3b3VsZCBiZSB0aGUgYmVzdCBmaXQgZm9yIHRoZSBtYXRlcmlhbCBp biB0aGUgZHJhZnQuDQoNCklmIGFueW9uZSBvYmplY3RzIGZlZWwgZnJlZSB0byBzaGFyZSB5b3Vy IGNvbmNlcm5zLg0KDQpEcmFmdCBsaW5rOiAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1wcC1hZGQtcmVzaW5mbw0KDQoNCnJlZ2FyZHMNCkFERCBXRyBDaGFpcnMs IEdsZW5uIERlZW4gJiBEYXZpZCBMYXdyZW5jZQ0KDQo= --_000_B98873C429434D1BB751D7B3A6945323comcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <5D7EECA4792C484A97C2318D5061B977@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCWNvbG9yOndp bmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIEFERCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJlc3BvbnNpYmxlIEFEcyBhbmQg Y28tY2hhaXJzIGZvciB0aGUgdmFyaW91cyBETlMgV0dzIG1ldCByZWNlbnRseSB0byB0YWxrIHRo cm91Z2ggd2hlcmUgdmFyaW91cyBkcmFmdHMgbWF5IGZpdCBiZXR0ZXIgdGhhbiB3aGVyZSB0aGV5 IHdlcmUgb3JpZ2luYWxseSBiZWluZyBkaXNjdXNzZWQsIGFuZCB3ZSB3YW50ZWQgdG8gc3VnZ2Vz dCB0aGF0IHRoZSBkcmFmdCBEcmFmdC1wcC1hZGQtcmVzaW5mbyB3aGljaA0KIG9yaWdpbmFsbHkg d2FzIGJlaW5nIGRpc2N1c3NlZCBvbiB0aGUgRFNOT1BTIGxpc3QgYmUgZGlzY3Vzc2VkIGhlcmUg b24gQUREIGFzIGl04oCZcyBhIGNsb3NlciBmaXQuJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwO1RoaXMgaGFzIGFscmVhZHkgYmVlbiBoYXBwZW5pbmcgc29tZXdoYXQgYWxyZWFk eSwgc28gdGhpcyBpcyBtb3N0bHkgYW4gYXR0ZW1wdCBhdCBjbGFyaWZpY2F0aW9uLiZuYnNwOyAm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBub3QgYSBXRyBhZG9wdGlvbiBv ZiB0aGUgZHJhZnQsIGp1c3QgcmVjb2duaXppbmcgdGhhdCB0aGUgQUREIGxpc3Qgd291bGQgYmUg dGhlIGJlc3QgZml0IGZvciB0aGUgbWF0ZXJpYWwgaW4gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JZiBhbnlvbmUgb2JqZWN0cyBmZWVsIGZyZWUgdG8gc2hhcmUgeW91ciBjb25j ZXJucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RHJhZnQgbGluazombmJzcDsgPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1wcC1hZGQtcmVzaW5m byI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXBwLWFkZC1y ZXNpbmZvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+cmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkhlbHZldGljYSI+QUREIFdHIENoYWlycywgR2xlbm4gRGVlbiAmYW1wOyBEYXZpZCBMYXdy ZW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B98873C429434D1BB751D7B3A6945323comcastcom_-- From nobody Mon Aug 17 12:13: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 B829E3A09F0 for ; Mon, 17 Aug 2020 12:13:04 -0700 (PDT) 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, 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 IcuCI3krcLyL for ; Mon, 17 Aug 2020 12:13:03 -0700 (PDT) Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.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 42A293A09EF for ; Mon, 17 Aug 2020 12:13:03 -0700 (PDT) Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa4.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 07HJCtI8023122 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Aug 2020 19:12:58 GMT Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.595.3; Mon, 17 Aug 2020 12:12:54 -0700 Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0595.003; Mon, 17 Aug 2020 12:12:54 -0700 From: Paul Hoffman To: "Deen, Glenn" CC: ADD Mailing list Thread-Topic: [Ext] [Add] Draft-pp-add-resinfo Thread-Index: AQHWdLUMPJsi9gPnKEytUcy0M6rB/ak9IL8A Date: Mon, 17 Aug 2020 19:12:54 +0000 Message-ID: <7C33E325-6DD0-4620-B66A-E71B412075A7@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_1648997F-0FE5-438D-887C-2CF3161DC5EE"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-17_14:2020-08-17, 2020-08-17 signatures=0 Archived-At: Subject: Re: [Add] [Ext] Draft-pp-add-resinfo 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, 17 Aug 2020 19:13:05 -0000 --Apple-Mail=_1648997F-0FE5-438D-887C-2CF3161DC5EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 17, 2020, at 9:39 AM, Deen, Glenn wrote: >=20 > Hi ADD, > =20 > The responsible ADs and co-chairs for the various DNS WGs met recently = to talk through where various drafts may fit better than where they were = originally being discussed, and we wanted to suggest that the draft = Draft-pp-add-resinfo which originally was being discussed on the DSNOPS = list be discussed here on ADD as it=E2=80=99s a closer fit. This = has already been happening somewhat already, so this is mostly an = attempt at clarification. =20 > =20 > This is not a WG adoption of the draft, just recognizing that the ADD = list would be the best fit for the material in the draft. > =20 > If anyone objects feel free to share your concerns. Not an objection, but two questions: - Is there a time plan for the call for adoption of = draft-pp-add-resinfo? - What about draft-pp-add-stub-upgrade? Was that omitted from the = message by accident, or did you assume that we would roll that text into = draft-pp-add-resinfo, or ... ? --Paul Hoffman= --Apple-Mail=_1648997F-0FE5-438D-887C-2CF3161DC5EE 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 CQUxDxcNMjAwODE3MTkxMjU0WjAvBgkqhkiG9w0BCQQxIgQghs5eza0sSBJ5KGA/UzzbJLCRUH93 7qGtmiqm21mHCIUwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBADMx7HO8PG7FeYjgmgeQqQ1yk231PT43xInJD66Mf3QX VY7RRL3WoKatBCmiofj6JIutpRu9fCA+5KfqYII3DmqDxkGjUCCDw28WPjntV8HRM0MgJnR/aKei z/gtS2eKovdBBNjg6wXjRqvegDl23FfgPjcMkq2XWU8sL8Nn7SO9jQf5VYsSxV2Ss3rS912r6xcA 5fCYzp46um/1GGvSh9pdNFwO6Kk57NfzfQvbLiFl//83nzaB8UCDDY7tz4gynHnApASovmcQwVjv lv2ta3yRjxHoF9FZ1pOL5rxrAFc0oHfVEiUXP28wU3Rw/IZy5zfCPQ0glesPDuSRPl8m3WsAAAAA AAA= --Apple-Mail=_1648997F-0FE5-438D-887C-2CF3161DC5EE-- From nobody Mon Aug 17 13:15: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 04BDC3A1057 for ; Mon, 17 Aug 2020 13:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=comcast.com header.b=4kknqjXm; dkim=pass (2048-bit key) header.d=comcast.com header.b=Jjo/jVlV; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=HKR82F/e 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 lQdvI2VOdEK0 for ; Mon, 17 Aug 2020 13:15:53 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.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 D7F783A1055 for ; Mon, 17 Aug 2020 13:15:53 -0700 (PDT) Received: from pps.filterd (m0156891.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07HKFOdk022317 for ; Mon, 17 Aug 2020 16:15:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=IQOVTwwbRycaJoxnI6Sgx0j/JTpq7DQKwbyaE2eagWw=; b=4kknqjXm7qNh07F58Odrsc7/Z+j7SrKlw4nTN8AHhM/QYRL6EOkiSDZLwCvZLMkA4/rG 66BLsK7DM2uDmImR3X2KGDr679oa/BJ+jJCQYeYuVVJr51cd6uNFM6MfpvbI95zx0Gnm e1tj1kTDYeaUcisi5Ecm4KYjs8nqXmnjk7Z90/FYLrxxrip9HLCsCs0PWKMW+wj9/gh5 NLjQUHbfn/z7e3IUEu+Lk+72AEu37trQHw1pkg8PXAxkM2x/A4hRvFbmsGtNid7KwqmU dRHsyYCdSdfZaHhCUgXofbbpr2gry72a5vmOjlGS5+uaDVWeJ+8SJt1JbrN5WMh1XTw8 nA== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 32xchvb3yh-43 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 17 Aug 2020 16:15:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1597695352; x=2461608952; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IQOVTwwbRycaJoxnI6Sgx0j/JTpq7DQKwbyaE2eagWw=; b=Jjo/jVlVPSI4a8LhbqHbtRGTP8Xo+e4ESoYAbtlHdvCnduMXKqxLuWWHtol7poBv wUFpihZwlaqiM/+JTGIv+CU/9JkiCMvlnz9h7/A2bh13Rq8sAaD5miaVmWcvL6c1 uKqXQjZ/z0FEYSBw+f63YQrdjOCB9ffrMVTx0afwm4i3mvksUIZAdpvVD6ITDlKG IxsFv/1D+7PtlJYWNF8yODCylJpUEV7mXQ4dXiStUiyu8TX3JjZsc8pR2b4cVCUK jLcMa3Y/tDYAo02jx7TPDe6sBeCoMvFJvQPUSPNOAmZSQgY15mCJSv6gjUs85rRp Ck5ixy8ItYpK/Z7KE2tf/g==; X-AuditID: 60729ed4-a49ff70000003048-2c-5f3ae5771a77 Received: from COPDCEX12.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 6E.F6.12360.775EA3F5; Mon, 17 Aug 2020 14:15:51 -0600 (MDT) Received: from copdcexc34.cable.comcast.com (147.191.125.133) by COPDCEX12.cable.comcast.com (147.191.124.143) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Aug 2020 14:15:51 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc34.cable.comcast.com (147.191.125.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Mon, 17 Aug 2020 14:15:51 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.177) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Aug 2020 16:15:22 -0400 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BYAPR11MB2678.namprd11.prod.outlook.com (2603:10b6:a02:c1::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.23; Mon, 17 Aug 2020 20:15:20 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6%7]) with mapi id 15.20.3283.027; Mon, 17 Aug 2020 20:15:20 +0000 From: "Deen, Glenn" To: Paul Hoffman CC: ADD Mailing list , "Deen, Glenn" Thread-Topic: [Ext] [Add] Draft-pp-add-resinfo Thread-Index: AQHWdLUMPJsi9gPnKEytUcy0M6rB/ak9IL8A//8mv4A= Date: Mon, 17 Aug 2020 20:15:20 +0000 Message-ID: <26F9C5C3-0AC2-431E-BDB0-11BD45360ACC@comcast.com> References: <7C33E325-6DD0-4620-B66A-E71B412075A7@icann.org> In-Reply-To: <7C33E325-6DD0-4620-B66A-E71B412075A7@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: icann.org; dkim=none (message not signed) header.d=none;icann.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:29ff:35a8:5b6f:9c14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f0c628f4-65bf-4a6a-0bf0-08d842ea440f x-ms-traffictypediagnostic: BYAPR11MB2678: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HfQhy0recXkXzulWX9uN1KAOZT2w0Pgr1z8PtcmPzrYdny5Y8aTrMgWGPm/msEKtV2goBG6kB2X6z4v7wq8AGICqsSX7C9nWOUT4LTcPhf7KPRAoYJurL2qBzrOL6y68kUh2wLdACvlXvkuQBgSjisoukZYpI+dYY9TB4uVnCWg2xShkoCTcAhdWRNfTHXD10Fh3zVboIlmNFp6hyHqoe0wJ5DvzHigTTfZ+Xl4zJJBOc0OjsQYJi2+qnv85m1zTFvxd7Pq2+EohLdGsDfdhnTYBHdWOp2+H6zo5KNfZz/wofTi2Ks6LTFfljVYHO0mk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(346002)(396003)(39860400002)(186003)(8676002)(2616005)(71200400001)(6916009)(316002)(8936002)(5660300002)(4326008)(478600001)(66476007)(2906002)(107886003)(33656002)(86362001)(91956017)(54906003)(76116006)(64756008)(66446008)(6486002)(66556008)(6512007)(66946007)(36756003)(83380400001)(53546011)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: C+cyUS4tL7rSnGzTKZRhCKZnMP5dcC16lT5DSOdK+H2MJoIe+RXDHLp2DGUY5sdFg1DK22q+Ol0Y5/nwYMdhS0Fg2+QkyI3TaDX5qmnrbVRHVP7m5TW27dtywFr34LjcqplwKNI6yS0ZyqFSa00pmjPX7f7yKpwTnzp8iwUVTKJa5Vy9+K97HX/O9poaV+r/WlOK9UytA8O4uJeCo+9+69F1vyMWHQmLXY0Pmya+Wb+vgsSKHgptIo1GiRhKpDTFEsjuNDvPWFGwic9GBFXCbqxh0GliBO9GqKigBs/24a+URmBblAYvfNpo1mmZ8gRd9bieKX5JF1yBQJglhPoPO1FifZL5elyDDBHLTZWazsSwJr+1Hc/oNYJVnNCQMHmdhvdk6QSlc400tx/xogGh0uA/VFvHOA+2J55UYXnaTt/r3if8+IrlwLDA6Z+oHd17btDvW0P1EQAqZbjN8MfXuI4rAuz+CJN0H/BqVNAuIxapX5iab7wScge2y7rGWPKhGnXTBZeLfz9JB7XBfetR42DrWlp8+8UbQdKJ5XQlwbcgmz97klFma2G8JUBaWW2JtMc1276pjyyoWDNu2uF0Fr5D3WwZ95BgnF2Tgg7NnS3BYSqXQfYMPFreotQAyLB3h6xe6Gksu21smKZUvLVmXaL+Bk5y2JZimd/KSzUe6vcjP1ZIS9tIvxc20u8GWM46FEwYoGGVVpnsGTXQz5np3w== arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nVtV1w+RvlwNmwHAPvKB7HknMwfAoKBBxu21B6CEDWXw87b99bKOJ4NVKDHx0wTQbs2bDltK5/YDv2pSsgLc91xLOFYBzJgXGJOUXy2zELNCOH7qZfDI4WyFrRu2F2ESL6vD1wjtagQq3KHvFHh28ifewBIx3XlHvFjfVC3AkZ6DVUS4pctKgM/obi9lPvj5R3qbmnZo1ruM9Aser5zXT8wDBDRhwFf05Z3O2HalCm1Uwax/lN7sWrK97d9TkxaI+YVeXp+kEGMj1571pcwvS7fDJ/Q1S6U1c2XdzyB+euodfEZqQ1u1aSCrlLRKOl207gSFQQ1Rj0BS6a5PpMA8uQ== 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=Zq0xeMyfHC8h8mquuTgvRUN6gRCekN545jFG7RNM99o=; b=kswQkmrgFvBLy5HZBfdChVxDrJbNON4pDpOCi0OLZT0wUNH/+LTpC7Wxxdjvh76/zoBSd1/Vk1givAtfKUTJCT1vjj7w1pdKjCRCYy7Z6hJ4Fg6bdSoZicMqi9nkf/bycLtRulaVcT6WrBjCmX0ljsdAphRcwWkS1kB1NMZXX+XSknN58nKG32xoeriR1/CKh4gaIsHEai3aUYcgGlJdeh/6MHKaQxVfaMJwlo1+YkL9I7ota3aVyLNeFgnkDJJFphObAtnPpG+VQ8a0u3qGXMn++WEOJSnDVpougOxp+jjzgfQJoCEWH/d3imp9N+pvx4JRIUUtQ61dUOrJGnqALQ== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zq0xeMyfHC8h8mquuTgvRUN6gRCekN545jFG7RNM99o=; b=HKR82F/eKz+Dkn9cxoe3MqJ3Z2LqreSEAJawG8GjE5t5P9aMEhS5/HThfcJkQkDjjrLmGOpAUY20QqvYZx5E0bdYzs3GwfzWUKaJL4jZidqCtUBah1xtTIPo6u9fSZ+krtQhyeigWdyOVbR1L+MDZ+xB1qMMQe6wc9T+RV6auFA= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: f0c628f4-65bf-4a6a-0bf0-08d842ea440f x-ms-exchange-crosstenant-originalarrivaltime: 17 Aug 2020 20:15:20.2563 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: eul0sUvg2CT+qVB+6tlwkpqJivXb5h19gMExLbmIfLed2Vxk8c7b6ZxrR1ZdnVkvt8JE76OHkvW6mtIUdVMjdfKISXx+IWrU/f3vv9KJFCc= x-ms-exchange-transport-crosstenantheadersstamped: BYAPR11MB2678 x-originatororg: comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <2D3CA59221C0194B8132ECFFB5F2B498@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42JJKJozWbfiqVW8wV8Pi/+n17FZ9E56wujA 5HH4wn0WjyVLfjIFMEVx2aSk5mSWpRbp2yVwZbxZfJGxYJdAxbv+q4wNjC0CXYycHBICJhJ/ bzaxdzFycQgJHGaSOL31CBuUwyhx+ux5FghnLpPEy+k3oZyTjBL39q1ngnAWM0msnPSDGcJ5 xCix/sVMoDIODjYBHYltm+1BlogIaEp8OLibBcRmFvCW+NHfxARiCwvoSsxtfMACUaMn8X1W GxNIq4iAlcTVViMQk0VAVeLV2yqQCl4BO4k3l3+CVQgJFEo0b3QGCXMK2ErMPXKNDcRmFBCT +H5qDRPEInGJW0/mM0F8KSCxZM95ZghbVOLl43+sIGNEBfQlXt1zAbmdUaCHUeLc77/sEDVW ElPfPGWFsGUlLs3vZoSwfSW2P/oGFdeSOH3kPjPIHAkBFYl/hyohwtkSdx+fgxqjJrH92nmo E+QkVvU+ZIGwZSQe3NjONoHRbBaSS2cBTWIGBtX6XfoQpofEo93JEBWKElO6H7LPAgeDoMTJ mU9YFjCyrmLkszTTMzQ00TM0tdAzMjTaxAhOGfOu7GC8PN3jEKMAB6MSD+/dB1bxQqyJZcWV uYcYJTiYlUR4k06YxwvxpiRWVqUW5ccXleakFh9ilOZgURLnjY09GyckkJ5YkpqdmlqQWgST ZeLglGpg5Dz5UaUwNeCLd+m/+i0BvVvWVcp/unU460yY65w6q0M5gjdXtBrobUjZ9P5aAo/d odKFS86oTejxf3g3lctszcvtweukcpPWHj/hn7RqpeH1I9/npbSuMhS4kx6v4dlzZ033ow/3 fr/9qFWwKHZO27Lw5rKjT5pybfdV9fHNivR1/K8osF9ruRJLcUaioRZzUXEiAJ3PwecVAwAA X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-17_14:2020-08-17, 2020-08-17 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] [Ext] Draft-pp-add-resinfo 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, 17 Aug 2020 20:15:55 -0000 SGkgUGF1bCwNCg0KU2luY2UgZHJhZnQtcHAtYWRkLXN0dWItdXBncmFkZSBkZWFscyBzcGVjaWZp Y2FsbHkgd2l0aCBBREQncyBkaXNjb3Zlcnkgd29yaywgIEkgdGhpbmsgdGhlIGFzc3VtcHRpb24g d2FzIHRoYXQgaXQgd291bGQgYWxyZWFkeSBiZSB1c2luZyB0aGUgQUREIGxpc3QgZm9yIGRpc2N1 c3Npb24uICAgICBTbyBtb3JlIG9mIGEgbWF0dGVyIG9mIGFzc3VtaW5nIGl0IHdhcyBhbHJlYWR5 IGluLg0KDQpTbyB0byBiZSBjbGVhciAtIGJvdGggZHJhZnRzOiAgIGRyYWZ0LXBwLWFkZC1yZXNp bmZvIGFuZCBkcmFmdC1wcC1hZGQtc3R1Yi11cGdyYWRlIHNob3VsZCBiZSB1c2luZyB0aGUgQURE IGxpc3QuDQoNClJlZ2FyZHMNCmdsZW5uDQoNCg0KDQrvu79PbiA4LzE3LzIwLCAxMjoxMyBQTSwg IlBhdWwgSG9mZm1hbiIgPHBhdWwuaG9mZm1hbkBpY2Fubi5vcmc+IHdyb3RlOg0KDQogICAgT24g QXVnIDE3LCAyMDIwLCBhdCA5OjM5IEFNLCBEZWVuLCBHbGVubiA8R2xlbm5fRGVlbkBjb21jYXN0 LmNvbT4gd3JvdGU6DQogICAgPg0KICAgID4gSGkgQURELA0KICAgID4NCiAgICA+IFRoZSByZXNw b25zaWJsZSBBRHMgYW5kIGNvLWNoYWlycyBmb3IgdGhlIHZhcmlvdXMgRE5TIFdHcyBtZXQgcmVj ZW50bHkgdG8gdGFsayB0aHJvdWdoIHdoZXJlIHZhcmlvdXMgZHJhZnRzIG1heSBmaXQgYmV0dGVy IHRoYW4gd2hlcmUgdGhleSB3ZXJlIG9yaWdpbmFsbHkgYmVpbmcgZGlzY3Vzc2VkLCBhbmQgd2Ug d2FudGVkIHRvIHN1Z2dlc3QgdGhhdCB0aGUgZHJhZnQgRHJhZnQtcHAtYWRkLXJlc2luZm8gd2hp Y2ggb3JpZ2luYWxseSB3YXMgYmVpbmcgZGlzY3Vzc2VkIG9uIHRoZSBEU05PUFMgbGlzdCBiZSBk aXNjdXNzZWQgaGVyZSBvbiBBREQgYXMgaXTigJlzIGEgY2xvc2VyIGZpdC4gICAgICAgVGhpcyBo YXMgYWxyZWFkeSBiZWVuIGhhcHBlbmluZyBzb21ld2hhdCBhbHJlYWR5LCBzbyB0aGlzIGlzIG1v c3RseSBhbiBhdHRlbXB0IGF0IGNsYXJpZmljYXRpb24uDQogICAgPg0KICAgID4gVGhpcyBpcyBu b3QgYSBXRyBhZG9wdGlvbiBvZiB0aGUgZHJhZnQsIGp1c3QgcmVjb2duaXppbmcgdGhhdCB0aGUg QUREIGxpc3Qgd291bGQgYmUgdGhlIGJlc3QgZml0IGZvciB0aGUgbWF0ZXJpYWwgaW4gdGhlIGRy YWZ0Lg0KICAgID4NCiAgICA+IElmIGFueW9uZSBvYmplY3RzIGZlZWwgZnJlZSB0byBzaGFyZSB5 b3VyIGNvbmNlcm5zLg0KDQogICAgTm90IGFuIG9iamVjdGlvbiwgYnV0IHR3byBxdWVzdGlvbnM6 DQoNCiAgICAtIElzIHRoZXJlIGEgdGltZSBwbGFuIGZvciB0aGUgY2FsbCBmb3IgYWRvcHRpb24g b2YgZHJhZnQtcHAtYWRkLXJlc2luZm8/DQoNCiAgICAtIFdoYXQgYWJvdXQgZHJhZnQtcHAtYWRk LXN0dWItdXBncmFkZT8gV2FzIHRoYXQgb21pdHRlZCBmcm9tIHRoZSBtZXNzYWdlIGJ5IGFjY2lk ZW50LCBvciBkaWQgeW91IGFzc3VtZSB0aGF0IHdlIHdvdWxkIHJvbGwgdGhhdCB0ZXh0IGludG8g ZHJhZnQtcHAtYWRkLXJlc2luZm8sIG9yIC4uLiA/DQoNCiAgICAtLVBhdWwgSG9mZm1hbg0KDQo= From nobody Mon Aug 17 16:15: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 A888E3A142E for ; Mon, 17 Aug 2020 16:15:00 -0700 (PDT) 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 rufpKfBmIr5s for ; Mon, 17 Aug 2020 16:14:58 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 76E1F3A142D for ; Mon, 17 Aug 2020 16:14:58 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id e11so14806163otk.4 for ; Mon, 17 Aug 2020 16:14:58 -0700 (PDT) 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; bh=Dun0g7gJp7gFKEe23ldH/t6mlTlnVUniuZhz/Uxz3PY=; b=WEiIgniypbSEn7XeORHagwQexDemsbRpQ4SudnJTkKgJZY68HEnz791Ph4l7RbTMUo nqzm2QMsa/7LFi7kW+3lqKsmODW4Q70/iCS2eFQmNLb13l141MJ2Ced77IOrhrkC2WmS qjAl2sxllMOuwfG0AzpvDjsEQu+bBlvkEw9x/yfs19e0YCnekiLDN6KFW10laci+z6Sh jEUzaHgYtIEbm1gyaNlA3c0yS7TG0RJoXxC5diMbS6GdW6zH8BbRBLJAHYC9wiupB0lh lElP+JVlKv1ppqG9pRYFK/XyisJrUGWDdFHAMGHwNtMnl+wWXlQGOOej8O8I9pVDDX8T w6Fw== 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; bh=Dun0g7gJp7gFKEe23ldH/t6mlTlnVUniuZhz/Uxz3PY=; b=RJ6zHYaW4qkpplfBGBQa7cYZ3gTc7oxL2MCtgGK8/AnnhDvY5ownkIWr5DjL6pL+C4 LJWO9kjQpeGIsZCfCVC0cLdVSTa3ihHo0OyRixhQMrhiBnB/p18aMwoDZBs+KofyLRUx NeLIWoUDh+y9BvCyF5rTmvUp61ioz2NuXOeyKlV5PqXeynWHS7bCv+SulycwZ6+eNrqm tbsSsaTnJYqBvyqa2Dn2rCfMFNAuskSplyl3SpKQKnwnSDqTJFYqp+N0qzeXRRLDP7go pdvDU3vUophuEIca9kOt5K2Auz6ZCBRUo07QnmpCPDILJ1iu2J/wKKrMhavI/hNv9fca GUXg== X-Gm-Message-State: AOAM5334oMuySk9mglIegcKxjAWmSJbuusM5ShZQQCOO5pgDweVc7MS0 y85oPAZD0W/kH8DucrJHXi/Rn+jDEVjrXqpCCUMLGnRg X-Google-Smtp-Source: ABdhPJyn0lEBAoFsfbchjzEXiAlOMjmYQ5tztBzNcIa008KhPpjmMBveNJnK/fOJ+T9nvQg9NwX1LKx343OPRR2Sh94= X-Received: by 2002:a05:6830:4008:: with SMTP id h8mr13110595ots.158.1597706097405; Mon, 17 Aug 2020 16:14:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Mon, 17 Aug 2020 19:14:46 -0400 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000064334605ad1af0cf" Archived-At: Subject: Re: [Add] Draft-pp-add-resinfo 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, 17 Aug 2020 23:15:01 -0000 --00000000000064334605ad1af0cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The Resolver Info draft was originally adopted by DNSOP, so DNS people are good with this work. The registry it creates allows for more expressive information to be extracted. My only wish is the authors could create several initial entries based on some of the work they've done implementing it. tim On Mon, Aug 17, 2020 at 12:40 PM Deen, Glenn wrote= : > Hi ADD, > > > > The responsible ADs and co-chairs for the various DNS WGs met recently to > talk through where various drafts may fit better than where they were > originally being discussed, and we wanted to suggest that the draft > Draft-pp-add-resinfo which originally was being discussed on the DSNOPS > list be discussed here on ADD as it=E2=80=99s a closer fit. This ha= s already > been happening somewhat already, so this is mostly an attempt at > clarification. > > > > This is not a WG adoption of the draft, just recognizing that the ADD lis= t > would be the best fit for the material in the draft. > > > > If anyone objects feel free to share your concerns. > > > > Draft link: https://datatracker.ietf.org/doc/html/draft-pp-add-resinfo > > > > > > regards > > ADD WG Chairs, Glenn Deen & David Lawrence > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000064334605ad1af0cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

T= he Resolver Info draft was originally adopted by DNSOP, so DNS people are g= ood with this work.=C2=A0=C2=A0
The registry it creates allows for more = expressive information to be extracted.=C2=A0 My only wish=C2=A0
is the authors coul= d create several initial entries based on some of the work they've done=
implemen= ting it.
=
tim<= /div>


On Mon, Aug 17, 2020 at 12:40 PM Deen, Glenn <Glenn_Deen@comcast.com> wrote:

Hi ADD,

=C2=A0

The responsible ADs and co-chairs for the various DN= S WGs met recently to talk through where various drafts may fit better than= where they were originally being discussed, and we wanted to suggest that = the draft Draft-pp-add-resinfo which originally was being discussed on the DSNOPS list be discussed here on ADD= as it=E2=80=99s a closer fit.=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0This has= already been happening somewhat already, so this is mostly an attempt at c= larification.=C2=A0 =C2=A0

=C2=A0

This is not a WG adoption of the draft, just recogni= zing that the ADD list would be the best fit for the material in the draft.=

=C2=A0

If anyone objects feel free to share your concerns.<= u>

=C2=A0

Draft link:=C2=A0 https://datatracker.ietf.org/doc/html/draft-pp-add-resinfo

=C2=A0

=C2=A0

regards

ADD WG Chairs, Glenn Deen & David Lawrence

=C2=A0

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000064334605ad1af0cf-- From nobody Mon Aug 17 16:20:48 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 6419F3A143B for ; Mon, 17 Aug 2020 16:20:46 -0700 (PDT) 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 gQkxL1cfLPKP for ; Mon, 17 Aug 2020 16:20:44 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 9C9ED3A143A for ; Mon, 17 Aug 2020 16:20:44 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id q9so14807783oth.5 for ; Mon, 17 Aug 2020 16:20:44 -0700 (PDT) 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; bh=r7S8Au8fjHcwjVYQffbwJ4gxA+Epu6FebAQZwOEqRrI=; b=Ewkh0r0IxbQqo/g9J+mXRp3/kr2oHBOaYbJisx83IuWa0dGvFKAGGnFK3RDHEfM1I2 6nGWqtm6U2i5hWEBFzEHEhoJBUQtubKhPjdUK5QH0ekk6B2LMRLsAjS1ua0ByZkqJMUu MYdvZWxxIZMDJPn0rikApx1EgdNmjK7EnUN0TXYBplzZfj/22/oGWdomkiFOmu1CAvmS p2jhXv3bopxFSVjAyGyeD5dgwE0gJWf/xsANB6tyZqf2Nv9mRxxbe5hIEq2tD+zpxfFX vpiCOzEL63NMiLtChqdybUKSzjuXjQMEodWLDVDa0KaNgkdjQSr6NBh4dfJKs/u/9+3G 83HA== 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; bh=r7S8Au8fjHcwjVYQffbwJ4gxA+Epu6FebAQZwOEqRrI=; b=AF1jW22u1+a9Z3xwak4OYV58IR62VtAmeyi/Scfqy0M670OvGnE5GjlW6avamAVmk2 PBNIZABlxoreqLwnES0EZ929/MtEVBdOASu2qJJabTSrGUVRa00NK7jl1pFCA+KfIUaB z0wBkqmPxQvc0nMJg5a9mXOx6fUCVTsPOipK0P7rn0ZKPLpbLL1coVykXCgKJNn0PnYF MfQy/NySKLkeLWVWX/ssoKcEM1s70IzvK1MVoWKGPPW0cN/R9Cnx2gWcOm8VtJjkgCIh YKM5YPw+WsBtsA52PDu1kxsA/fLlkZ+a2WocpcJAdMbqxEtaT5rCfpZZaV4a78NAIHFQ mPxg== X-Gm-Message-State: AOAM532JsYWwt+DHNUS0QKpW+tcS6OJw2cMMqlWZEHsGPEWwB7RN7oqw r/u743Dj2VdDhxm2i2i4ALlL95Xmw1MhjiYEAa33KvmZ X-Google-Smtp-Source: ABdhPJw8V8Au9+mImdzUQoz/IKcCQ5bnWLpebJICW15VCHyflr75Jh6+KFO/IpJ+sGsGKORevj190YJu0+Ii9sD4S3Q= X-Received: by 2002:a05:6830:4008:: with SMTP id h8mr13125907ots.158.1597706443758; Mon, 17 Aug 2020 16:20:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Mon, 17 Aug 2020 19:20:33 -0400 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000091e2905ad1b05fd" Archived-At: Subject: Re: [Add] Draft-pp-add-resinfo 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, 17 Aug 2020 23:20:47 -0000 --000000000000091e2905ad1b05fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Also, since I'm not a chair here, I can say that I think this work should be adopted and worked in within ADD. tim On Mon, Aug 17, 2020 at 7:14 PM Tim Wicinski wrote: > > The Resolver Info draft was originally adopted by DNSOP, so DNS people ar= e > good with this work. > The registry it creates allows for more expressive information to be > extracted. My only wish > is the authors could create several initial entries based on some of the > work they've done > implementing it. > > tim > > > On Mon, Aug 17, 2020 at 12:40 PM Deen, Glenn > wrote: > >> Hi ADD, >> >> >> >> The responsible ADs and co-chairs for the various DNS WGs met recently t= o >> talk through where various drafts may fit better than where they were >> originally being discussed, and we wanted to suggest that the draft >> Draft-pp-add-resinfo which originally was being discussed on the DSNOPS >> list be discussed here on ADD as it=E2=80=99s a closer fit. This h= as already >> been happening somewhat already, so this is mostly an attempt at >> clarification. >> >> >> >> This is not a WG adoption of the draft, just recognizing that the ADD >> list would be the best fit for the material in the draft. >> >> >> >> If anyone objects feel free to share your concerns. >> >> >> >> Draft link: https://datatracker.ietf.org/doc/html/draft-pp-add-resinfo >> >> >> >> >> >> regards >> >> ADD WG Chairs, Glenn Deen & David Lawrence >> >> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > --000000000000091e2905ad1b05fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A= lso, since I'm not a chair here, I can say that I think this work shoul= d be adopted and worked in within ADD.

tim


On Mon, Aug 17, 2020 at 7:14 PM Tim Wicinsk= i <tjw.ietf@gmail.com> wrot= e:

=
The Resolver I= nfo draft was originally adopted by DNSOP, so DNS people are good with this= work.=C2=A0=C2=A0
The registry it creates allows for more expressive in= formation to be extracted.=C2=A0 My only wish=C2=A0
is the authors could create seve= ral initial entries based on some of the work they've done
implementing it.

tim


On Mon, Aug = 17, 2020 at 12:40 PM Deen, Glenn <Glenn_Deen@comcast.com> wrote:

Hi ADD,

=C2=A0

The responsible ADs and co-chairs for the various DN= S WGs met recently to talk through where various drafts may fit better than= where they were originally being discussed, and we wanted to suggest that = the draft Draft-pp-add-resinfo which originally was being discussed on the DSNOPS list be discussed here on ADD= as it=E2=80=99s a closer fit.=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0This has= already been happening somewhat already, so this is mostly an attempt at c= larification.=C2=A0 =C2=A0

=C2=A0

This is not a WG adoption of the draft, just recogni= zing that the ADD list would be the best fit for the material in the draft.=

=C2=A0

If anyone objects feel free to share your concerns.<= u>

=C2=A0

Draft link:=C2=A0 https://datatracker.ietf.org/doc/html/draft-pp-add-resinfo

=C2=A0

=C2=A0

regards

ADD WG Chairs, Glenn Deen & David Lawrence

=C2=A0

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000091e2905ad1b05fd-- From nobody Tue Aug 18 19:13:52 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 CFC783A109E for ; Tue, 18 Aug 2020 19:13:50 -0700 (PDT) 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, 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 (1024-bit key) header.d=nohats.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 pobO1jUapCba for ; Tue, 18 Aug 2020 19:13:49 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 51E253A1098 for ; Tue, 18 Aug 2020 19:13:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BWWY62h6Wz3F6; Wed, 19 Aug 2020 04:13:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1597803226; bh=NFVlttXHUFCNps14tMrK4WOfGHGijltbf7OW5QlJCvk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mXxn23O8E99HpyRt30Banc7BSxSc0OrK08NRsmSGyafpaPOUUZ8TsE+HXq9tq7lM+ rexASpVG1DsR0oO7HBWm0tK6VBMX9prcF3gf3J64gwEBRnJUwA453cJSOF3zdycYig oEWpwdMumqITcMLuePsGEOo71aj0kxXqx1I8rs4k= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Rqa15frJQqTH; Wed, 19 Aug 2020 04:13:45 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 19 Aug 2020 04:13:45 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id EF1E16029BA2; Tue, 18 Aug 2020 22:13:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E6BBC384C6; Tue, 18 Aug 2020 22:13:43 -0400 (EDT) Date: Tue, 18 Aug 2020 22:13:43 -0400 (EDT) From: Paul Wouters To: Tim Wicinski cc: ADD Mailing list In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Add] Draft-pp-add-resinfo 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, 19 Aug 2020 02:13:51 -0000 On Mon, 17 Aug 2020, Tim Wicinski wrote: > The Resolver Info draft was originally adopted by DNSOP, so DNS people are good with this work.   > The registry it creates allows for more expressive information to be extracted.  My only wish  > is the authors could create several initial entries based on some of the work they've done > implementing it. Yes indeed. If we don't have any entries, why are we starting this work. Personally I think "private-" is a better prefix than "temp-". It would also be nice if the server had a standarized way of relaying its public name, so that any TLSA records associated with it could be found in the public DNS. Paul From nobody Tue Aug 18 20:23:52 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 7427A3A10EF for ; Tue, 18 Aug 2020 20:23:50 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=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 (2048-bit key) header.d=lowentropy.net header.b=Jh90MXEN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=l6wM5UYg 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 eOJ6IwSLoFYw for ; Tue, 18 Aug 2020 20:23:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1473A10EE for ; Tue, 18 Aug 2020 20:23:48 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C54585C0160 for ; Tue, 18 Aug 2020 23:23:47 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 18 Aug 2020 23:23:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=wDgRyiXs3cy4F6JEwpePmgJ/OiwyDRr 90UIBcKO8KJU=; b=Jh90MXENRRaCyuz2UPI0JoZu9OAhISNBxyFImL2vce+vo1l 61DhA5A9wxcdKxjSTNmjQq5Hz4jMKMoOowl5qICF3CgLxoJp+na4sKi56s2mHryL aZ0f98n8P2BOt1b6pcL81d7spNps7dfQ7eXPdTK2UYvazHIuobA79usKmCvsErHO ti1OPZ/0mxTws+t9gK7O1X2iq08vVOsOfcLqeeoPQYfoyIIZps+zb+5ytZoMjaLi S+xX3dqQIXaZ+IMGjysDWW6oz205/9msho6CoAPujKcxMk5K069v21GgwtSQnldW cvDtEMzXBIDbGSf73DrJRkUfak6Ufyv4KlSVQlA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=wDgRyi Xs3cy4F6JEwpePmgJ/OiwyDRr90UIBcKO8KJU=; b=l6wM5UYgfSsIFk1lOtRsT9 q2N8i2Or7w3tLPw6Hwq+3BHKO/lVLPJGJ+f/Pa3vKbUtuDYyPIJzEeKwr1vquV1l 6Su+QUrNUPdTd6wfzlzht0sMgej1mz9kZnVhIwK+e3H1zz3vVtrU6VsNtuYHqoSf 08/Bfd21RkmMmGrov9EeqZOLaGZq+xxCxWa0tiZmzBirwhYonXTIXJBTrHh4yIzg IcirJ6fdF0YMTtoJTVYWJ/czaDZ+hQZuwY5CRGXJclrUov8au/oKgj+RWVTSK7Z0 HepCbrxaeKe+q0NnQl/gyzk5CtIBJyyNgAcjSrUZrYlC5YUPDnqqsnDHJGNU3URg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtjedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4DE3CE00B3; Tue, 18 Aug 2020 23:23:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-191-gef79d59-fm-20200818.001-gef79d590 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 19 Aug 2020 13:23:26 +1000 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] Draft-pp-add-resinfo 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, 19 Aug 2020 03:23:50 -0000 On Wed, Aug 19, 2020, at 12:13, Paul Wouters wrote: > Personally I think "private-" is a better prefix than "temp-". "X-", definitely "X-". See RFC 6648. From nobody Wed Aug 19 07:49: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 5A9023A09D4 for ; Wed, 19 Aug 2020 07:49:55 -0700 (PDT) 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, 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 0wKUq4AkY8Wi for ; Wed, 19 Aug 2020 07:49:54 -0700 (PDT) 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 59D473A0847 for ; Wed, 19 Aug 2020 07:49:42 -0700 (PDT) Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 07JEnfoG011770 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Aug 2020 14:49:41 GMT Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.595.3; Wed, 19 Aug 2020 07:49:40 -0700 Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0595.003; Wed, 19 Aug 2020 07:49:40 -0700 From: Paul Hoffman To: Paul Wouters CC: ADD Mailing list Thread-Topic: [Ext] [Add] Draft-pp-add-resinfo Thread-Index: AQHWdjf3IXCln8VKiUmOB/RLYLNiOg== Date: Wed, 19 Aug 2020 14:49:40 +0000 Message-ID: <387BEB1D-9619-40E3-AA8E-EFC13BCFC151@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_C94731F7-4902-42F5-8FDA-A6EFD23B7BB2"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-19_07:2020-08-19, 2020-08-19 signatures=0 Archived-At: Subject: Re: [Add] [Ext] Draft-pp-add-resinfo 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, 19 Aug 2020 14:49:55 -0000 --Apple-Mail=_C94731F7-4902-42F5-8FDA-A6EFD23B7BB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 18, 2020, at 7:13 PM, Paul Wouters wrote: > Yes indeed. If we don't have any entries, why are we starting this = work. We do have proposed entries: please see draft-pp-add-stub-upgrade. = People asked us to split the entries into the document that would use = them. > It would also be nice if the server had a standarized way of relaying > its public name, so that any TLSA records associated with it could > be found in the public DNS. Fully agree. --Paul Hoffman= --Apple-Mail=_C94731F7-4902-42F5-8FDA-A6EFD23B7BB2 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 CQUxDxcNMjAwODE5MTQ0OTQwWjAvBgkqhkiG9w0BCQQxIgQgffIt6t7jUm1tNTbGwLwJK+n8Bs6V kVBN1vfpdEu+EmswgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAJx/dSbHOGbrKlz19aOyp3bNibc8zkGvUZPSuHII+5ON rWACWduq/T3hvbO6RYeyhdf8k397j+RZMDEckAa1tc8WrIHrUlAHRcZMV4Bhcu3Vww7enjVxj/Bb 0Xc29CE7UFl0avcTlvjtjfgnCmxjFMI0Fn8A25S38UVnXvs39x9mBwrQ5yDvHiQ/I1ntmyldbNP/ 0kI9Qb99BR+bE0BLLL4JE3fN74Oy0bW/k/G6JY5CEH3ie3mIWFNORU4A9jDko49B1I8b1+x+Ap4V NLr4wsYUBaTWlNI5QxIxZCVO8DUGo5GBjM8QJI46LqaKtTVSITv67d0Hj7O9n83pPskXu6oAAAAA AAA= --Apple-Mail=_C94731F7-4902-42F5-8FDA-A6EFD23B7BB2-- From nobody Fri Aug 21 10:51: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 DF5EE3A0F65 for ; Fri, 21 Aug 2020 10:50:57 -0700 (PDT) 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=comcast.com header.b=rVRm9ojn; dkim=pass (2048-bit key) header.d=comcast.com header.b=R2WJF3pr; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=QEU2DXWo 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 idWQLlsQ_pdi for ; Fri, 21 Aug 2020 10:50:56 -0700 (PDT) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.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 D2AEF3A0F56 for ; Fri, 21 Aug 2020 10:50:55 -0700 (PDT) Received: from pps.filterd (m0156895.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07LHnkJW008581 for ; Fri, 21 Aug 2020 13:50:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : mime-version; s=20190412; bh=tv2PC6naTVztH+RMXoncpBcQGDjlZzPRgE1A7ThwuCg=; b=rVRm9ojnk/3J9d+HEbfst6EgSJr3/Yp82ldXC7O+0oe/xE4qpyxUYu0FTx1LZSe2H5UD v8Q4p9l1ipQxUgM9z5DjlVBw5Y3nLInyJ1oikzDEpsRKn6hPoRzUZAkfJnMUiiq3PH08 ykr/IHubGkW4zs8mZEUexJ7nEzj6XD6PGxT9V4HbkjBfCVMfpYYnqyDJfwzolWM51LwM WP1eO3QuVrQPaFOoYtB0otPuqa6RWb/ABoxKt1Xl2zJlFI0i3yRnjO6gI88IarM9V0CW FlD0x2nhv0OFTwm7EE/upz8fCmu7oowije2rz8odsqJbHYI17Kt0gMNLkIUpfZW/JXak fQ== Received: from pacdcmhout02.cable.comcast.com (pacdcmhout02.cable.comcast.com [68.87.96.15]) by mx0b-00143702.pphosted.com with ESMTP id 3304my6x37-19 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 21 Aug 2020 13:50:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1598032250; x=2461945850; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tv2PC6naTVztH+RMXoncpBcQGDjlZzPRgE1A7ThwuCg=; b=R2WJF3prjnril4zk4ZHPi08p7lxNW9qhXKQF+h4JX95ZjxZIUIqSnE59reu6IVOp BYVnqgp/WYXlwV/cNoe7RYhieTzxk/gHAmR1PvlutMqAxJHSEbSG4XR4QHiqVjfm y7hhaTylCVwPosVnWVSZlYJTT32Q5f9+VnGXWaAfK+JEcbHAmKnrP9Xt/M763X32 kOaHIxEH8J4LI7yaA97tRt8PeqmxLIYxWleMjuLBZ65jyJvfZbbCI3v+IX4x4HTs hpmRNgeR3a9qHBodj/aNrY5UqOdjPzVp5cfBI84nGY+J20rEIuiNfOYzQ9UNkF2/ Q19RbSwWbr5liNkdIzbzQA==; X-AuditID: 4457600f-f0fff70000005543-cf-5f40097a4099 Received: from PACDCEX51.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by pacdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 6A.71.21827.A79004F5; Fri, 21 Aug 2020 13:50:50 -0400 (EDT) Received: from PACDCEX15.cable.comcast.com (24.40.1.138) by PACDCEX51.cable.comcast.com (24.40.2.150) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Aug 2020 13:50:49 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX15.cable.comcast.com (24.40.1.138) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 21 Aug 2020 13:50:49 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.57) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Aug 2020 13:50:49 -0400 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BYAPR11MB3669.namprd11.prod.outlook.com (2603:10b6:a03:f7::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Fri, 21 Aug 2020 17:50:48 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6%7]) with mapi id 15.20.3305.026; Fri, 21 Aug 2020 17:50:47 +0000 From: "Deen, Glenn" To: ADD Mailing list Thread-Topic: ADD WG Github Thread-Index: AQHWd+OZSYN17LEmEUiw5/2Qz5/u6g== Date: Fri, 21 Aug 2020 17:50:47 +0000 Message-ID: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:ad11:8459:6ae5:7c3d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1da32fe-2147-487f-54d7-08d845fabc82 x-ms-traffictypediagnostic: BYAPR11MB3669: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oMlTXnI/LxwpuoN8HyWdUux27l9QeC4pENMb2vC5WzEeEgB7Zna9592AJvuW0VUrzwZrC6askj55EDbYnsz2Bxup7izJdGkgSzCUAQIwUszWKmMpU24YJFE70P9V70EKxtEQRd4b9NwY5yblrWy4U32xjlfOpLDhKzLILGQHostO1o27ifPq4NuetF3Dzxdv70e2FpVJCtp1/WIm5mKTYRfSw7YyWWVKJlA9nlw0K2niTh8RBF5g/UJnRMk1l/xiHJS/wMcKc+rw9S2UMkfvgdsSf4GsWOSI/fC23PBmGUIpLz/y9i7cBKk4+Mb+WGHM7Lp8dJuMb+cBFM2zB4BClwG+mQ4SpYvx5HHuL93cJGZWh2aTkOIi2xAwjnxEjJjBtSoJ4f0FWR8oYNvM/q+Mwg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(366004)(396003)(136003)(376002)(2906002)(316002)(966005)(8936002)(478600001)(2616005)(6486002)(8676002)(186003)(6916009)(6506007)(71200400001)(6512007)(3480700007)(76116006)(66946007)(66476007)(33656002)(5660300002)(166002)(86362001)(66446008)(66556008)(64756008)(83380400001)(7116003)(36756003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Zfn8ceT8xDVZ7NmEX4/0eTM4w+KVuhb/PldZPpseWUNzd4mfr+X0Z4fX6hrY0kbOusr9OCrJ1ZpCyl070xZ4nIycCBwco5I7gXekDbadzdRX6u0DUlCL407vonsJKcbV9sr8QJtciwLEVKRPOkZKe16k6xPUuCEe/TufGOHREQLtyK2gcbz2y7UCEEQhd7j+kwmt+mNSaaMqHtjuT8hTB/gCGQpho3ABhqKZQ3zT12F9S7SX39oI0g+xsnN0s61qdbKREn8Vuz5zKFz6e+NQc2xzfOY5M6sR7RNL7O1aQ2G0VOCFa1CGOuc90ud9htWm1hBBsgj/fcFWvpS9YavNgOXMqsfT7FhYITA8Kb+hAUic6CJdU/t2CfDnyYApEelN76r/PEA0YMR4+cV8WdYa8m9HulFWGvp+y2UrThKr78X5Utoi5FUCkSu1WWUkdDQgGC6QygwZ9uWMBxUmxLSKeV57zX6nFpO0rIQOJ8KFRjpzLgGk/ky7hafn0L0G8Vtw2Jup4m7LQR/K2S8LKvXvnXB+h1QFDHgpC+lH5VjcSlZcwyo6d/DHSSm1gmyTroM/p1KG5SmfExyGeneNn3kG9seo0vuxuRyhdID7449DTQ+w1iVVpiSq9KNu3iBOjaIHBtydoFV8UvZeTTryhwS8ofebbqAimKBJ8bgTJ4GBDi/jMEflesAEdklweki7sghcHwzIHLY2OagSZmbPOvISow== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EGuZnQQrqrLMeUUN5PcU3NH5Zq9POWFwadlUSeXX2FEE6fACeiWqDtYcCpIsgfdqVrrWHdhC9JsG84tNekhlbmDZlZLMjuD2LbnSjYyDQG704dAxEOEYzOj6ygXhdarM8dqPNsXtoVfo1eCG6Rs6fPjUKxgnb3qdQp9EUtbRAcbAldUCUWwLiGAnG7KV01oPzA0HY6eBxMj0wYjc2sncXyRm2svLG+M+QrvZmCAnG7T1pNlmJpkr+liQr7Kc4duS5vK0qQaiMzoVfenJYlhlL7jEiMu++e9EJm1hMklu1bq7ScuNtDljXCLUFCWzEPSeVtWL4cLOkz7REW1zgIqpPA== 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=CBE/TJTQMMVLuDeEr6RSA/ncMJXVetW7CxPMh2pfnc4=; b=LNhLtj/4DSAR6nMRfD0EWuKy8045wDvUx30kEdZLExQb/jUnlfTz0cQhvGaJbFW7uENKVJRLp7n8pRwIq7IlMO1xXPq/bdHtw88bI2H/kbOMYK5VwrvvtZQKB+OyRyLf2PltXWAZjA576dhJGiqhvCE4Qaru3MwpAV+ykS6QgGlMq2lmYJumXeocaF0iv6hww2VZCHQaseW+uJVNaBFRrY39BVckhRiZbtTKk4/ePfUNtUSY2oB5LN5D3P0oSkt83uG4+oxq8ja1eOSB3saA/2siHpwapUSnkUlTYhG1j0sHbJ3UBaKzciIiUUH+eIVWHJwy93tmtBdx3c/99gbtrw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CBE/TJTQMMVLuDeEr6RSA/ncMJXVetW7CxPMh2pfnc4=; b=QEU2DXWo8SzYgkqyydqeK/5FoIfAFain2iZ5Bvq6VBDGIA/O/5WaZ2YILmUtI0teoxZZvT8bU7+mCrrlbeyU17T6Mn8YqzFI3mbvavhN+7UP67GVy0+4mBm6cWRO3WmvjmPQcsuKn11NGhYmK/kurSVjbLQiNrAUo+/7GpH0afE= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: e1da32fe-2147-487f-54d7-08d845fabc82 x-ms-exchange-crosstenant-originalarrivaltime: 21 Aug 2020 17:50:47.8744 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: rtMH+VTjRKUVbMjfcaCSH43ZXEyv0imbFEP1MvMwDrJuJOz+cQUfvkt2V1t89g17ODnAF9SqznP0a09w0Wmz2riHMB/Rw1eq+S94YA0j8Co= x-ms-exchange-transport-crosstenantheadersstamped: BYAPR11MB3669 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_31194C906C0B470C8B1479C12D2C5C0Dcomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+Xa249ls9bk0X9SK1oUUnRllJsMLCU1GYfRHFNFceMpb0zYz NQoJBJ1ZQkF5iYluFKaWVq50kgwl1FKwjJHOdM7yEl4wzRuunZ0F/vd7nvf53gt8FCHS8fyo FFUWrVYp08WkgBt3ThwQksePURyqnBZHOHoayBgk0+tXOAnogkCaRKenZNPq0KhEQXLbqonM LJLmLNnXUD6qi9QiPgX4CPQ+7OIyLMIdHJjL99UigZNbEMyYuhErBhBYep/wWNGJoL+5mmBF DQcWPr51V2wISg0WZ4WiSBwMza+jmb7eeC8YrEYOw9vxDhh5Vo1Y3x+6C5iuDEtgyGYnGebi /TA2xOaFOApqHD9cGeR8+7e7zuUT2Be+23Uc9gYMelMfwbIPTI5t8JgVfHAoTA3HMashrEUw pW1HbCYSlsuKeCzvhH5dsds/BQuWabcfBCNGowfLafC5x0qyfAAsvwvds3ZBbckol+UAGLEY SWYY4FYC5u/O8FgxS0Dji+furus8qFm8xWwHeB9smHNLUVj5pntYvgxrf6wuFmIv6Cqzc8ud LwgcCC9bQtnIHnhUPOrB8kEoqHzqZhmUtenR5kwVomqRZ3iEJOKY5Hi4JOxoE3J9m8Rt71Dn Y5kZYQqJtwjxerRCxFNma3KvmRFQhNhbONjktIRJytw8Wp2hUN9IpzVm5E9xxb7CBwMTl0T4 qjKLTqPpTFr9v8qh+H75KO39JNi+vJGOf7piSLnzwdDYbmjgW0M6Xg06CGpi9KZq/PTsWXL9 tlwXqyg8n2PUevlfb10q6asKrFepqivk2QlcSZVDaZs7nGESrBkdsYRIvHVV3ihb/HXmZNbF nIqfSQ0ZX+l77Z5FJ+ablz2J4Hhp6v3Fbyv1wwnx8tTdYq4mWRkWRKg1yn95ODT4MgMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-21_08:2020-08-21, 2020-08-21 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Add] ADD WG Github 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: Fri, 21 Aug 2020 17:50:58 -0000 --_000_31194C906C0B470C8B1479C12D2C5C0Dcomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQURELA0KDQpBREQgbm93IGhhcyBhIEdpdGh1YiBwcmVzZW5jZTogICAgaHR0cHM6Ly9naXRo dWIuY29tL2lldGYtd2ctYWRkDQoNClNvIGZhciBpdCBoYXMgIGp1c3QgdHdvIHJlcG9zaXRvcmll czoNCiAgICAoMSkgYSBnZW5lcmljIHdnLW1hdGVyaWFscyAgKG5vdCBtdWNoIHRoZXJlIHlldCBo b3dldmVyKQ0KICAgICgyKSBkcmFmdC1hZGQtcmVxdWlyZW1lbnRzIGhvbGRpbmcgdGhlIFJlcXVp cmVtZW50cyBkb2MgdGhhdCBDaHJpcyBCb3gga2lja2VkIG9mZiBvbiB0aGUgbWFpbGluZyBsaXN0 IHJpZ2h0IGFmdGVyIElFVEYxMDguDQoNCkFzIHdpdGggb3RoZXIgSUVURiBXRyB1c2VzIG9mIEdp dEh1YiBwcmltYXJ5IGFjdGl2aXR5IGFuZCBkaXNjdXNzaW9uIHdpbGwgY29udGludWUgdG8gYmUg b24gdGhlIEFERCBsaXN0IHdoaWxlIEdpdEh1YuKAmXMgdG9vbHMgY2FuIGhlbHAgdGhlIGdyb3Vw cyB3b3JrIHN1Y2ggYXMgaXNzdWUgdHJhY2tpbmcsIGFuZCB0aGUgYWJpbGl0eSB0byB1cGxvYWQg bWF0ZXJpYWxzIHRvIGhlbHAgdGhlIGRpc2N1c3Npb24gc3VjaCBhcyBkaWFncmFtcyBhbmQgZHJh d2luZ3MuDQoNCklmIEFERCBkb2N1bWVudCBhdXRob3JzIGFuZCB3b3VsZCBsaWtlIGFuIEFERCBy ZXBvc2l0b3J5IGZvciB5b3VyIGRvY3VtZW50IHBsZWFzZSBzZW5kIG1haWwgdG8gYWRkLWNoYWly c0BpZXRmLm9yZw0KDQoNClRoaXMgaXMgdGhlIGZpcnN0IElFVEYgV0cgR2l0aHViIHRoYXQgSeKA mXZlIHNldHVwIGFuZCBJIGRpZCBteSBiZXN0IHRvIGZvbGxvdyB0aGUgSUVURi1HaXRodWIgZHJh ZnRzIGJ1dCB0aGVyZSBhcmUgc3RpbGwgYSBmZXcgdGhpbmdzIHN1Y2ggYXMgaG93IHRvIHNldHVw IGF1dG9tYXRlZCBhY3Rpdml0eSByZXBvcnRzIHRoYXQgSeKAmW0gc3RpbGwgbm90IHN1cmUgaG93 IHRvIGVuYWJsZS4gICAgUGxlYXNlIGRpcmVjdCBtZXNzYWdlIG1lLCBhbmQgZG9u4oCZdCBmaWxs IHRoZSBBREQgbGlzdCwgd2l0aCB0d2Vha3MgYW5kIG9wdGlvbnMgeW914oCZZCByZWNvbW1lbmQu DQoNCkJUVyDigJMgSSBiZWxpZXZlIENocmlzIEJveCBpcyBsb29raW5nIGZvciBhZGRpdGlvbmFs IGNvbnRyaWJ1dG9ycyB0byB0aGUgcmVxdWlyZW1lbnRzIGRvYy4NCg0KUmVnYXJkcw0KR2xlbm4g RGVlbiwgQUREIGNvLWNoYWlyDQo= --_000_31194C906C0B470C8B1479C12D2C5C0Dcomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <7B8A36D3FE77E54C98CAA61D8313B3F0@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCWNvbG9yOndp bmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SGkg QURELDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5BREQgbm93IGhhcyBhIEdpdGh1YiBw cmVzZW5jZTombmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL2dpdGh1 Yi5jb20vaWV0Zi13Zy1hZGQiPmh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWFkZDwvYT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gZmFyIGl0IGhhcyAmbmJzcDtqdXN0IHR3byByZXBvc2l0 b3JpZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsg Jm5ic3A7KDEpIGEgZ2VuZXJpYyB3Zy1tYXRlcmlhbHMgJm5ic3A7KG5vdCBtdWNoIHRoZXJlIHll dCBob3dldmVyKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7ICZuYnNwOygyKSBkcmFmdC1hZGQtcmVxdWlyZW1lbnRzIGhvbGRpbmcgdGhlIFJlcXVpcmVt ZW50cyBkb2MgdGhhdCBDaHJpcyBCb3gga2lja2VkIG9mZiBvbiB0aGUgbWFpbGluZyBsaXN0IHJp Z2h0IGFmdGVyIElFVEYxMDguDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgd2l0aCBvdGhl ciBJRVRGIFdHIHVzZXMgb2YgR2l0SHViIHByaW1hcnkgYWN0aXZpdHkgYW5kIGRpc2N1c3Npb24g d2lsbCBjb250aW51ZSB0byBiZSBvbiB0aGUgQUREIGxpc3Qgd2hpbGUgR2l0SHVi4oCZcyB0b29s cyBjYW4gaGVscCB0aGUgZ3JvdXBzIHdvcmsgc3VjaCBhcyBpc3N1ZSB0cmFja2luZywgYW5kIHRo ZSBhYmlsaXR5IHRvIHVwbG9hZCBtYXRlcmlhbHMgdG8gaGVscCB0aGUgZGlzY3Vzc2lvbiBzdWNo DQogYXMgZGlhZ3JhbXMgYW5kIGRyYXdpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBB REQgZG9jdW1lbnQgYXV0aG9ycyBhbmQgd291bGQgbGlrZSBhbiBBREQgcmVwb3NpdG9yeSBmb3Ig eW91ciBkb2N1bWVudCBwbGVhc2Ugc2VuZCBtYWlsIHRvIGFkZC1jaGFpcnNAaWV0Zi5vcmc8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpIZWx2ZXRpY2EiPlRoaXMgaXMgdGhlIGZpcnN0IElFVEYgV0cgR2l0aHViIHRoYXQgSeKAmXZl IHNldHVwIGFuZCBJIGRpZCBteSBiZXN0IHRvIGZvbGxvdyB0aGUgSUVURi1HaXRodWIgZHJhZnRz IGJ1dCB0aGVyZSBhcmUgc3RpbGwgYSBmZXcgdGhpbmdzIHN1Y2ggYXMgaG93IHRvIHNldHVwIGF1 dG9tYXRlZCBhY3Rpdml0eSByZXBvcnRzIHRoYXQNCiBJ4oCZbSBzdGlsbCBub3Qgc3VyZSBob3cg dG8gZW5hYmxlLiAmbmJzcDsmbmJzcDsmbmJzcDtQbGVhc2UgZGlyZWN0IG1lc3NhZ2UgbWUsIGFu ZCBkb27igJl0IGZpbGwgdGhlIEFERCBsaXN0LCB3aXRoIHR3ZWFrcyBhbmQgb3B0aW9ucyB5b3Xi gJlkIHJlY29tbWVuZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+QlRXIOKAkyBJIGJl bGlldmUgQ2hyaXMgQm94IGlzIGxvb2tpbmcgZm9yIGFkZGl0aW9uYWwgY29udHJpYnV0b3JzIHRv IHRoZSByZXF1aXJlbWVudHMgZG9jLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5SZWdh cmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5HbGVubiBEZWVuLCBB REQgY28tY2hhaXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_31194C906C0B470C8B1479C12D2C5C0Dcomcastcom_-- From nobody Fri Aug 21 10:58:43 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 5D2363A0F9A for ; Fri, 21 Aug 2020 10:58:41 -0700 (PDT) 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 al9UputwuuI9 for ; Fri, 21 Aug 2020 10:58:40 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 E52653A0F9C for ; Fri, 21 Aug 2020 10:58:39 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id l13so996445qvt.10 for ; Fri, 21 Aug 2020 10:58:39 -0700 (PDT) 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=lKfM+qCFNLWgONh5emPs4nsPI0yOhUWcPauH5T3omp4=; b=kaoW5ICWlttdtrdAglCOMb0Brx5+KNLdRExsuo8uIzMiuraagf9AYQyRCs/9E8n9uY bFhxr83Db/4Is6g/bCLKDZW0F3EC2Wb2X9h6hDe5If16FocXJiBh33jk6pKJtYf5nwa7 52ciVUUQnMWJOnEWpGIJue8Y6qw7+r2LPyDVx4mdZRDWxmb8E6tMqV9Fjv+TCZS61BQD JJiqTPS5NftU+o43+eu+7iRgHk36bA2p6pxzDmnGRouEkEV+jFr65zHO/g6kZ4i4PTBu +CZa8bdIguzOP4x/IC7zQdg7poyDYeYU9P+EQ6YWZDfnfbyI7+BmFamZIxBuvuaYWAzs QOjA== 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=lKfM+qCFNLWgONh5emPs4nsPI0yOhUWcPauH5T3omp4=; b=hHALLHHCJ4UpmzzoPdRT2QLrv/sDAY998b15EPOYfXG0yBD4syMa5HI8k0bgrPrtc/ CKRhrLMinqkb68T2xE9WsQZlSjos9XQ9vGSRCkjfdqZViCpJUFPl31i/EzNmEVgia21K FpunBwsNaj7QLLKlen6vgtUpo0KqcFxOX9sGgF2CP9Ra8HKeBG5771E54GdYRBHW/eTj MbobpQuRCC5jC5fcSnYpB9nmQ/9Rs1YxZg+LKFdhbPgpoamCkaNAttnDc8zTX+RL5kZM /+ypf8G4ePiSlPIDvC8jFDaOtLLLCP7o+CzzsUgf3GmUZdqy6RvD3IbfM1ctAEltV6OM JM2w== X-Gm-Message-State: AOAM533HtRl/f8y+IccZhb8LVIDQyYABnnNngMGEbrwa/HUaWghzI52H 6TC0+FAfszu9sq4yBhhICVA+S2RWKj5uJ1Egz1g= X-Google-Smtp-Source: ABdhPJxfu7A1TUGFev83sj9TfBEbBBFtv/jHdch/W1KNazbPv/ldZ5ViLKG9Ckr34OcIS6aXMiMUeCj+peie4isY7VQ= X-Received: by 2002:a0c:eb87:: with SMTP id x7mr3341074qvo.79.1598032718949; Fri, 21 Aug 2020 10:58:38 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> In-Reply-To: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> From: "Chris Box (BT)" Date: Fri, 21 Aug 2020 18:58:27 +0100 Message-ID: To: "Deen, Glenn" Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000008d708505ad66fc87" Archived-At: Subject: Re: [Add] ADD WG Github 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: Fri, 21 Aug 2020 17:58:41 -0000 --0000000000008d708505ad66fc87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > BTW =E2=80=93 I believe Chris Box is looking for additional contributors = to the > requirements doc. > > > Indeed I am, and also looking for feedback on whether this is a suitable structure to articulate the initial set of requirements. Direct links: https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirements= .html https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirements= .txt https://github.com/ietf-wg-add/draft-add-requirements Hoping to hear your suggestions on the list, the repo, or via any other means. Chris --0000000000008d708505ad66fc87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=C2=A0

BTW =E2=80=93 I believe Chris Box is looking for additional contributors t= o the requirements doc.

=C2=A0


Indeed I= am, and also looking for feedback on whether this is a suitable structure = to articulate the initial set of requirements.

Dir= ect links:

<= a href=3D"https://ietf-wg-add.github.io/draft-add-requirements/draft-add-re= quirements.txt">https://ietf-wg-add.github.io/draft-add-requirements/draft-= add-requirements.txt

Hoping to hear your suggestions on the li= st, the repo, or via any other means.

Chris
--0000000000008d708505ad66fc87-- From nobody Fri Aug 21 13:20:23 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 ADDA23A1228 for ; Fri, 21 Aug 2020 13:20:21 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=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 (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 LTiCk0IImJUo for ; Fri, 21 Aug 2020 13:20:19 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 E2DA43A1226 for ; Fri, 21 Aug 2020 13:20:19 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.43/8.16.0.42) with SMTP id 07LKKE5V061141; Fri, 21 Aug 2020 13:20:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=4Ci7xr2ibObQb7OW9grurApPQ7lRjw9LesBjyp4HAPg=; b=YKuREMh7mWCf1GdZEFMaqa9YjFrf28wJaf9oHmABIXjYKsrTy4n0580qyYTHrO4qxCd/ aBIe4156n5uy6Fip+reKjbuv0lHF2AUsWKgjpB2oKBfLpFts0xRH2mnN7HnVCFZSF3XT 136wJa0TMaHoSFsBovsiOfOpZWFQb5oDbR4su/jlLFzPaE21+m+TqA56/GXO07dsNf2r f0KgdYKSJBIoYVMkzRwLcwuJBT0ttwDYJ0WumVaKmxa82biMgMhQSanfkyTHHLCMU6pq HeZpYhJT4qvku0UyGZaMNSVMr/qxpnPVp/9nnQaxXtBUq9rCCK6DG+JIHvpPVsd/upIR uQ== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp02.apple.com with ESMTP id 32xc9jncbh-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 21 Aug 2020 13:20:16 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QFF009Q7KHJJF40@rn-mailsvcp-mta-lapp01.rno.apple.com>; Fri, 21 Aug 2020 13:20:07 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QFF00K00KF78V00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 21 Aug 2020 13:20:07 -0700 (PDT) X-Va-A: X-Va-T-CD: bc8aa1f2007b0bf815f1477c692805f9 X-Va-E-CD: da60ef7739dd767db9e5d64fc7b3d6c9 X-Va-R-CD: 749e6ef747a8f5742c49ee0161800877 X-Va-CD: 0 X-Va-ID: 8e6b6bb3-89c3-43a8-b8f9-c06d7f876ccb X-V-A: X-V-T-CD: bc8aa1f2007b0bf815f1477c692805f9 X-V-E-CD: da60ef7739dd767db9e5d64fc7b3d6c9 X-V-R-CD: 749e6ef747a8f5742c49ee0161800877 X-V-CD: 0 X-V-ID: 7a0d8fbb-c9d1-47c1-b338-2e196aa74f49 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-21_09:2020-08-21, 2020-08-21 signatures=0 Received: from [17.234.17.84] (unknown [17.234.17.84]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QFF00IMOKHHY500@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 21 Aug 2020 13:20:07 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_F4A006AB-5128-492D-85CF-DE8A70DFCF20" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Fri, 21 Aug 2020 13:20:05 -0700 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> To: "Chris Box (BT)" , "Deen, Glenn" , ADD Mailing list In-reply-to: Message-id: <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-21_09:2020-08-21, 2020-08-21 signatures=0 Archived-At: Subject: [Add] ADD Requirements Draft 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: Fri, 21 Aug 2020 20:20:22 -0000 --Apple-Mail=_F4A006AB-5128-492D-85CF-DE8A70DFCF20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, Since the requirements item had been discussed, but we hadn=E2=80=99t = yet seen document text, some of us have actually written up a draft for = the upcoming ADD discussions. This covers: - Use cases - Distilled discovery mechanisms (what the use cases can share) - Security and privacy considerations and threat analysis https://www.ietf.org/id/draft-pauly-add-requirements-00.html = https://datatracker.ietf.org/doc/draft-pauly-add-requirements/ = Chris, I think this covers many if not all of the use cases you = enumerate. I think it will be critical to include some analysis of what = privacy/security guarantees we expect out the discovery mechanism=E2=80=94= we tried to base this on the discussion on the list that was titled = =E2=80=9CMy principles for discovery=E2=80=9D. If people agree this is useful content, I=E2=80=99d say we should fold = this into the framework you=E2=80=99ve started, and build from there? Thanks, Tommy > On Aug 21, 2020, at 10:58 AM, Chris Box (BT) = wrote: >=20 >=20 > =20 >=20 > BTW =E2=80=93 I believe Chris Box is looking for additional = contributors to the requirements doc. >=20 > =20 >=20 >=20 > Indeed I am, and also looking for feedback on whether this is a = suitable structure to articulate the initial set of requirements. >=20 > Direct links: >=20 > = https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirement= s.html = > = https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirement= s.txt = > https://github.com/ietf-wg-add/draft-add-requirements = >=20 > Hoping to hear your suggestions on the list, the repo, or via any = other means. >=20 > Chris > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --Apple-Mail=_F4A006AB-5128-492D-85CF-DE8A70DFCF20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

Since the requirements item had been discussed, but we = hadn=E2=80=99t yet seen document text, some of us have actually written = up a draft for the upcoming ADD discussions. This covers:

- Use cases
- Distilled discovery mechanisms (what the use cases can = share)
- Security and privacy considerations and = threat analysis

https://www.ietf.org/id/draft-pauly-add-requirements-00.html
https://datatracker.ietf.org/doc/draft-pauly-add-requirements/<= /a>

Chris, I = think this covers many if not all of the use cases you enumerate. I = think it will be critical to include some analysis of what = privacy/security guarantees we expect out the discovery mechanism=E2=80=94= we tried to base this on the discussion on the list that was titled = =E2=80=9CMy principles for discovery=E2=80=9D.

If people agree this is useful content, = I=E2=80=99d say we should fold this into the framework you=E2=80=99ve = started, and build from there?

Thanks,
Tommy


On Aug 21, 2020, at 10:58 AM, Chris Box (BT) <chris.box.ietf@GMAIL.COM> wrote:


 

BTW =E2=80=93 I believe Chris Box is looking for additional = contributors to the requirements doc.

 


Indeed I am, and also looking for = feedback on whether this is a suitable structure to articulate the = initial set of requirements.

Direct links:

https://ietf-wg-add.github.io/draft-add-requirements/draft-add-= requirements.html
https://ietf-wg-add.github.io/draft-add-requirements/draft-add-= requirements.txt
https://github.com/ietf-wg-add/draft-add-requirements
=

Hoping to hear your = suggestions on the list, the repo, or via any other means.

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

= --Apple-Mail=_F4A006AB-5128-492D-85CF-DE8A70DFCF20-- From nobody Fri Aug 21 20:16: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 343163A094C for ; Fri, 21 Aug 2020 20:16:21 -0700 (PDT) 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 gPQ30uHdvtOY for ; Fri, 21 Aug 2020 20:16:20 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 D82BB3A094A for ; Fri, 21 Aug 2020 20:16:19 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id v138so1810819vsv.7 for ; Fri, 21 Aug 2020 20:16:19 -0700 (PDT) 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=FFMG/cErQ+/Kl0kOkoKnUUpFVkHByPUwOHMFbXkkNbo=; b=QIpxdEuyxtg4PcVzvXLt2MGmQC/TJRpx63xo+WJ1PyC2WAcAEDSqDlGi/pTHeZK51h vdB2ZiP0HOxCmHg+u4GT6NzR69sprWmHbGd5ScM4II0qwgRLkkMVmVsMWm+Yol0fQStd XgTcw+gnLCOFUzgH5aPmCL0C0czRJiQEiTW4zG1i0pHU4zyFSbNnjlDLIRRhj7Xe75O4 2CHLc5RHJT0YuZLEOI3AHq4mX3vNKB7JpdObJnbOdC3OiUi+bD6IOmDCKv0q9R0tt0Co Y9VRsV++LEEzd2JwjYeQyeODrYgl+e55NK7oCj0B3fscHMvkGoNnAEddJsDrUzOsygZh zDEA== 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=FFMG/cErQ+/Kl0kOkoKnUUpFVkHByPUwOHMFbXkkNbo=; b=fi8VpEJsE8wEjiWnR5wlvxhnjRhzB2vWRO1ZHjAh+T16djCr41GR7V0X3MBKf161B4 x5IyTo/pEuNLj+WH6pKAwddyXGLJ7LdFgtt4OBinBA56kX/bQppo2Nht6mSaV30uHC9/ OWNxcjyffoC3RQBYtr24mFBoWc/MroTMSUeE6jkMstK8UT7WuFHtyzVroblTOyX3VL8J rpzjUw1MbuOVpmC6vw9mYdo4DAiMKA1v77Fovkue5s36blFeTmvDOxCQzhNVNvSyxx6b sC1YzomM+1pkp6dN1N+QkkXLOZuTPLNI5M2RWekyJtcD3kggGK3tbv66FdVZczdGxJ6U vBdw== X-Gm-Message-State: AOAM533VNXEcPcTWYo9sF4+T0sibydp8Zp9sIZbidUMNmst0bY8cMv9q aN1hIlA31rSKwgkFJqCdtSHMfmriFTB+N6MK5rs= X-Google-Smtp-Source: ABdhPJyiklO8wMfpJ7VTv5yc+LCAiP4HgztWZmcJWGmL3RqFjY10wPG9Ie+eJ5V6rmbU/q3V880rQfP8WwyKcSAMkeE= X-Received: by 2002:a67:ed89:: with SMTP id d9mr3750168vsp.97.1598066178921; Fri, 21 Aug 2020 20:16:18 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> In-Reply-To: <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> From: Daniel Migault Date: Fri, 21 Aug 2020 23:16:07 -0400 Message-ID: To: Tommy Pauly Cc: "Chris Box (BT)" , "Deen, Glenn" , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000ec17cd05ad6ec64a" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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, 22 Aug 2020 03:16:21 -0000 --000000000000ec17cd05ad6ec64a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks for initiating the draft. I think that is useful and will provide more feed backs. That said, with a quick reading, it seems the document is more focused on use cases that result in a combination of initiation of the discovery, discovery and selection. I imagined requirements as a list focused on the discovery protocol. These requirements could be matched the discovery protocol designed by add. [1] was an attempt to do that. I am happy to to publish [1] as a separate draft and improve it in regard to the use case draft. Just for clarification, I think a use case draft is important. Yours, Daniel [1] https://tools.ietf.org/html/draft-mglt-add-rdp-02#section-4 On Fri, Aug 21, 2020 at 4:20 PM Tommy Pauly wrote: > Hello, > > Since the requirements item had been discussed, but we hadn=E2=80=99t yet= seen > document text, some of us have actually written up a draft for the upcomi= ng > ADD discussions. This covers: > > - Use cases > - Distilled discovery mechanisms (what the use cases can share) > - Security and privacy considerations and threat analysis > > https://www.ietf.org/id/draft-pauly-add-requirements-00.html > https://datatracker.ietf.org/doc/draft-pauly-add-requirements/ > > Chris, I think this covers many if not all of the use cases you enumerate= . > I think it will be critical to include some analysis of what > privacy/security guarantees we expect out the discovery mechanism=E2=80= =94we tried > to base this on the discussion on the list that was titled =E2=80=9CMy pr= inciples > for discovery=E2=80=9D. > > If people agree this is useful content, I=E2=80=99d say we should fold th= is into > the framework you=E2=80=99ve started, and build from there? > > Thanks, > Tommy > > > On Aug 21, 2020, at 10:58 AM, Chris Box (BT) > wrote: > > > >> >> BTW =E2=80=93 I believe Chris Box is looking for additional contributors= to the >> requirements doc. >> >> >> > > Indeed I am, and also looking for feedback on whether this is a suitable > structure to articulate the initial set of requirements. > > Direct links: > > > https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requiremen= ts.html > > https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requiremen= ts.txt > https://github.com/ietf-wg-add/draft-add-requirements > > Hoping to hear your suggestions on the list, the repo, or via any other > means. > > Chris > -- > 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 > --=20 Daniel Migault Ericsson --000000000000ec17cd05ad6ec64a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Thanks for i= nitiating the draft. I think that is useful and will provide more feed back= s. That said, with a quick reading, it seems the document is more focused o= n use cases that result in a combination of initiation of the discovery, di= scovery and selection.=C2=A0
I imagined requirements as a list fo= cused on the discovery protocol. These requirements could be matched the di= scovery protocol designed by=C2=A0add. [1] was an attempt to do that.
=
I am happy to to publish [1] as a separate draft and improve it i= n regard to the use case draft. Just for clarification, I think a use case = draft is important.


On Fri, Aug 21, 2= 020 at 4:20 PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
Hello,

Since the requirements item had been dis= cussed, but we hadn=E2=80=99t yet seen document text, some of us have actua= lly written up a draft for the upcoming ADD discussions. This covers:
=

- Use cases
- Distilled discovery mechanisms = (what the use cases can share)
- Security and privacy considerati= ons and threat analysis

https://datatracker.ietf.org/doc/draft-pauly-add-requirements/<= /div>

Chris, I think this covers many if not all of the = use cases you enumerate. I think it will be critical to include some analys= is of what privacy/security guarantees we expect out the discovery mechanis= m=E2=80=94we tried to base this on the discussion on the list that was titl= ed =E2=80=9CMy principles for discovery=E2=80=9D.

= If people agree this is useful content, I=E2=80=99d say we should fold this= into the framework you=E2=80=99ve started, and build from there?

Thanks,
Tommy


<= blockquote type=3D"cite">
On Aug 21, 2020, at 10:58 AM, Chris Box (BT) = <chris.box= .ietf@GMAIL.COM> wrote:


=C2=A0

BTW =E2=80=93 I believe Chris Box is = looking for additional contributors to the requirements doc.<= /span>

=C2=A0


Indeed I am, and also looking for feedback on whether this is a suitable = structure to articulate the initial set of requirements.

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


--
Daniel Migault
Ericsson
--000000000000ec17cd05ad6ec64a-- From nobody Sat Aug 22 00:50: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 DCF073A1072 for ; Sat, 22 Aug 2020 00:50:26 -0700 (PDT) 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 WYXkzFIfQcGz for ; Sat, 22 Aug 2020 00:50:25 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 218043A1071 for ; Sat, 22 Aug 2020 00:50:24 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id n129so3383405qkd.6 for ; Sat, 22 Aug 2020 00:50:24 -0700 (PDT) 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=xpTwsRAh1q79kqwHIQDoSZ8EbllA6t7paQ7rcqzB5O0=; b=OwyVPK+yrWMROvv9JyLccfzNh+FFX9VVXIufQKbi+eu1brhYCaQLQAhSl14mu8rmvp Yq2NhMSerX/VYFR9JmYbFjfiv/60pa3WacYz5r4ydFqgnNXtusW5ozgZ/TG+52Ob+HfM w4zVHyikbC5CnB06Y3Y7i9NjdutmTkGdJU7oyBc2OLjSsbjjNByohtI5hXdgDeGpQ7Zb AByjzhTh7UWIHUM+O7xmrXKcIE0K6c7URGB5r0nXrAePe6OFWphs0NuJXuCYt1g+JBKF biWe5WfAicGYYynhlG+65FuTzNHHiMCVaDwgAkFHuGiCzH1kavH47wlsX9s2DaLu2hKB vGuw== 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=xpTwsRAh1q79kqwHIQDoSZ8EbllA6t7paQ7rcqzB5O0=; b=fmIFz6H1mkYUNnTR8ap5N3n4i8e3/TYMLrfpjXy4DKmfxo/BViF/CZJv9cPF0kxgsa uBycDOtw1QYqBAVf000UZwoi7NLFy4UeX2wC71u7a76+BJVcs/kZZR7w/FgsOs4MXtVC fKozGnPByDsKjbqd29YU8C5Lc/I2Wl85AUwkYY+FmU2rHdJLiNgY7Sjd7YHZpB5Ht9LS c5u4Ilb63XM/VBpZi0cswScek3J7wdVUwyY9nJdYKHiM5xfB1JmySJA1b7IF+TxEv/oL HA9s2YuLPAjXieRsHTi3q/EztRCPi43aW+D/5voCFhvR3NgHzZoFh95KAMyDTDqb+/gK v5ew== X-Gm-Message-State: AOAM530XjCEUb7QEhjLVpQmW2g6kjCYDgkIgAXpRMgGqYXzLEfQS/hXz mgK0o6/UiDm0/DGcibw/CT9C9aNWIEsX1jWg8sY= X-Google-Smtp-Source: ABdhPJyQhXWaBMp4HqeBE+6HDJXXRdryvCZke7YQ3EaRuHyBuNS7asFZQeU1Ul6Bkx1KcjxiOhq4fzHd+JYtkaOIM7U= X-Received: by 2002:a05:620a:209b:: with SMTP id e27mr5693104qka.431.1598082623934; Sat, 22 Aug 2020 00:50:23 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> In-Reply-To: <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> From: "Chris Box (BT)" Date: Sat, 22 Aug 2020 08:50:13 +0100 Message-ID: To: Tommy Pauly Cc: ADD Mailing list , "Deen, Glenn" Content-Type: multipart/alternative; boundary="0000000000001f14ac05ad729be7" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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, 22 Aug 2020 07:50:27 -0000 --0000000000001f14ac05ad729be7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tommy, (+ co-authors) That=E2=80=99s a fantastic start. You=E2=80=99ve approached it from a sligh= tly different direction but it=E2=80=99s also more complete, and consistent. The text can definitely be folded in. Daniel, Could your desire for a single list of requirements be met by the =E2=80=9CRequirement Summary=E2=80=9D section of https://github.com/ietf-wg-add/draft-add-requirements/blob/master/draft-add= -requirements.md ? (Once suitably populated) Thanks Chris On Fri, 21 Aug 2020 at 21:20, Tommy Pauly wrote: > Hello, > > Since the requirements item had been discussed, but we hadn=E2=80=99t yet= seen > document text, some of us have actually written up a draft for the upcomi= ng > ADD discussions. This covers: > > - Use cases > - Distilled discovery mechanisms (what the use cases can share) > - Security and privacy considerations and threat analysis > > https://www.ietf.org/id/draft-pauly-add-requirements-00.html > https://datatracker.ietf.org/doc/draft-pauly-add-requirements/ > > Chris, I think this covers many if not all of the use cases you enumerate= . > I think it will be critical to include some analysis of what > privacy/security guarantees we expect out the discovery mechanism=E2=80= =94we tried > to base this on the discussion on the list that was titled =E2=80=9CMy pr= inciples > for discovery=E2=80=9D. > > If people agree this is useful content, I=E2=80=99d say we should fold th= is into > the framework you=E2=80=99ve started, and build from there? > > Thanks, > Tommy > > --0000000000001f14ac05ad729be7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tommy, (+ co-authors)
<= br>
That=E2=80=99s a fantastic start. You=E2=80=99ve= approached it from a slightly different direction but it=E2=80=99s also mo= re complete, and consistent. The text can definitely be folded in.

Daniel,
<= br>
Could your desire for a single list of requireme= nts be met by the =E2=80=9CRequirement Summary=E2=80=9D section of=C2=A0https://github.com/ietf-wg-add/draft-add-req= uirements/blob/master/draft-add-requirements.md ? (Once suitably popula= ted)

Thanks
Chris


On Fri, 21 Aug 2020 at 21:20, Tommy Pauly <tpauly@apple.com> wrote:
Hello,

<= /div>
Since the requirements item had been discussed, but we hadn= =E2=80=99t yet seen document text, some of us have actually written up a dr= aft for the upcoming ADD discussions. This covers:

- Use cases
- Distilled discovery mechanisms (what the use cases= can share)
- Security and privacy considerations and threat anal= ysis


Chris, I think this covers many if not all of the use cases you enume= rate. I think it will be critical to include some analysis of what privacy/= security guarantees we expect out the discovery mechanism=E2=80=94we tried = to base this on the discussion on the list that was titled =E2=80=9CMy prin= ciples for discovery=E2=80=9D.

If people agree thi= s is useful content, I=E2=80=99d say we should fold this into the framework= you=E2=80=99ve started, and build from there?

Tha= nks,
Tommy

--0000000000001f14ac05ad729be7-- From nobody Sat Aug 22 07:37: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 930E73A08D6 for ; Sat, 22 Aug 2020 07:37:55 -0700 (PDT) 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 4bSbGSMdMD3R for ; Sat, 22 Aug 2020 07:37:53 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 C68763A08D4 for ; Sat, 22 Aug 2020 07:37:30 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id e14so2255408vsa.9 for ; Sat, 22 Aug 2020 07:37:30 -0700 (PDT) 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=9uBSi+GycSO6jX4MWuqPhF16PKXW+DpzRGMIms+a3GA=; b=pAKg/hJwv1g5YISDV+2f8Xmlq8ooGGWbvR1BJoc3KQqjNRV/w0vmSAXkrsICBoxcii mGkGRt0dLh91O+bNf1JldE9cjS/2jBdXei5l8KJejupg6ojlA2jyGVjDWw0jL6rqflgS PhcVGnKtI1Iz9HV1pdqh1+lMzt8csPrHuEBT7A7LHY229L4NpUBKmnPY7unnQFMp7U8+ CqKhnS3GlXoV2U81vNP1uKLJugchbmIcENcFn54liGZl33Zasu+smK+pIyJefLpKHEdU 6UIrVgJtwxgj6gT5plfW+vwYibCV4M4KVAe00QgbUeLktnfhIRp+4S2A88p9he/DwJkj cFhQ== 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=9uBSi+GycSO6jX4MWuqPhF16PKXW+DpzRGMIms+a3GA=; b=MvyWmXOSm1GGst10ATZC/TeA9sTu5O2f/HVZ0rORt+ewK4nSncxQQW0DuZk814U1H/ nQPW/K/mWkTddtpZO9H3hQ22Q+kMn5grXBx6Bi2aCEM6TjZmBBVZLpw4OuKJEijP/Wyp EuvFUzv9KhzcfMozma0FepU2vqbgRbx8vDPI59qzXPNC21Gotu4p9f6Ihi2RXp4cIYpe Y+2j7bSKaRBmbAWoCqsEcnuE3AI9Pe/n8RwraPRemAnCl1dYrDIUU/bJ7z5AeuLwSaoe ARKjbIdCpff8onrCSrlR6E7lDdRJugCPEuKsV+yk1sJsKdL2yMt3eKGd97Q9eYFgL+uu Z12w== X-Gm-Message-State: AOAM5300PBKH94W9xUduaRCI26pDp3PoALrNsW9LifjcuHfu8deURy2P j6mIMojzOh9aptwF6WXBo0dykSO32DnnUxi4Tvw= X-Google-Smtp-Source: ABdhPJxTd8Sa23OMHCDGK3FXEQNsHokYuGK9eLq3DmYHitaIe2enEXiISYMLI9TQxPboo2bkvQg7pOeLlO4fdOh7MuE= X-Received: by 2002:a67:12c7:: with SMTP id 190mr4477475vss.180.1598107049864; Sat, 22 Aug 2020 07:37:29 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> In-Reply-To: From: Daniel Migault Date: Sat, 22 Aug 2020 10:37:19 -0400 Message-ID: To: "Chris Box (BT)" Cc: Tommy Pauly , ADD Mailing list , "Deen, Glenn" Content-Type: multipart/alternative; boundary="00000000000005341405ad784b1b" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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, 22 Aug 2020 14:37:56 -0000 --00000000000005341405ad784b1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Sat, Aug 22, 2020 at 3:50 AM Chris Box (BT) wrote: > Tommy, (+ co-authors) > > That=E2=80=99s a fantastic start. You=E2=80=99ve approached it from a sli= ghtly different > direction but it=E2=80=99s also more complete, and consistent. The text c= an > definitely be folded in. > > Daniel, > > Could your desire for a single list of requirements be met by the > =E2=80=9CRequirement Summary=E2=80=9D section of > > https://github.com/ietf-wg-add/draft-add-requirements/blob/master/draft-a= dd-requirements.md > ? (Once suitably populated) > sure. I will send a PR so there is a starting list for discussion. > > Thanks > Chris > > > On Fri, 21 Aug 2020 at 21:20, Tommy Pauly wrote: > >> Hello, >> >> Since the requirements item had been discussed, but we hadn=E2=80=99t ye= t seen >> document text, some of us have actually written up a draft for the upcom= ing >> ADD discussions. This covers: >> >> - Use cases >> - Distilled discovery mechanisms (what the use cases can share) >> - Security and privacy considerations and threat analysis >> >> https://www.ietf.org/id/draft-pauly-add-requirements-00.html >> https://datatracker.ietf.org/doc/draft-pauly-add-requirements/ >> >> Chris, I think this covers many if not all of the use cases you >> enumerate. I think it will be critical to include some analysis of what >> privacy/security guarantees we expect out the discovery mechanism=E2=80= =94we tried >> to base this on the discussion on the list that was titled =E2=80=9CMy p= rinciples >> for discovery=E2=80=9D. >> >> If people agree this is useful content, I=E2=80=99d say we should fold t= his into >> the framework you=E2=80=99ve started, and build from there? >> >> Thanks, >> Tommy >> >> -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --=20 Daniel Migault Ericsson --00000000000005341405ad784b1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

On Sat, Aug 22, 2020 at 3:50 AM Chris Box (B= T) <chris.box.ietf@gmail.com= > wrote:
=
Tommy, (+ co-authors)
<= br>
That=E2=80=99s a fantastic start. You=E2=80=99ve= approached it from a slightly different direction but it=E2=80=99s also mo= re complete, and consistent. The text can definitely be folded in.

Daniel,
<= br>
Could your desire for a single list of requireme= nts be met by the =E2=80=9CRequirement Summary=E2=80=9D section of=C2=A0https://github.com/ietf-wg= -add/draft-add-requirements/blob/master/draft-add-requirements.md ? (On= ce suitably populated)
<mglt>
= sure. I will send a PR so there is a starting=C2=A0list for discussion.=C2= =A0
</mglt>=C2=A0

Thanks
Chris


On Fri, 21 Aug 2020 at 21:20, Tommy Pauly <tpauly@apple.com>= wrote:
Hello,

Since the = requirements item had been discussed, but we hadn=E2=80=99t yet seen docume= nt text, some of us have actually written up a draft for the upcoming ADD d= iscussions. This covers:

- Use cases
- D= istilled discovery mechanisms (what the use cases can share)
- Se= curity and privacy considerations and threat analysis

<= div>https://www.ietf.org/id/draft-pauly-add-requirements-00= .html

Chris, I think this = covers many if not all of the use cases you enumerate. I think it will be c= ritical to include some analysis of what privacy/security guarantees we exp= ect out the discovery mechanism=E2=80=94we tried to base this on the discus= sion on the list that was titled =E2=80=9CMy principles for discovery=E2=80= =9D.

If people agree this is useful content, I=E2= =80=99d say we should fold this into the framework you=E2=80=99ve started, = and build from there?

Thanks,
Tommy

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


--
Daniel Migault
Ericsson
--00000000000005341405ad784b1b-- From nobody Sat Aug 22 14:07: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 E097E3A0FB2 for ; Sat, 22 Aug 2020 14:07:48 -0700 (PDT) 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=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 LRTl3jsBtx6T for ; Sat, 22 Aug 2020 14:07:46 -0700 (PDT) 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 8B1053A0FAE for ; Sat, 22 Aug 2020 14:07:45 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id f26so5528407ljc.8 for ; Sat, 22 Aug 2020 14:07:45 -0700 (PDT) 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=jjY1p8Xueesc9rNFjNFmf/FXOrSLOZSgyE+lQnlS74M=; b=yQmCM7as9www8NMogcLoQO3b8l2+zYZ1lUmoBKrRuk1/s9lnvlMd+1XOC/Dv17a30+ n20ZS1wftcOWJlPKsaBj6Z5qm67sOP1hRd5HWgoP9+wZ/pMR2H9wP6fOKZtScmFmEWtW nV6wAK2ilgyP0EgvkSBP4QcUOMukXCR8pf6ZJcspJ/OL087pZKU4AMGu8y9Ujg+ISono QJmmzZ611JDBe+bUOSWOnacm2VQnEc6DVlrTrU44Q7Heqm9EHyPEPls+Bv1TEJn1zAsL IXuWvDSqtyifwpX8uCt3p6TPrJEEVD7eyQOWvDoZfSZ5l2f7Zk9PEGijbNO+hYetp3LM 2I5w== 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=jjY1p8Xueesc9rNFjNFmf/FXOrSLOZSgyE+lQnlS74M=; b=tiqBTOEyEAS+fXYRvHCy2aRWoNdfxGFVJrzmR/nHrDQc/5sp3mVD+7woSUbarn57+T yU9/5bCiDz9yPXIcz5NoZNThRA3lugwrrLRQ6WOgneFPQfBrKBoQYCgwjxc0PUBkfbAj ZbwmyaMPVp+IFwyMQijvetXS7XE9NMGWBATdza82naVKXczXxzlLPfdp2RRD2N4ZhkmW zw2+0yL4WB86N0EPHtTlwIIG6mNGAPlohZN3J/+nj0ZES+dKsVjP+5L2YyGVfAZi1oNM iAVasEcnVbWOcARKAi0pjHYZsjCNF+bLtspDvuPcHsaxMMThQR+D1PyR6IUaWXcBvIXl He1A== X-Gm-Message-State: AOAM5313EzVLih14Kzov7ePL3oo08sYjAR6DeC9PYfSMlRt6FA8VmyCw 9KwifY+aOvJf6F+Zl8lb4ZaDt4OSLieUKWTg2oEgEQ== X-Google-Smtp-Source: ABdhPJzPxTMeWSS52QswphHSv8h6vm6Tb0inBtW3Z8nbaWx6N8o4jeVWX+O9vrw+MPSxzq58x1+Aqla3+GEigoHx2pM= X-Received: by 2002:a2e:b058:: with SMTP id d24mr4576445ljl.265.1598130463665; Sat, 22 Aug 2020 14:07:43 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> In-Reply-To: <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> From: Eric Rescorla Date: Sat, 22 Aug 2020 14:07:07 -0700 Message-ID: To: Tommy Pauly Cc: "Chris Box (BT)" , "Deen, Glenn" , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000097906205ad7dbef3" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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, 22 Aug 2020 21:07:49 -0000 --00000000000097906205ad7dbef3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Document: draft-pauly-add-requirements-00.txt Tommy, Thanks for posting this. Two comments on the threat model, requirements, and what mechanisms it leaves in scope. The points below are primarily about local discovery. 1. In S 4, you say you are assuming an RFC 3552 threat model that includes on-path active attackers. However, in S 2.1 you indicate that one of the benefits of this type of mechanism is to authenticate data coming from the true resolver: * Verify that answers come from the selected DNS resolver * Authenticate that the DNS resolver is the one provisioned by the network As a side note, I would observe that these benefits derive from the use of an authenticated channel, not from an encrypted channel. This is sort of a nit in that modern TLS profiles discourage authentication only, but I think it's still worth getting right. More importantly, this is only really true if either (1) the client can accurately determine the nonexistence of a secure resolver or (2) the client somehow behaves meaningfully differently in cases where it determines that there is no secure resolver. To lay this out in more detail, assuming that it's possible to determine the identity of a secure resolver if one is present (e.g., by the kind of SPAU mechanism that Chrome uses), then there are three cases: 1. The client connects to a secure resolver 2. No authenticated resolver is present 3. There is an attack While it's straightforward to determine whether one is in case (1), many users will be in case (2) and so as long as the client treats (1), (2), and (3) identically, then this doesn't preclude attack by on-path attackers. Thisisn't a new observation, of course, but I think it points to the need to sharpen the requirements and potentially S 4.2 if they are to be useful in the face of the threat model you define. 2. S 4 says that attackers must not be able to: * Redirect DNS traffic to themselves. If we try to map this onto the various proposed mechanisms, I think it has to be softened to say something like "Redirect secure DNS traffic to themselves when DNS traffic would not be" (again a 3552 attacker can say whatever they want in DHCP). I think this then precludes this mechanism having some kind of indicator of where the secure resolver is other than at its own IP. -Ekr On Fri, Aug 21, 2020 at 1:20 PM Tommy Pauly wrote: > Hello, > > Since the requirements item had been discussed, but we hadn=E2=80=99t yet= seen > document text, some of us have actually written up a draft for the upcomi= ng > ADD discussions. This covers: > > - Use cases > - Distilled discovery mechanisms (what the use cases can share) > - Security and privacy considerations and threat analysis > > https://www.ietf.org/id/draft-pauly-add-requirements-00.html > https://datatracker.ietf.org/doc/draft-pauly-add-requirements/ > > Chris, I think this covers many if not all of the use cases you enumerate= . > I think it will be critical to include some analysis of what > privacy/security guarantees we expect out the discovery mechanism=E2=80= =94we tried > to base this on the discussion on the list that was titled =E2=80=9CMy pr= inciples > for discovery=E2=80=9D. > > If people agree this is useful content, I=E2=80=99d say we should fold th= is into > the framework you=E2=80=99ve started, and build from there? > > Thanks, > Tommy > > > On Aug 21, 2020, at 10:58 AM, Chris Box (BT) > wrote: > > > >> >> BTW =E2=80=93 I believe Chris Box is looking for additional contributors= to the >> requirements doc. >> >> >> > > Indeed I am, and also looking for feedback on whether this is a suitable > structure to articulate the initial set of requirements. > > Direct links: > > > https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requiremen= ts.html > > https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requiremen= ts.txt > https://github.com/ietf-wg-add/draft-add-requirements > > Hoping to hear your suggestions on the list, the repo, or via any other > means. > > Chris > -- > 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 > --00000000000097906205ad7dbef3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Document: draft-pauly-add-requirements-00.txt

Tommy= ,

Thanks for posting this. Two comments on the threat model,
requ= irements, and what mechanisms it leaves in scope. The points
below are p= rimarily about local discovery.


1. In S 4, you say you are assum= ing an RFC 3552 threat model that
includes on-path active attackers. How= ever, in S 2.1 you indicate that
one of the benefits of this type of mec= hanism is to authenticate data
coming from the true resolver:

=C2= =A0 =C2=A0* =C2=A0Verify that answers come from the selected DNS resolver
=C2=A0 =C2=A0* =C2=A0Authenticate that the DNS resolver is the one pr= ovisioned by the
=C2=A0 =C2=A0 =C2=A0 network

As a side note, I w= ould observe that these benefits derive from the
use of an authenticated= channel, not from an encrypted channel. This
is sort of a nit in that m= odern TLS profiles discourage authentication
only, but I think it's = still worth getting right.

More importantly, this is only really tru= e if either (1) the client
can accurately determine the nonexistence of = a secure resolver or (2)
the client somehow behaves meaningfully differe= ntly in cases where
it determines that there is no secure resolver. To l= ay this out in
more detail, assuming that it's possible to determine= the identity
of a secure resolver if one is present (e.g., by the kind = of SPAU
mechanism that Chrome uses), then there are three cases:

= 1. The client connects to a secure resolver
2. No authenticated resolver= is present
3. There is an attack

While it's straightforward = to determine whether one is in case (1),
many users will be in case (2) = and so as long as the client treats
(1), (2), and (3) identically, then = this doesn't preclude attack by
on-path attackers. Thisisn't a n= ew observation, of course, but I think
it points to the need to sharpen = the requirements and potentially
S 4.2 if they are to be useful in the f= ace of the threat model
you define.


2. S 4 says that attacker= s must not be able to:

=C2=A0 =C2=A0* =C2=A0Redirect DNS traffic to = themselves.

If we try to map this onto the various proposed mechanis= ms, I think it
has to be softened to say something like "Redirect s= ecure DNS traffic
to themselves when DNS traffic would not be" (aga= in a 3552 attacker
can say whatever they want in DHCP). I think this the= n precludes this
mechanism having some kind of indicator of where the se= cure resolver
is other than at its own IP.


-Ekr









On Fri, Aug 21, 2020 at 1:20 PM Tommy Pauly <tpauly=3D<= a href=3D"mailto:40apple.com@dmarc.ietf.org" target=3D"_blank">40apple.com@= dmarc.ietf.org> wrote:
Hello,

Since the requirements it= em had been discussed, but we hadn=E2=80=99t yet seen document text, some o= f us have actually written up a draft for the upcoming ADD discussions. Thi= s covers:

- Use cases
- Distilled discov= ery mechanisms (what the use cases can share)
- Security and priv= acy considerations and threat analysis

=

Chris, I think this covers many if = not all of the use cases you enumerate. I think it will be critical to incl= ude some analysis of what privacy/security guarantees we expect out the dis= covery mechanism=E2=80=94we tried to base this on the discussion on the lis= t that was titled =E2=80=9CMy principles for discovery=E2=80=9D.
=
If people agree this is useful content, I=E2=80=99d say we s= hould fold this into the framework you=E2=80=99ve started, and build from t= here?

Thanks,
Tommy

=

On Aug 21, 2020, at 10:58 AM, = Chris Box (BT) <chris.box.ietf@GMAIL.COM> wrote:


=C2=A0

BTW =E2=80=93 I believe Chris Box is = looking for additional contributors to the requirements doc.<= /span>

=C2=A0


Indeed I am, and also looking for feedback on whether this is a suitable = structure to articulate the initial set of requirements.

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000097906205ad7dbef3-- From nobody Mon Aug 24 09:33: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 850363A0DEF for ; Mon, 24 Aug 2020 09:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, HTML_OBFUSCATE_05_10=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 RZjJw_WsZyY1 for ; Mon, 24 Aug 2020 09:33:17 -0700 (PDT) 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 02FDB3A0C6D for ; Mon, 24 Aug 2020 09:33:16 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id o12so3285050qki.13 for ; Mon, 24 Aug 2020 09:33:16 -0700 (PDT) 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=gGOOPovm1uhwRbikmC1tjEYq1Z/jabqRpW8OgSAuP4A=; b=sxklompXG6XPrnzCxVfPBhI9C16T/134TW5wMa7ZCqj7ydf0cgrTZsvKVw9WDdc6yN sL8OCf6wyAFVaBzDNhX0dK1jd2TmvBPmXjM3oVly01Q5T/zPZOCyjDGi09oOsvAZVjJX 1T42EByekNzPscR8jQgxblYAKpbGBF9MBn6DMyIhENoajoP8ObK3rAkBfIVUvSX4qgr3 BUBjPLhCSBIh62Uwo4543RZL1t5wto56e+V3WY0/t7gDdSs/HA9HX4R1BR/jDT+yNH/t LfLu4GhB8zWXKicllJcZYVamsRSAiMva77ACnxumKgmviVDQfAkYFPBiid+RzbcEy88E SJoA== 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=gGOOPovm1uhwRbikmC1tjEYq1Z/jabqRpW8OgSAuP4A=; b=mep7W+hT5vP6mcYesssCDm7pdu2IfFPSvziwAPnQ/RXS+KwGSvhCKfOr5PCAIUW1GK y52O3edMPpmbaZi4Jvd6ilXVN/zV2nFNIXzuS2AfGfCzyLRwx8fJG2D51DG0FQutQ7Q7 A3+QDbslt+ObupmLpMp2HNNFSWs7RQEIEMcB2zHz5H3WJyREKPspmWEh6gTiDAtuIkDK n1Bn9Z+AcToSivgwKkdriZnGw4WWTyzxPZOrEgp53SoSEKlVQxQHWy4iyyoZLmzh04kr Iw3Vuzcw/O3f69qP2+iX3UizG7QLwwIyA83tNxjSSPsbxl7O6CKkaAYJca1JzOdBRnr0 bhmw== X-Gm-Message-State: AOAM533lwNPXn55FagRCwSml5vYEX5lVG499bjPZV50GcAtK4rvpnukv paIRM9IyUFiifh0BOrkSJ79Gc1lpS0jcdraie/P2zLQofGQOwg== X-Google-Smtp-Source: ABdhPJywMitOhtJ8ruDOOBwBEP5yB5OujUcft4pbrJJVIKTET0zXkGkdJMlYaVRec6Cvf27h8QB8fM+p6sefaoY511I= X-Received: by 2002:a05:620a:209b:: with SMTP id e27mr5221746qka.431.1598286795798; Mon, 24 Aug 2020 09:33:15 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> In-Reply-To: From: "Chris Box (BT)" Date: Mon, 24 Aug 2020 17:33:04 +0100 Message-ID: To: Tommy Pauly Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000b687e805ada224f7" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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, 24 Aug 2020 16:33:19 -0000 --000000000000b687e805ada224f7 Content-Type: text/plain; charset="UTF-8" Tommy, Here's how I propose to map the content in your draft into the working group's draft. I'd appreciate comments from anyone on whether this looks about right. If it is, I'm happy to do the work tomorrow, or if someone wants to create the pull request that'd be great too. draft-pauly-add-requirements draft-add-requirements Take content from Merge into 1. Introduction 1. Introduction 2.1. Network-provisioned resolvers 3.1. Discover resolvers associated with one declared by an attached network 2.2. Client-selected resolvers 3.2. Discover resolvers associated with a manually-configured resolver 2.3. VPN resolvers 3.3. Discover resolvers associated with a VPN-configured resolver 2.4. Encrypted resolvers for private names 4.1. Discover a mapping between a locally-hosted domain and a resolver, and 4.1.3. Private enterprise names 2.5. Encrypted resolvers for local or home content 4.1.1. Walled garden content 2.6. Encrypted resolvers for content providers 4.2. Discover a mapping between a public domain and a resolver 3. Discovery mechanisms Partly covered by the splitting of this draft into section 3 (Discovery of associated resolvers) and 4 (Discovery of limited domain resolvers). Content could be copied into the beginning of both of these. 4. Privacy and security requirements New section prior to 5. Requirements Summary, so that these requirements can be populated into the summary. Maybe we then don't need the existing "Security Considerations" section? One thing I do notice is that your section titles are more human-friendly, so we could also consider similar titles in draft-add-requirements. Thanks Chris P.S. Still seeking additional authors, so please contact me directly if you're willing to be such. I could do with *at least* one author from draft-pauly-add-requirements. (Tommy, Eric, Chris, Patrick, Tommy) --000000000000b687e805ada224f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tommy,

Here's how I prop= ose to map the content in your draft into the working group's draft. I&= #39;d appreciate comments from anyone on whether this looks about right. If= it is, I'm happy to do the work tomorrow, or if someone wants to creat= e the pull request that'd be great too.

draft-pauly-add-requirements draft-add-requirements
Take content from Merge into
1. Introduction 1. Introduction
=C2=A02.1. Network-provisioned resolvers=C2=A0 =C2=A03.1. Discover resolvers asso= ciated with one declared by an attached network=C2=A0
=C2=A02.2. Client-selected resolvers=C2=A0 =C2=A03.2. Discover resolvers asso= ciated with a manually-configured resolver=C2=A0
=C2=A02.3. VPN resolvers= =C2=A0 =C2=A03.3. Discover resolvers asso= ciated with a VPN-configured resolver=C2=A0
=C2=A02.4. Encrypted resolvers for private names=C2=A0 =C2=A04.1. Discover a mapping betw= een a locally-hosted domain and a resolver, and 4.1.3. Private enterprise names=C2=A0
=C2=A02.5. Encrypted resolvers for local or home content=C2=A0 =C2=A04.1.1. Walled garden content= =C2=A0
=C2=A02.6. Encrypted resolvers for content providers=C2=A0 =C2=A04.2. Discover a mapping betw= een a public domain and a resolver=C2=A0
=C2=A03. Discovery mechanisms=C2=A0 Partly covered by the splitting of this draft into section 3 (Discovery of associated resolvers) and 4 (Discovery of limited domain resolvers). Cont= ent could be copied into the beginning of both of these.
4. Privacy and security requirements New section prior to 5. Requirements Summary, so that these requirements can = be populated into the summary. Maybe we then don't need the existing "Security Considerations" section?

One thing I do notice is that your section titles are more human-frien= dly, so we could also consider similar titles in draft-add-requirements.

Thanks
Chris

P.S.= Still seeking additional authors, so please contact me directly if you'= ;re willing to be such. I could do with at least one author from dra= ft-pauly-add-requirements. (Tommy, Eric, Chris, Patrick, Tommy)

--000000000000b687e805ada224f7-- From nobody Mon Aug 24 15:46: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 484993A0E84 for ; Mon, 24 Aug 2020 15:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=comcast.com header.b=j30ts9Oq; dkim=pass (2048-bit key) header.d=comcast.com header.b=fZx+fRQ/; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=lzscpuAj 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 zkt8ZogVrpOG for ; Mon, 24 Aug 2020 15:46:20 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.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 5FC0D3A0E72 for ; Mon, 24 Aug 2020 15:46:20 -0700 (PDT) Received: from pps.filterd (m0184893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07OMii8f019485 for ; Mon, 24 Aug 2020 18:46:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : mime-version; s=20190412; bh=cchH5mnWwNZDgrHc3hy49lZX8gXjDc61qPjHaX/TqeE=; b=j30ts9OqjK7jYvSrdh2Cqaw2z7gnHZe/njXZnTPVhu8Dr42QwvElRmbo3kZP/NvMzQt0 LQU7il4RFI0B5CIRVlHMOODRuLIqXnhPwOVn+Nra0rlg9EHlbhQ4NewnROnLNxis+n4s yvEIRBrVTGEpFoiY3R1QLMyww77y0qE9EbdrTzvJakGycutRtFw+JzvTt/g1zK7DHWof JrJZiRUyIm5A5Mk4VL8eEspcFpo/CxAsj81dbPnloMMvzsbPKOeEml7xfTCIgXtNJCAf C4PTQnHudqJ53AQlQaNKHy0p9jr3tKu+Km/P6NpNrUs2YuoMREd5LzNMDVYgHWuTK3Gx kw== Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) by mx0a-00143702.pphosted.com with ESMTP id 332xheuknn-31 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 24 Aug 2020 18:46:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1598309179; x=2462222779; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cchH5mnWwNZDgrHc3hy49lZX8gXjDc61qPjHaX/TqeE=; b=fZx+fRQ/cxRiHqOTMvg3J4dyXY/iNGNmHSq1+6NMU+yhYGlL9IEbAt0S2fPwWfH6 p2fiyK8gylq2tuPc1klgBaLxvzylB2BqssFvtqkSqkS8vfX8+vzURXfC35dT7iXj /ARmH5m9RVDthAQLWmY0f8VPZLBzWWHAerEmeoKU9wsM/YT0DWiY/6poxB0NhiHT AJ0QtbYIa2BgNaDitcMtCecE2OyXjiXJXwNaQfn1Fsuu1A1Pf1vW5y56HZRHBUYj iXK2N7Rx+SXmDgR2n8mAzEeodeFhx4AdYnRKoUfWqe1Yc4lOR3FQaQkLSGvwRbJ1 wtlgVGsnj1/PbTstHQPepw==; X-AuditID: 44571fa7-3fdff70000018e96-fd-5f44433b348e Received: from PACDCEX51.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 4F.4D.36502.B33444F5; Mon, 24 Aug 2020 18:46:19 -0400 (EDT) Received: from PACDCEX47.cable.comcast.com (24.40.2.146) by PACDCEX51.cable.comcast.com (24.40.2.150) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Aug 2020 18:46:18 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX47.cable.comcast.com (24.40.2.146) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 24 Aug 2020 18:46:18 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.168) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Aug 2020 18:46:18 -0400 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BYAPR11MB2837.namprd11.prod.outlook.com (2603:10b6:a02:c6::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Mon, 24 Aug 2020 22:46:17 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6%7]) with mapi id 15.20.3305.026; Mon, 24 Aug 2020 22:46:17 +0000 From: "Deen, Glenn" To: ADD Mailing list Thread-Topic: IPR Disclosures to ADD WG Thread-Index: AQHWemhgLCpZ8O78CU2nmVqPWUWEaw== Date: Mon, 24 Aug 2020 22:46:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:d497:24e1:ed7b:974a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1174b7dc-d0a7-4f3c-ef24-08d8487f8353 x-ms-traffictypediagnostic: BYAPR11MB2837: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +8u7wLRUArz3DLpABOgj+6vtsCOx5HLMeJtuhj/bcO4IDlqV2r9v/SCdSvFWSk9mlk4OB07N+0gRJEOPdr2YVjTrpvvf6bgxifDtu4Tv71fom95LP9s4p7mutxifklQT8sFhZYZ24FYLdIkO5Lrux0MFZgOpcEcwP9PPSbT9ZVV0bywEwRCEtwbQBznzS8JYWLlb5Sh3MY+o5Ye/pnwAeDQElVKLZrkR8FomGWNiuyI0/roiuWorCEicWMxKjMAITWMmEzt2bUSNU3QF1Cgnfik+6RMgkfRb22Cb+JhWiOYZS9e9X+nOoi8t1DG/VaJkSxjul85j1QZwQNG3ZcxcSvBJcrA+XYmMzi/TcIU+Ycx8FhX+1Ytl0fJHeIkZe+xZ3WwOJeXSIfHP3dRUvFyjEA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(346002)(396003)(136003)(366004)(8676002)(316002)(5660300002)(966005)(66446008)(8936002)(4744005)(6506007)(66556008)(478600001)(33656002)(2616005)(83380400001)(6916009)(66946007)(76116006)(2906002)(64756008)(66476007)(166002)(36756003)(186003)(71200400001)(6486002)(6512007)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Uud6VcsSYpRAUA9Fq+YVOCgH/b2AFn6Pg6fRw6sOmmSa5v/dUurBoQcO8SJFCQLpwztWqt0Hdw9cdcE6hIdqFDsKHukvTqpJLNnA/l33p6CJwbynC7EIRaouZ2pLEHuo7Di0SlCjJCxDs3+o3NeHrjvMXTMfXzm6fzypfP6k8exTH3DpSyEj2XlRghtUOD4N7l3L7RR8pxR1Dz2Y7l1WOzcZ/7zaRXu9FniV5Y8REYQ03k9J/mv1+7D4mAYJUIiVyZptrGaQSMcAm4w3un9cFBcRN7+8w7XFut957LdoS0L5uK2FrRdaIQTSVyk08A82Ua50pAolBaOV0XteWTZ3f0XOSsLQa32LGpWTxsUiy5Dv5hqXLyGDpDyeGdlJYZCUzwwonjQGejrk3/AkXglDcANxnYnFMTBMNgpALSqEspRgoPctVp6/6T7Io/c5up+DQ7Dmtas/3x7YPcvRhyD89F/SA+jKhDSFKPUESXLBZAWjGI2Lz0Q9NOjKLTHRQagztF3iOPl2cr7c1zY0XjzB9+zx2vvdMg9lCTIIfSiIE2AY9JX33DGA0FhcPr/WN95T9rdRkuWuwitoUqvCbz+CVA0nk4S8s8r6sY+Lt3AtmwTWYNqbbKZeOgwzf1YzMWS4fdbe1BtEC6G9VteM/F6WmUF6jigm/WXS8nawodJQYRTG5en/UrVIRvbTN5sf03c7jBi1I4uTfP6mMfaG3exZDg== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FxhHQPmo+X/HzVe1iHBNzHvyFCXV1YHFqjtrOqnyEqR52nxgO+o4sKqZvJgGZdjokT/w7xrZ+2xLvSLSSNx8ig0u1nfkrbQ9lcVecn4M9f/BcR22IhWJoIh830+IIWiZ/5VOc+iphRx1Pek4fv+MxIzJN36hLdeLX/f864hv7W5Hx0ilx2v+ZvNy8THf5BtoxhvMhtkcvSkBNuH6U59DQnmxLdoYZ9lnU29Xvm3rM9dR8vGOatPBS/snQsCHphQAhiL1Rftc8LyHIhqqUiGsthmKbfjtBJyUM8c9d42D3jN29rf4plQKy+ha3YzviA9C3apj3hADQr5TYRsepxislg== 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=oMD3hw+xllwBVHy9veqsD/PQgqhaPX1egUB2YV0+umE=; b=kYVypacl/P0HLKtqoLagRVw3DtreAfbyYOR0HShRsNJkJQlPOqBkmdFOufd8E10ecgD4xzbb1VBOFGXJ0pglmxr0s7GfIRVRbitBb7ZCXFUgSRXjh/58qMKcwt0AZxn2hnCbMQsbqgnen9i/BurdLqIp4wLcM/6xZu2VJzwBVSReq98tjxpePdbfmKWkrKDqWyZkdVkZyJH1TFqzSUUdMhW96P1u0e50VsFGg2XYF2Gvbxg8qglugP0fv8/X+BtJHJxXE6rtpvifNtJepxeVGV6o0a0NyeFpsrqxqoNg6Ra04G3kVQHZj4+mRaJMlKQSoObnWSa7KbKLFspWAaWexw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oMD3hw+xllwBVHy9veqsD/PQgqhaPX1egUB2YV0+umE=; b=lzscpuAj9/6SbbeAmK6saVNWjbkcVBZTFq3eB6PnYLkrGHGmAOoen3gaNNqy5VgIuE0cLtCKgafsRnPL0h7SaKh8Ha/5/P2uMjknNpArbwHMcQxDaheZBFqiKCX4Nz6+VfGM8TQHfgzn+mkE6XjpTg0IkvSVq+Ni3UN750B1Eqw= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 1174b7dc-d0a7-4f3c-ef24-08d8487f8353 x-ms-exchange-crosstenant-originalarrivaltime: 24 Aug 2020 22:46:17.2878 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: qHyWXcH7mNXBxrU5dBd/qsKvust6XeCxDAbSur3pzLKTGuFlmuXK52rMYR9ZoAwU0/rOGa2w1Ow9LdOnYUh7zHbO9NQq4xMnsdhex3MyWL8= x-ms-exchange-transport-crosstenantheadersstamped: BYAPR11MB2837 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_BAFF3577EA5048AC8DBDD9BD6715A56Dcomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHO3vfba/m4DhvD2pWr5llOVuKmoUlDpLKsi8JXZwL39S8JNsU V32wzLCZME0/ODUFFWGuhARNu8kaRq1QI0kGZV6iNSaIF0aYVq9ngd9+/+f5Pec5Bw5DSVuE wUx+sZZTF6sKWZE3rchkQ6MPpyqUB+53Byb+sT0WHUNpnZ2/BBnovPeRHK4wv4xTxyRne+dV PKoUl/SEl9/uYypQO6tHXgzgOFgecoj1yJuRYqsAWuumaRKGEMyZWwQkTCAw9I97OiMI6qv7 PTMdAnDOTHm0GQRjd/kZhhHh/dDfd5Rf4o/DoevLgIBnP8yCaf4OzSv+OBLmF64QRQbvXXaa ZxpHwOiiTcwrEpwMn+0pfBnhQHC/M2+cQuEgsM+1CcgTMHQ+H6UIB8DP2XUhPxqAY8D5VcFf DGE9Aqd+GPF1wEnwpiec6NvgY1sNIpwO9xxmAVGiYK3qFCkXwKqtUUh4N0y6qj2bwsBUO00T DoVvkwMifhXgZxRMvqynSJilwGyaEpLwWwhzayueDbtg3aIzILlx03MIX4am77eEPEuwL7xt mqON/yYovBd6h2KIshMaaqbFhPdAVUurmChpsNqTsVlpR4wJ+cQnyhITZLFymTw+4Qna+DPb u5+iAWOeBWEGsT6SVykKpVSoKtPoiiwIGIr1l/iOpyqlkhyV7jqnvqZUlxZyGgsKYWg2SGKY cGRJca5KyxVwXAmn/t8VMF7BFYgNycrWjrUuHKxzD9YaZ5p/xJeO1WdtKR5Myt93VTrUGNC1 dJHNXVkKtJ47ZAiYH83b+iBh1hnhst64uaOzVz2S/Lo52l3uc7rP98PD4IYQ6wn/5bBFcYNC eSnyk11eLhk+3r9S6afLdBSdcb/IcJ29IJJqtVVZUbZYVVx6x8k4ltbkqeRRlFqj+gtgQk35 LwMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-24_12:2020-08-24, 2020-08-24 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Add] IPR Disclosures to ADD WG 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, 24 Aug 2020 22:46:23 -0000 --_000_BAFF3577EA5048AC8DBDD9BD6715A56Dcomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QUREIHBsZWFzZSBiZSBhZHZpc2VkIHRoYXQgMyBuZXcgSVBSIGRpc2Nsb3N1cmVzIGhhdmUgYmVl biBzdWJtaXR0ZWQgcmVsYXRpbmcgdG8gdGhlIEFERCB3b3JraW5nIGdyb3VwIGJ5IFZlcmlzaWdu Lg0KDQpCVFctIFRoZXNlIHdlcmUgc3VibWl0dGVkIHdpdGhvdXQgcmVmZXJlbmNpbmcgYW55IHNw ZWNpZmljIGRvY3VtZW50IHNvIHlvdSB3b27igJl0IHNlZSB0aGVtIGlmIHlvdSBsb29rIGF0IHRo ZSBsaXN0IG9mIEFERCBkb2N1bWVudHMgaW4gZGF0YXRyYWNrZXIuDQoNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByLzQyNTYvDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lw ci80MjU3Lw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvNDI2MS8NCg0KdGhhbmsg eW91LA0KR2xlbm4gRGVlbiwgQUREIGNvLWNoYWlyDQo= --_000_BAFF3577EA5048AC8DBDD9BD6715A56Dcomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <640C907B49B7A5489ED5D6A7E72D4100@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCWNvbG9yOndp bmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFERCBwbGVhc2UgYmUgYWR2aXNlZCB0aGF0IDMgbmV3IElQUiBkaXNjbG9zdXJlcyBoYXZlIGJl ZW4gc3VibWl0dGVkIHJlbGF0aW5nIHRvIHRoZSBBREQgd29ya2luZyBncm91cCBieSBWZXJpc2ln bi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CVFctIFRoZXNlIHdlcmUgc3VibWl0dGVkIHdp dGhvdXQgcmVmZXJlbmNpbmcgYW55IHNwZWNpZmljIGRvY3VtZW50IHNvIHlvdSB3b27igJl0IHNl ZSB0aGVtIGlmIHlvdSBsb29rIGF0IHRoZSBsaXN0IG9mIEFERCBkb2N1bWVudHMgaW4gZGF0YXRy YWNrZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvaXByLzQyNTYvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci80 MjU2LzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzQyNTcvIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2lwci80MjU3LzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzQyNjEvIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci80MjYxLzwvYT48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhIj50aGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5H bGVubiBEZWVuLCBBREQgY28tY2hhaXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BAFF3577EA5048AC8DBDD9BD6715A56Dcomcastcom_-- From nobody Mon Aug 24 16:40:30 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 65BD33A0A96 for ; Mon, 24 Aug 2020 16:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 wP_yMBuNomoF for ; Mon, 24 Aug 2020 16:40:27 -0700 (PDT) Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 216A23A0A90 for ; Mon, 24 Aug 2020 16:40:27 -0700 (PDT) Received: by mail-oo1-xc36.google.com with SMTP id k63so2310955oob.1 for ; Mon, 24 Aug 2020 16:40:27 -0700 (PDT) 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=YED66wQWW3uLjGNRWmxBdQ/zzMmbWH5z++pEeoenKQ8=; b=gqab6Qxct6fAqGcRWw17ufkghKaoDiqaHY52/wBDNg/tWzwQDVOwEIAfojn8GH/nng zFN5YJW4ct9zSCyY9v/rpR/s4WuOCYI4cKtcNczNB410No2gqVSMwv1b7HJgxeipuqOJ kWsw54lhHUZk5+IR+ZJmXCwFtnHfcvnrXHEoxjwbq+8mty0VrHhfHge7mmzFEW0l9rnL mjIm4D3CUpQG3eTYbAZ7ZcAXL9yyBqvUcURbsfWQEsZUmSjFwWXfFF2mCFuJaskfBScX d4mz/mQYBW8B1zOue91tJHeatQfvPMa9ttdMCIMrHZdd6A6IBrNEVROJ7S0x3wEYu0I5 +0KQ== 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=YED66wQWW3uLjGNRWmxBdQ/zzMmbWH5z++pEeoenKQ8=; b=A3VrO1VW+kJ2pL96E3k+2xRd5xz2Aof8Ua8NvEFkscVoSc9LuB299eAIYLHR27p3Pt QFF6eGfu0vXJd+eV4AgVfIX29msGZjsul56LMXzcB2uGKbN4f36K7MDQB0e+As0EB2Pm 59k4G8/h8zmE1vorH/bTLp8C3dojMzBdhppRUgpC2gJ8FOh3QiiAOpNr1OpaT3nAkxQb AdJpi7299+PybxpKKBJS/TRX7xlN89foUM7XVtynEdtD+kW8zJrMnyyy4+ANZE1LoBbh KE1Ck5t2QWiIM/89j0Tk8APLlNBuigV8MRSY7G2coy0nXqOwee+dnSWoHpU1Ui5tIji3 joFg== X-Gm-Message-State: AOAM531dxuLaOrBpzkRyO4F3ehrACcAkiVRKnc00o6lIGhhFdUcU/OS4 0456QCGALERwpapwvwGTcNr1GVJa6HDLClozFzA= X-Google-Smtp-Source: ABdhPJxDjwpv8RFn93EcP3rg6e8Szca0r+Lvzu6GEhaTvkHwueh+wXKMuvQlAetdUSiQz442fgAhxULx1YcogLY5yL4= X-Received: by 2002:a4a:8d95:: with SMTP id i21mr5299753ook.67.1598312426309; Mon, 24 Aug 2020 16:40:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Mon, 24 Aug 2020 16:39:59 -0700 Message-ID: To: "Deen, Glenn" Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000690e1205ada81cc3" Archived-At: Subject: Re: [Add] IPR Disclosures to ADD WG 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, 24 Aug 2020 23:40:28 -0000 --000000000000690e1205ada81cc3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Glenn, 4261 appears to be an update to the disclosure #4257--is there are another, independent claim or are the two claims (and 3 disclosures) the full set you wanted to call out to the group? regards, Ted On Mon, Aug 24, 2020 at 3:46 PM Deen, Glenn wrote: > ADD please be advised that 3 new IPR disclosures have been submitted > relating to the ADD working group by Verisign. > > > > BTW- These were submitted without referencing any specific document so yo= u > won=E2=80=99t see them if you look at the list of ADD documents in datatr= acker. > > > > https://datatracker.ietf.org/ipr/4256/ > > https://datatracker.ietf.org/ipr/4257/ > > https://datatracker.ietf.org/ipr/4261/ > > > > thank you, > > Glenn Deen, ADD co-chair > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000690e1205ada81cc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Glenn,

4261 appears to be= an update to the disclosure #4257--is there are another, independent claim= or are the two claims (and 3 disclosures) the full set you wanted to call = out to the group?

regards,

Ted

On Mon, Aug 24, 2020 at 3:46 PM Deen, Glenn <Glenn_Deen@comcast.com> wrote:

ADD please be advised that 3 new IPR disclosures hav= e been submitted relating to the ADD working group by Verisign.

=C2=A0

BTW- These were submitted without referencing any sp= ecific document so you won=E2=80=99t see them if you look at the list of AD= D documents in datatracker.

=C2=A0

https://datatracker.ietf.org/ipr/4256/

https://datatracker.ietf.org/ipr/4257/

https://datatracker.ietf.org/ipr/4261/

=C2=A0

thank you,

Glenn Deen, ADD co-chair

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000690e1205ada81cc3-- From nobody Mon Aug 24 16:50: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 9AAC23A0AA5 for ; Mon, 24 Aug 2020 16:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SPOOFED_URL=0.001, SPOOFED_URL_HOST=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=comcast.com header.b=fG+up2Ax; dkim=pass (2048-bit key) header.d=comcast.com header.b=YzvIDpHY; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=Nmai158Q 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 zk-b0Kp4dm-2 for ; Mon, 24 Aug 2020 16:50:20 -0700 (PDT) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.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 7EDA93A0AA4 for ; Mon, 24 Aug 2020 16:50:20 -0700 (PDT) Received: from pps.filterd (m0184890.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07ONnqTi032169 for ; Mon, 24 Aug 2020 19:50:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=20190412; bh=NOYnXlslUL2RR8Wd1Y6ychsET0vv8dGXqq7KqEiLB+4=; b=fG+up2AxdVIoiFi1g/uKDMGx91hMkTdmHNPhVT68ntHc9H/Gaq2KwywBKMWTaJ/uLmEb DrkEMJvcjK2rli67ZD1wc+3QOjGYuM8+OcAISNxmjf8xuJ0+qy4g6TeuIIqAdPIym2Eh 2yN8j2GMPwUEH350LAfUy5hmIRfwS+dpsbHBOR+4F8EFhDEqs0JUR1aVu776nzF7tfFT LbUmG0dZ8kRwVJ264iVwPZukPfipFLNgPUNdL8E89wGz5wFdPyPO8irIw+9IXF4yjlw8 mILkqjjyDuXYYO6QWCBuP4i2hgsrrVM+HRYtjlxxdDvYml4Vwm5qQMrBqq8Z1DwrsFhG YA== Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) by mx0b-00143702.pphosted.com with ESMTP id 332yfd3mhd-23 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 24 Aug 2020 19:50:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1598313018; x=2462226618; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NOYnXlslUL2RR8Wd1Y6ychsET0vv8dGXqq7KqEiLB+4=; b=YzvIDpHYStMM9lLJmc+nZ/u4uPHsOjV1AjBRxARbh/OyP5wnINSzCDjOlyPWr4lT oUH9456qBCoTFKFoSIEGnY8OumprI88O71GwOz3khIqvLLyEpJXbY3ZOIIMm/U1T ote5HN+VV1MMejnH7Xi33PGrok+Q+DIlYY3TOBi5ooMjOWA7pHfotA8cSB06xwqs MK6Sx2xuN3+QBmv2onmqHrwMYLq3+Fs4iki5olRY1/cBYlgFa5jBwHP9LqmjnTKU o1+9+9HDHMcEoDagx97JaDj9iGB/CQkpk81c1bLhKM9uG07EjdCXzVBBJYxLGcD9 7cIOwjMU6AMJbZG6mOOAvA==; X-AuditID: a2962c47-52fff7000001f819-be-5f44523a414e Received: from copdcexc33.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 68.36.63513.A32544F5; Mon, 24 Aug 2020 17:50:18 -0600 (MDT) Received: from COPDCEX10.cable.comcast.com (147.191.124.141) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 24 Aug 2020 17:50:17 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX10.cable.comcast.com (147.191.124.141) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 24 Aug 2020 17:50:17 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.169) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Aug 2020 19:49:43 -0400 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BYAPR11MB3558.namprd11.prod.outlook.com (2603:10b6:a03:b3::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Mon, 24 Aug 2020 23:49:42 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6%7]) with mapi id 15.20.3305.026; Mon, 24 Aug 2020 23:49:42 +0000 From: "Deen, Glenn" To: Ted Hardie CC: ADD Mailing list Thread-Topic: [Add] IPR Disclosures to ADD WG Thread-Index: AQHWenE8dutmrRNq9E2xPhrvGj2MYw== Date: Mon, 24 Aug 2020 23:49:42 +0000 Message-ID: <94E479FC-78A9-4BA4-87B3-75AD85C72981@nbcuni.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:d497:24e1:ed7b:974a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 40d7cb4c-c13d-4ac5-d178-08d848885f40 x-ms-traffictypediagnostic: BYAPR11MB3558: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YbuOXALAl+ToYZ2jHYt5246cIQEc3IAylPF8++YfAhLw5C4aEYoS/1KtuTjL7PVU+uRFogrlAUNn0aUpIE2GcY6o4snuvkuop42tMT5vR0YfAuD1SAbl2y9tgoD4YYUDXy6atY6E7wrXpTwZulqSIB++T5n2B1uZ2KlUhhqf0Iuz+jRR8x3QnCKHSmQdL5lcTk9BSQsmYx+k5amES7sjn3F4LWlz7+QvPR+Zvab3j+YaQyBPOSia1wZmukC5ZIzh/FLJOUeK3UDKMnL34WDTRD/D6GBv4dCu83zw7l1i/HB3dukZjkPktiqEyKAqYhqEl4jTPCQLAulwqtWUVaqNVWwVdL7uszc89vn0L0DfOzdXG0OS6zYtbDIUGIW7+72h6k5lond1u75zl1N/T0UgEA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(346002)(136003)(39860400002)(366004)(478600001)(9686003)(9326002)(36756003)(86362001)(2906002)(316002)(6916009)(33656002)(8676002)(186003)(66946007)(4326008)(8936002)(66556008)(76116006)(6512007)(71200400001)(966005)(6486002)(66446008)(66476007)(6506007)(53546011)(64756008)(166002)(5660300002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: NwXJlwnJx03u4GWMioWwMQRQ86zZQUcIm2wN/6KjBdG6yWDA5s+7i2VSutuhq0Cq5i9T0QoUifAc31CDAM7TCH3UMEauBD1R4RWfsYmBonE7gETOv934AmB6aaDx3aJJKm2HdxKG3kYZ5Fd58jalq18oFLvSr+uRZ1UQUjMF6qw0Q4XYPYHB4v0tltoNzvZgLP0V88aIC9aV64EuPDPsTOxmP6pcIpSZotyGUO0rJ1Z2pihIKQEgvyiHjxCqF8wOOL4/NaE0LgNiXS2Ku018dQN2/Pui0h9j1c5LnxNbcDzO/HlMGNlq0aqYAuINIktm1X2+C/Fkwa+eId8Wd7kHooQsiHyePfVU82sGcTpbw/U4FrVxM9IWBh5p4QpTcZw+vRQK16hKS0869U14Rdu8J6wbS3nswOZQ1W6XmYWns7qxX/G2IqYOSy63eTEDAxhbR06YsG/H+JeJRS/2exG7YzF76BDzFgnhlpzX10u7f4C2XaYc1nCDBainZMC/nzTF8gmy6J+HqpRNlBlxmU3R1cosP0bVLHRnzQIcu0P8JTaoZc65svhEcIrQaV3vSCdLm9bDMvOQw+P6yS2NvBfOfGlNjWuRT4nLbfe6YdfhEvZXu7vdKFe5kcWcGz8Zqn1l3vPUgTwM6GBzPOlGBN6+M8WReO81ALxQlUsURNI9QR0tFqdJeLy0iGWZvdwUZ0WwF5MuqAFjGEyk6Q6Zo/rnBg== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EAnf+MbA9exYVXrDl3INiXYkIIvsqj1QM92v4MSwdbGQGvJB8BQB3PiwR2h/46jzf3BfmUs6UvHHaAU3iWkgJCPRnb+p2dEOgEP2VBtQ8zzh969b6F/X0a2vNZgV8V5Z6DPK1BNjVVidwxYjbbxIsePg35WYe/nXyU9VLvwYrWnYHQlS7bXwWNpgR31ffL2fa6riGAQUlrHL5ZSiIeBs6qXN303n89aV0HtB8W7v5JET6Js8fzIAaPEPfZ2M+TykDPrp5j+yS5854TEaq7NQvywkboyF70NPCXG0LEgXOCRYDO3ArmnKvhUVCbaG0L/0cRluy7sY8cLfOQ7zkuCYSw== 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=pibszdZr9jZmoLmsfGf7Nfn4ufyOfkf4u4EU5rn/EPU=; b=HAauG4VIDD8zxdJriYGe9n0OCMjShRkey3Cd3B7rFHf9nvp4bjm6Uh02yr9szf36NB4a0mxivU7YFfGTva8ca+tB7iJTZVt9Ty6P6HHZX/n4gvN4oEIruXjzjVopZKb8haK3I5cKO4yD84S4JyJ/bfjct7p69v3JC+rYTXWl0lgG+lMJ7C8cCXmmxmTYDpeuvesO5AlwBTliT8qRAU9KjpdBR6owDS3S78bBBhZ84Me3KcfmO5rso7aqLdRKSwUKjVQYjv0gz1cLWZbhYD4wI8DXElYh1hWNLPPbKOy08ABf6AgebM2o0v88XnDNboR7LePDfZcwFIA9H8sGkodH3A== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pibszdZr9jZmoLmsfGf7Nfn4ufyOfkf4u4EU5rn/EPU=; b=Nmai158QrES62IhyLsXvKYX9joRoCshnRTovYGufS3rzdihyKpyc94z/r2IrvrJGA0NXw1jDAzrqXt0U5z03+ttOJGkJgaASACEc2V5SPWxuGaCajRfrs4t+aAsgZI+RN2QhLrYdwt7Aj79O92DPrMriZIB05LtIq+hI54s/jc8= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 40d7cb4c-c13d-4ac5-d178-08d848885f40 x-ms-exchange-crosstenant-originalarrivaltime: 24 Aug 2020 23:49:42.1781 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: Fd+pp2wtcK+cpLIoFWVShtnF395TpoScSKXp+N34zRLWfkCbtyH/uuE2eZ0HNFpKZeaA4IFUfNLx5kDxnaqKvBpvS7OfvZ9fWuNaOfdaiAI= x-ms-exchange-transport-crosstenantheadersstamped: BYAPR11MB3558 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_94E479FC78A94BA487B375AD85C72981nbcunicom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsWSUDRnsq5VkEu8wa83Yhb/T69js2ica+fA 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZWx99Ze5oC254uq5zcwNjCsTuhg5OCQETCQa /vN1MXJxCAkcYZLovN/NCOE0M0lc+3SMCcK5wyix/PkDZgjnJKPEg6fPoTKLmSTmHdgE5Txi lDg3cSsjyGA2AR2JbZvtuxg5OUQElCX2XtnBBmIzA9ktT+4yg9jCQCUfV11ihajRlbhyqQXK 1pNYt+gWE4jNIqAqsXnCOkYQm1fAVmLVpGVgcUYBMYnvp9YwQcwUl7j1ZD6YLSEgILFkz3lm CFtU4uXjf6wg54gK6Eu8uucCciajQA+jxKxlGxgh/reSOL5aGaJcVuLS/G5GCNtX4tL+vVBj tCTe/ZnEDmFnS3xr3MwCYatJ3HjTAVUjJ7Gq9yFUXEbiwY3tbCC7JAR2M0vcX/+CBcL5xizR 8O4jI4Tzh1Xiy5JlzBMYjWYheQLCTpRY+/g46yywpwUlTs58wjIL6FhmAU2J9bv0IUoUJaZ0 P2SHsDUkWufMhbI9JJY9Xs6KrGYBI8cqRl5DMyM9Q1MDPRMTPXPDTYzAJLRomo77DsYP52MP MQpwMCrx8F53cokXYk0sK67MPcQowcGsJMIreNE5Xog3JbGyKrUoP76oNCe1+BCjNAeLkjhv z9UXcUIC6YklqdmpqQWpRTBZJg5OqQbGiZK8Lz98PzUxKnzR0axSzfB97H42Oa98taz3xOa1 /as695uhsrd1miP/NomgtCuFvTvPa2jMMlaVttD+ocp87cF9c9vfGSknZ15/O3ml+9UvUjGv XD0ZytyO9+81unVOR98s1s8w5Jj28viPve8VDpUoplQc2z+t6abm5R7G6+LJX9cwcdcosRRn JBpqMRcVJwIATFX8rz4DAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-24_12:2020-08-24, 2020-08-24 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] IPR Disclosures to ADD WG 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, 24 Aug 2020 23:50:23 -0000 --_000_94E479FC78A94BA487B375AD85C72981nbcunicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBUZWQsDQoNCkxldCBtZSBjaGVjayB3aXRoIHRoZSBzZWNyZXRhcmlhdC4gICAgVGhlcmUg b3JpZ2luYWxseSB3aGVyZSAyIG90aGVyIElQUiBzdWJtaXNzaW9ucywgNDI1OCBhbmQgNDI2MCwg IHRoYXQgSSB3YXMgdG9sZCBoYWQgYmVlbiBjb21iaW5lZCBpbnRvIDQyNjEuICBUaGVzZSBvdGhl cnMgYXJlIG5vdCB2aXNpYmxlIGluIHRoZSBzeXN0ZW0gc28gIEkgbmVlZCB0byBjaGVjayB3aXRo IHRoZSBzZWNyZXRhcmlhdC4gWW91IGFyZSBjb3JyZWN0IHRoYXQgNDE2MSBkb2VzIHN0YXRlIHRo YXQgaXQgdXBkYXRlcyA0MjU3LiAgIEkgd2lsbCB2ZXJpZnkgYW5kIGxldCB0aGUgbGlzdCBrbm93 Lg0KDQoNClRoYW5rcw0KR2xlbm4NCg0KDQoNCk9uIDgvMjQvMjAsIDQ6NDAgUE0sICJBZGQgb24g YmVoYWxmIG9mIFRlZCBIYXJkaWUiIDxhZGQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YWRkLWJv dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiB0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRl ZC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBHbGVubiwNCg0KNDI2MSBhcHBlYXJzIHRv IGJlIGFuIHVwZGF0ZSB0byB0aGUgZGlzY2xvc3VyZSAjNDI1Ny0taXMgdGhlcmUgYXJlIGFub3Ro ZXIsIGluZGVwZW5kZW50IGNsYWltIG9yIGFyZSB0aGUgdHdvIGNsYWltcyAoYW5kIDMgZGlzY2xv c3VyZXMpIHRoZSBmdWxsIHNldCB5b3Ugd2FudGVkIHRvIGNhbGwgb3V0IHRvIHRoZSBncm91cD8N Cg0KcmVnYXJkcywNCg0KVGVkDQoNCk9uIE1vbiwgQXVnIDI0LCAyMDIwIGF0IDM6NDYgUE0gRGVl biwgR2xlbm4gPEdsZW5uX0RlZW5AY29tY2FzdC5jb208bWFpbHRvOkdsZW5uX0RlZW5AY29tY2Fz dC5jb20+PiB3cm90ZToNCkFERCBwbGVhc2UgYmUgYWR2aXNlZCB0aGF0IDMgbmV3IElQUiBkaXNj bG9zdXJlcyBoYXZlIGJlZW4gc3VibWl0dGVkIHJlbGF0aW5nIHRvIHRoZSBBREQgd29ya2luZyBn cm91cCBieSBWZXJpc2lnbi4NCg0KQlRXLSBUaGVzZSB3ZXJlIHN1Ym1pdHRlZCB3aXRob3V0IHJl ZmVyZW5jaW5nIGFueSBzcGVjaWZpYyBkb2N1bWVudCBzbyB5b3Ugd29u4oCZdCBzZWUgdGhlbSBp ZiB5b3UgbG9vayBhdCB0aGUgbGlzdCBvZiBBREQgZG9jdW1lbnRzIGluIGRhdGF0cmFja2VyLg0K DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci80MjU2LzxodHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cHM6L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci80MjU2L19fOyEhUEla ZWVXNXdzY3luUlEhN0d5emFXZ2FORUt1LTFPeTBRVjFLRTZpbnhuMWxNY3JydUtuenpBWHVUVWVa aHZkUTF2MjdVcVh6Mmh4RTkzeiQ+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci80 MjU3LzxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L2RhdGF0cmFja2VyLmlldGYu b3JnL2lwci80MjU3L19fOyEhUElaZWVXNXdzY3luUlEhN0d5emFXZ2FORUt1LTFPeTBRVjFLRTZp bnhuMWxNY3JydUtuenpBWHVUVWVaaHZkUTF2MjdVcVh6NmktdHlvTSQ+DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2lwci80MjYxLzxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0 cHM6L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci80MjYxL19fOyEhUElaZWVXNXdzY3luUlEhN0d5 emFXZ2FORUt1LTFPeTBRVjFLRTZpbnhuMWxNY3JydUtuenpBWHVUVWVaaHZkUTF2MjdVcVh6eDl0 ZVpHeSQ+DQoNCnRoYW5rIHlvdSwNCkdsZW5uIERlZW4sIEFERCBjby1jaGFpcg0KLS0NCkFkZCBt YWlsaW5nIGxpc3QNCkFkZEBpZXRmLm9yZzxtYWlsdG86QWRkQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZGQ8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92 My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZGRfXzshIVBJWmVlVzV3 c2N5blJRITdHeXphV2dhTkVLdS0xT3kwUVYxS0U2aW54bjFsTWNycnVLbnp6QVh1VFVlWmh2ZFEx djI3VXFYejB5WUNFcG4kPg0K --_000_94E479FC78A94BA487B375AD85C72981nbcunicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkhlbHZldGljYTsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZl dGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+SGkgVGVkLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpI ZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPkxldCBtZSBjaGVjayB3aXRo IHRoZSBzZWNyZXRhcmlhdC4mbmJzcDsmbmJzcDsmbmJzcDsgVGhlcmUgb3JpZ2luYWxseSB3aGVy ZSAyIG90aGVyIElQUiBzdWJtaXNzaW9ucywgNDI1OCBhbmQgNDI2MCwgJm5ic3A7dGhhdCBJIHdh cyB0b2xkIGhhZCBiZWVuIGNvbWJpbmVkIGludG8gNDI2MS4gJm5ic3A7VGhlc2Ugb3RoZXJzIGFy ZSBub3QgdmlzaWJsZSBpbiB0aGUgc3lzdGVtIHNvICZuYnNwO0kgbmVlZA0KIHRvIGNoZWNrIHdp dGggdGhlIHNlY3JldGFyaWF0LiBZb3UgYXJlIGNvcnJlY3QgdGhhdCA0MTYxIGRvZXMgc3RhdGUg dGhhdCBpdCB1cGRhdGVzIDQyNTcuJm5ic3A7Jm5ic3A7IEkgd2lsbCB2ZXJpZnkgYW5kIGxldCB0 aGUgbGlzdCBrbm93LiZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhh bmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+R2xlbm48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNh Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiA4LzI0LzIwLCA0OjQwIFBNLCAm cXVvdDtBZGQgb24gYmVoYWxmIG9mIFRlZCBIYXJkaWUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzphZGQtYm91bmNlc0BpZXRmLm9yZyI+YWRkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFs ZiBvZg0KPGEgaHJlZj0ibWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbSI+dGVkLmlldGZAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGkgR2xlbm4sPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+NDI2MSBhcHBlYXJzIHRvIGJlIGFuIHVwZGF0ZSB0byB0 aGUgZGlzY2xvc3VyZSAjNDI1Ny0taXMgdGhlcmUgYXJlIGFub3RoZXIsIGluZGVwZW5kZW50IGNs YWltIG9yIGFyZSB0aGUgdHdvIGNsYWltcyAoYW5kIDMgZGlzY2xvc3VyZXMpIHRoZSBmdWxsIHNl dCB5b3Ugd2FudGVkIHRvIGNhbGwgb3V0IHRvIHRoZSBncm91cD88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5yZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIE1vbiwgQXVnIDI0LCAyMDIwIGF0IDM6NDYgUE0gRGVl biwgR2xlbm4gJmx0OzxhIGhyZWY9Im1haWx0bzpHbGVubl9EZWVuQGNvbWNhc3QuY29tIj5HbGVu bl9EZWVuQGNvbWNhc3QuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NCkFERCBwbGVhc2UgYmUgYWR2aXNlZCB0aGF0IDMgbmV3IElQUiBkaXNjbG9z dXJlcyBoYXZlIGJlZW4gc3VibWl0dGVkIHJlbGF0aW5nIHRvIHRoZSBBREQgd29ya2luZyBncm91 cCBieSBWZXJpc2lnbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpCVFctIFRoZXNlIHdlcmUgc3VibWl0dGVkIHdpdGhv dXQgcmVmZXJlbmNpbmcgYW55IHNwZWNpZmljIGRvY3VtZW50IHNvIHlvdSB3b27igJl0IHNlZSB0 aGVtIGlmIHlvdSBsb29rIGF0IHRoZSBsaXN0IG9mIEFERCBkb2N1bWVudHMgaW4gZGF0YXRyYWNr ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVp biI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzQyNTYvX187ISFQSVplZVc1d3NjeW5SUSE3R3l6YVdn YU5FS3UtMU95MFFWMUtFNmlueG4xbE1jcnJ1S256ekFYdVRVZVpodmRRMXYyN1VxWHoyaHhFOTN6 JCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzQyNTYv PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41 aW4iPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi9kYXRhdHJh Y2tlci5pZXRmLm9yZy9pcHIvNDI1Ny9fXzshIVBJWmVlVzV3c2N5blJRITdHeXphV2dhTkVLdS0x T3kwUVYxS0U2aW54bjFsTWNycnVLbnp6QVh1VFVlWmh2ZFExdjI3VXFYejZpLXR5b00kIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvNDI1Ny88L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L2RhdGF0cmFja2VyLmll dGYub3JnL2lwci80MjYxL19fOyEhUElaZWVXNXdzY3luUlEhN0d5emFXZ2FORUt1LTFPeTBRVjFL RTZpbnhuMWxNY3JydUtuenpBWHVUVWVaaHZkUTF2MjdVcVh6eDl0ZVpHeSQiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci80MjYxLzwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpIZWx2ZXRpY2EiPnRoYW5rIHlvdSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6SGVsdmV0aWNhIj5HbGVubiBEZWVuLCBBREQgY28tY2hhaXI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPi0tIDxicj4NCkFkZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86QWRkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QWRkQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYWRkX187ISFQSVplZVc1d3NjeW5SUSE3R3l6YVdnYU5FS3UtMU95 MFFWMUtFNmlueG4xbE1jcnJ1S256ekFYdVRVZVpodmRRMXYyN1VxWHoweVlDRXBuJCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWRkPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_94E479FC78A94BA487B375AD85C72981nbcunicom_-- From nobody Mon Aug 24 17:23: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 7985A3A0AFA for ; Mon, 24 Aug 2020 17:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 UnvkVfzoHv8y for ; Mon, 24 Aug 2020 17:23:31 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 810D13A0AF8 for ; Mon, 24 Aug 2020 17:23:31 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id q132so246780iod.7 for ; Mon, 24 Aug 2020 17:23:31 -0700 (PDT) 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=fRVy+9Y8KR4ju55w+cy+UgnX5aZkCmyfUmisMnc+VY0=; b=qBDfU7qJYKRg4AWoOPXtFP6Y06VbsV7JOkeGdsQf85DqZ/iLOCcptKrmAA6RirZMzf cO1G2xX/ol9Fo3f5SAuHzvZkQW5J5yqDe6DiHiQltyTThYA11a5O+rgloUhErAC/qEB0 wUxk1EO1ceSNgSF+0MZP8GfbQNuBWE9P+fR9X9190bb52E0tFxhAxM88yZZsGaa7W8SB lKslQ4hUOLRYsKt9ei9RfnJZdTa79+GRj1Z3AbiWxgrHrk2vOxkIYfPsAq3BfPRQxNXV p4psmyW08MISCqczGI+ySe9HGkV23WsFOAcZThrV6uJ0KpGY5E1sJ1GxdEKnpXB4yU86 38NQ== 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=fRVy+9Y8KR4ju55w+cy+UgnX5aZkCmyfUmisMnc+VY0=; b=Qk2ehWvHX4pGV0j6e/mb0lY8Dr0KriJS5M0PBIqqkeNRdJinaTilxSBNjGtB/p4xcD mW36Ifb8YKOoxL6r7C3MtHxuz8qU8YpL+opqABJakndBY01QNv7k4lx3JZAyJa1sCtxF UDc0IVCWRoY3TCU9yj/Ene6xVBvgLO9Ms0jH8/2gtGPK20p29pll52TYYkRe3DuCDXKx lgi9VcRsx1Nlngyv7ai2J8mKgRLiXqsSYCIKBbN/YaR87qll+NAyjUsbc4D59+Sfne8E am36+tj/XmZdYgvtMTA6jdsj0mx99ou8dhMYU+t5mEC1AvVWNJPsNn6o1EgIZBXsW5+d BHrA== X-Gm-Message-State: AOAM532C42GXspfocuvzcDX78ldiNHvM68NVPmv7gLt0dPM4GO4raVRc /yhQ+7c2c3EG2RCpbVFKBfhHfKGaOaL+cWCt/qA= X-Google-Smtp-Source: ABdhPJy3c9E3iDVudepj5Q0HjvLOS/Ra9PSA8984Xd5dhNHjdCFX2X9gfNXIAcqN56L8SYa2gKfIZCmqKhMReIacZOU= X-Received: by 2002:a5d:9f0e:: with SMTP id q14mr6995492iot.69.1598315010716; Mon, 24 Aug 2020 17:23:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Mon, 24 Aug 2020 17:23:16 -0700 Message-ID: To: "Deen, Glenn" Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000073f54f05ada8b6f3" Archived-At: Subject: Re: [Add] IPR Disclosures to ADD WG 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 Aug 2020 00:23:32 -0000 --00000000000073f54f05ada8b6f3 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 24, 2020 at 3:46 PM Deen, Glenn wrote: > ADD please be advised that 3 new IPR disclosures have been submitted > relating to the ADD working group by Verisign. > It's interesting that they think these issues matter. thanks, Rob --00000000000073f54f05ada8b6f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 24, 2020 at 3:46 PM Deen, Gle= nn <Glenn_De= en@comcast.com> wrote:

ADD please be advised that 3 new IPR disclosures hav= e been submitted relating to the ADD working group by Verisign.


It's interesting that they think t= hese issues matter.

thanks,
Rob

--00000000000073f54f05ada8b6f3-- From nobody Tue Aug 25 07:49: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 207833A0E56 for ; Tue, 25 Aug 2020 07:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=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 (2048-bit key) header.d=heapingbits.net header.b=hvKsMfVX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SFfoGt69 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 QJSYJo9jWLee for ; Tue, 25 Aug 2020 07:48:59 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B233A0E45 for ; Tue, 25 Aug 2020 07:48:59 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 726E8D1F for ; Tue, 25 Aug 2020 10:48:58 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Tue, 25 Aug 2020 10:48:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=au9MB xLKkXPz/nwaR9kFSbnFf+bcAG5VneKmcZ0DK64=; b=hvKsMfVX5xoF5JhZscbEj 1OBVuSPJyXEx3psvl9eTCiNDjmMyPydVob5/uw4r9iswo/DrMo20ZOxG4tONmD5y 0WbrZPG1hhJK8UItR0z+hKP6d8M4/uc36/FoN3mdfewewQQh7a86CY4XPbyOKMpo OSCfnfZximzB2hfscLs8DvNB1XWx8wopKfokrYeeQ/ZogKBGAN/3AP18MoC9vhWG +3xmBnXmEDVMncIuNU3iZHY8fCYLta1WZb9jJ2quchKeCvTQomCclFV7OAB1JCll 1Tazd3sVRU/2I1Hp+kwqKhigD+ljpGL2AtNa+NQUC/Ty7wbJcoEISNguLqrU+ZJc w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=au9MBxLKkXPz/nwaR9kFSbnFf+bcAG5VneKmcZ0DK 64=; b=SFfoGt69x9qFcCLiJ7KRWzq2kwHexRtWxbeK6iWz+FKrz2XJdyIWn8blu thNIcIGf8t0yymmeF1dSB0FJWAVwZHWF5s2MUbfdJETh/BvisTp4N+1XloHh9aWa Cbdg2rBcSDIg9Q7IlQbjw5dPwlWZIYJ04lc8xScQrGw4vWFt9hAHK+3pX40StLdc Jg5l/TpHOXxdceorC/9n1nojdc4wSxBYzN7nuBfc572/buCvAwFH5IAbvUo7Hzu2 Fw9BYtcKT6ABnGmmWXcgFlae/2xkbmcCGVLoTBLvcKT6w8GbLARCDmTWZ0DYdBFU zeZKs74o7xT17jcaBHpW95aEYpWJQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggr fieshhgvrghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepkeffkeevge fhgfdtffeivedugfeltdehhfefvddvheeliedvgeevgeelfeetjedunecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhngh gsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DC0663C00A1; Tue, 25 Aug 2020 10:48:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-225-gd87cabf-fm-20200825.001-gd87cabfd Mime-Version: 1.0 Message-Id: <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> In-Reply-To: References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> Date: Tue, 25 Aug 2020 07:48:36 -0700 From: "Christopher Wood" To: add@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] ADD Requirements Draft 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 Aug 2020 14:49:01 -0000 Thanks for the review! Please see inline below. On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote: > Document: draft-pauly-add-requirements-00.txt >=20 > Tommy, >=20 > Thanks for posting this. Two comments on the threat model, > requirements, and what mechanisms it leaves in scope. The points > below are primarily about local discovery. >=20 >=20 > 1. In S 4, you say you are assuming an RFC 3552 threat model that > includes on-path active attackers. However, in S 2.1 you indicate that= > one of the benefits of this type of mechanism is to authenticate data > coming from the true resolver: >=20 > * Verify that answers come from the selected DNS resolver >=20 > * Authenticate that the DNS resolver is the one provisioned by the= > network >=20 > As a side note, I would observe that these benefits derive from the > use of an authenticated channel, not from an encrypted channel. This > is sort of a nit in that modern TLS profiles discourage authentication= > only, but I think it's still worth getting right. Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use of a= uthenticated DoH and DoT, but I can see how that=E2=80=99s confusing giv= en that we later mention opportunistic encryption (as a contrasting appr= oach). > More importantly, this is only really true if either (1) the client > can accurately determine the nonexistence of a secure resolver or (2) > the client somehow behaves meaningfully differently in cases where > it determines that there is no secure resolver. To lay this out in > more detail, assuming that it's possible to determine the identity > of a secure resolver if one is present (e.g., by the kind of SPAU > mechanism that Chrome uses), then there are three cases: >=20 > 1. The client connects to a secure resolver > 2. No authenticated resolver is present > 3. There is an attack >=20 > While it's straightforward to determine whether one is in case (1), > many users will be in case (2) and so as long as the client treats > (1), (2), and (3) identically, then this doesn't preclude attack by > on-path attackers. Thisisn't a new observation, of course, but I think= > it points to the need to sharpen the requirements and potentially > S 4.2 if they are to be useful in the face of the threat model > you define. That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3)= and (2) differently, then the attacker can always win. And right now, g= iven the threat model, it=E2=80=99s unclear *if* a client can differenti= ate between these cases. Or to put it differently (and I think this was = how you phrased it once in the past): the client can=E2=80=99t distingui= sh between a network with no authenticated resolver and an active attack= .=20 Perhaps we need to relax the attacker=E2=80=99s capabilities here? If Do= H is blocked, then, well, what is a client left to do? Section 4.2 punts= that problem to the client=E2=80=99s policy, which seems (to me) to be = the right way to deal with this type of attack. Perhaps it=E2=80=99s worth clarifying that one of the motivations for th= ese requirements (and guidance text) is to allow for incremental improve= ments. For example, opportunistic encrypted DNS may be better than no en= cryption for some clients. Although clients can=E2=80=99t determine if t= his is an attack or not, there=E2=80=99s arguably some benefit to it. Or= put differently: the attacker may easily win for opportunistic DNS, but= there may be cases where the attacker loses, and that seems like an imp= rovement. > 2. S 4 says that attackers must not be able to: >=20 > * Redirect DNS traffic to themselves. >=20 > If we try to map this onto the various proposed mechanisms, I think it= > has to be softened to say something like "Redirect secure DNS traffic > to themselves when DNS traffic would not be" (again a 3552 attacker > can say whatever they want in DHCP). I think this then precludes this > mechanism having some kind of indicator of where the secure resolver > is other than at its own IP. I think that=E2=80=99s right. None of the current discovery mechanisms w= ork well for local discovery when the attacker controls the network, sin= ce none of the current signals are authenticated. Best, Chris From nobody Tue Aug 25 08:36: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 17BE73A0E91 for ; Tue, 25 Aug 2020 08:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[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 7iQ2KIaDh0Jv for ; Tue, 25 Aug 2020 08:36:16 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 4B1833A0E79 for ; Tue, 25 Aug 2020 08:36:16 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id w25so14295759ljo.12 for ; Tue, 25 Aug 2020 08:36:16 -0700 (PDT) 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=o8mir/+4HAQ/cY3Z23Fpt53KvoPE0TVNArGscmYbLN0=; b=Qkb75quBDI26HBw9T1pn7c/4W76vqOwtzXmF5+M0p0eZ4zZ0nAuwaAXkwrmImXmMei 7ABgmzGb8yN/FU3ThLZsX3fcEG1Mys8tWee+svnCBeLPPmR3qjsxXO/SpuDcX6OtDiFt Vq49Ti8gH9LvSsKTc17avTn4D34OIcomgzsLmJf8wRtAZEReRy8GBE/CHhpMr97/G5Vc WSeA7snogD2G+kyhR90npfqpV+jCOhcsR9pmyZ7wcdzVMLDtyi2tq9x2u1DHiX4vXzXv QGLzwWfAjnJlU0beQ5SE2Jkioroi5tzDzpKKk8UOKSTsBjF+IqWcjNNotf1xh61iwuNU OcGg== 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=o8mir/+4HAQ/cY3Z23Fpt53KvoPE0TVNArGscmYbLN0=; b=U/lvoDHYuZn5Sr/bQkaamEif+V6QkxWxQn5cp2fTwYDBGGtPbdyHTVcO/lksexxWaR a5YmPHscUI3hkbEgdN3Q7+FHi/GsRInUc1DwCR+kTRzE21XXO05YVpfRrIqvtHySK4Tv xbe5B12ia3iTCrPS/QTbFPFnPCsixBS0F+8ZOz96uMldLyPTZy9jDggvW7YyzoXR1tN5 Q8WdLe+m3+KGYSREFZVZ1xnP5BL40TrOYamIQNQxOgjWlgfgKnjng6lwT49u8xqyxK+X l8RlLbPOCQDxMpmXf0qJ3H5O5yaU04ycIMhx5lbj01njjbMonjxBaFt8ooTpnEZI50eY Yqyw== X-Gm-Message-State: AOAM533r5PRyJH6AWa7fQhsHvsMySY8UHwb7aHdGdeuC7QFW2u6UoPle /qpcNL8npPIbwDl4EIvcjofveDeFq18nDXs2dDSCSjaB4HzWwA== X-Google-Smtp-Source: ABdhPJwjcFNtFtBSE0gLzBL7KgYA4zEUgbfnr8N8UdsSe3y++KLPwGG3Z/r/weTt6SkQendc3Or/dbvVqJAo9UlDUvc= X-Received: by 2002:a2e:b4f1:: with SMTP id s17mr4975462ljm.184.1598369774432; Tue, 25 Aug 2020 08:36:14 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> In-Reply-To: <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> From: Eric Rescorla Date: Tue, 25 Aug 2020 08:35:38 -0700 Message-ID: To: Christopher Wood Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000a00d1c05adb576d9" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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 Aug 2020 15:36:18 -0000 --000000000000a00d1c05adb576d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 25, 2020 at 7:49 AM Christopher Wood wrote: > > More importantly, this is only really true if either (1) the client > > can accurately determine the nonexistence of a secure resolver or (2) > > the client somehow behaves meaningfully differently in cases where > > it determines that there is no secure resolver. To lay this out in > > more detail, assuming that it's possible to determine the identity > > of a secure resolver if one is present (e.g., by the kind of SPAU > > mechanism that Chrome uses), then there are three cases: > > > > 1. The client connects to a secure resolver > > 2. No authenticated resolver is present > > 3. There is an attack > > > > While it's straightforward to determine whether one is in case (1), > > many users will be in case (2) and so as long as the client treats > > (1), (2), and (3) identically, then this doesn't preclude attack by > > on-path attackers. Thisisn't a new observation, of course, but I think > > it points to the need to sharpen the requirements and potentially > > S 4.2 if they are to be useful in the face of the threat model > > you define. > > That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3) = and (2) > differently, then the attacker can always win. And right now, given the > threat model, it=E2=80=99s unclear *if* a client can differentiate betwee= n these > cases. Or to put it differently (and I think this was how you phrased it > once in the past): the client can=E2=80=99t distinguish between a network= with no > authenticated resolver and an active attack. > > Perhaps we need to relax the attacker=E2=80=99s capabilities here? Yes, I think that's a good idea. For instance, one could look at cases where the attacker is read-only or where the attacker controls your uplink but not your local network. -Ekr --000000000000a00d1c05adb576d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 25, 2020 at 7:49 AM Chris= topher Wood <caw@heapingbits.net<= /a>> wrote:
> More importantly, this is only really true if either (1) the client > can accurately determine the nonexistence of a secure resolver or (2)<= br> > the client somehow behaves meaningfully differently in cases where
> it determines that there is no secure resolver. To lay this out in
> more detail, assuming that it's possible to determine the identity=
> of a secure resolver if one is present (e.g., by the kind of SPAU
> mechanism that Chrome uses), then there are three cases:
>
> 1. The client connects to a secure resolver
> 2. No authenticated resolver is present
> 3. There is an attack
>
> While it's straightforward to determine whether one is in case (1)= ,
> many users will be in case (2) and so as long as the client treats
> (1), (2), and (3) identically, then this doesn't preclude attack b= y
> on-path attackers. Thisisn't a new observation, of course, but I t= hink
> it points to the need to sharpen the requirements and potentially
> S 4.2 if they are to be useful in the face of the threat model
> you define.

That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3) an= d (2) differently, then the attacker can always win. And right now, given t= he threat model, it=E2=80=99s unclear *if* a client can differentiate betwe= en these cases. Or to put it differently (and I think this was how you phra= sed it once in the past): the client can=E2=80=99t distinguish between a ne= twork with no authenticated resolver and an active attack.

Perhaps we need to relax the attacker=E2=80=99s capabilities here?

Yes, I think that's a good idea. For instance, = one could look at cases where the attacker is read-only or where the attack= er controls your uplink but not your local network.

-Ekr

--000000000000a00d1c05adb576d9-- From nobody Tue Aug 25 08:54:47 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 6667B3A0E51 for ; Tue, 25 Aug 2020 08:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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 (2048-bit key) header.d=comcast.com header.b=YHMmRZRq; dkim=pass (2048-bit key) header.d=comcast.com header.b=Lj8H6+0u; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=IFKMix2D 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 xpnPsg4IkEoD for ; Tue, 25 Aug 2020 08:54:41 -0700 (PDT) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.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 594663A0EE5 for ; Tue, 25 Aug 2020 08:54:41 -0700 (PDT) Received: from pps.filterd (m0184889.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07PFj7ZL025912 for ; Tue, 25 Aug 2020 11:54:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=pne0kvgomMCotGQxf+cwpJoxfjLnToqJVYBHADW/YnU=; b=YHMmRZRq7onT3h0uxhB2zF9ELF1iZqoMdrXhOX8e6nvZXQW2QicAdh6RdiDAtB8ZGSwv uuU0CkZ4iO5cuLB4COBpUnklhOcR+aRDoyba2UNEa8oVVeJ8VB5qyyT/vn6fpOZzSfUA Bn6EFymt+AiwD93ZV3D20baEFL6x9uQUzaAu/OROg6MEL/k3zKBbOavPDaKJNVrIbqXJ QDeSLhsMhb0lvNo7kdFuYMNHK+F8TcbgawaTDpA9ehVBIc3wzJnG8402bMnTxS06clSI Cp8aJXrSMaXOuP9ZZLOQ/mk8D1UAbSNxn0ej+zgqRxcZLKHz2OBQ9INisowfwH0FQldT cA== Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) by mx0b-00143702.pphosted.com with ESMTP id 332w787b8k-96 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 25 Aug 2020 11:54:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1598370877; x=2462284477; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pne0kvgomMCotGQxf+cwpJoxfjLnToqJVYBHADW/YnU=; b=Lj8H6+0uSduNzDUDe2xkcnri9c+75A8je54MyKt8yorvV8X67jRMpERJPJmS2J8h kPnttPQPLgkyHPwokzAeDvuy2AjR9EClr2Dorr363a1f4wHxpDyf87eF/eW92Ja1 BLRpjZg0DMDKvVQwjGqp3QktjiDL83I1LQFbIuBofFZUtnAZThjs2cosnhuF/FY9 C5e2SfKhuAIYdEVTudbKWZ6Fu7GrkzWHoWsQk03CcVkWNqDVoD1eJjZAjT2uRvcd SP9J/wyGvaKTpN4mhWkWRnuy1BqUdG6102ChJlRwwtc/B5oPxX3vYMcTIpnLfz9E vNqPdB8xkL+ajgH5qFuUtA==; X-AuditID: 44571fa7-3fdff70000018e96-f7-5f45343d3e4f Received: from PACDCEX53.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 5A.63.36502.D34354F5; Tue, 25 Aug 2020 11:54:37 -0400 (EDT) Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by PACDCEX53.cable.comcast.com (24.40.2.152) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Aug 2020 11:54:36 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX41.cable.comcast.com (24.40.2.140) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 25 Aug 2020 11:54:36 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.103) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Aug 2020 11:54:28 -0400 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BY5PR11MB4102.namprd11.prod.outlook.com (2603:10b6:a03:181::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Tue, 25 Aug 2020 15:54:24 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::cd81:1d1c:b876:a1d6%7]) with mapi id 15.20.3305.026; Tue, 25 Aug 2020 15:54:24 +0000 From: "Deen, Glenn" To: Ted Hardie CC: ADD Mailing list Thread-Topic: [Add] IPR Disclosures to ADD WG Thread-Index: AQHWenE8dutmrRNq9E2xPhrvGj2MY6lIhcWA Date: Tue, 25 Aug 2020 15:54:24 +0000 Message-ID: <329355A9-AAFC-4F7C-909A-42D2D5BD793C@comcast.com> References: <94E479FC-78A9-4BA4-87B3-75AD85C72981@nbcuni.com> In-Reply-To: <94E479FC-78A9-4BA4-87B3-75AD85C72981@nbcuni.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:fdc5:7f29:9b0b:5c3f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41ef3252-eab6-418e-a407-08d8490f23d3 x-ms-traffictypediagnostic: BY5PR11MB4102: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mQ7KLOTJhOvpRtLGLLrlg4fD52uuDLmfPm/hd/mIpglbjGAY07pIHbzlr6LQl88TMz6HhB8MdvMM3g7PHpN3QSZBAYT+slqZu62D9y+y0T6g6Wp/5TRMCq2icL23/PMQukMT5WyroKbj2xi2knvzuGM4ukubhHzxz2bugztA9Zy5J2EA3c4ErkjP3e1/URmfeqaFIdi9mJOk3jlxPzuz1HHdYOYn8F0VOHD7S8a6hB0XtSGYtMwyxiPvI4KGvtuMsuLRALFMTUkcal5J+Tvj8I2Qm0Dc+xd2LEdRGVNYFJoz2PnxW+uP775VdS2GXblU7s6aHessr79ukKyNIKxgx5GGuR0V1a20YBqoCmeYcIV2gVk0+RxklBpBXB8ENuo8xAZ5ywBNHvzUf+8BMA2Tkg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(346002)(376002)(396003)(6506007)(4326008)(8676002)(36756003)(2616005)(8936002)(478600001)(966005)(5660300002)(6512007)(86362001)(76116006)(83380400001)(2906002)(33656002)(6916009)(71200400001)(66946007)(6486002)(53546011)(66556008)(186003)(66446008)(64756008)(166002)(316002)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: hQ8Qt/pcRCa/iDcvllbza4//L1sYkiaip1KZt2EBnFJv+J4qJ3rYiXAgYaC6kA3UuwzpUF0zKh/Ci6EyVjCqro3JzqTE/J/y64GMru/SsboSoKQbrBfVVAcIiV+34NXbTD1chRMPDwMxGw2/ZLyzhc19Bk1C1x44ryvgIzAO4vk6soR+lpfhnO7voXXUgm4Ye3MRXnYWwC7tqdiyPHCikt/m/ZHnhY4ZOm4ZZI/7B0EG5ZmgwvZ1e0c87Zlc2dJT1n98dHzV2uo2vKVpxaJiVqAhI3Z9hQertEvmeERZsNLWm2ZmMb29Ik2x9decnrBLgCGsmW/YslfFbLb7A09e63u8RIRKjai8Hpz3OoqPVOvwnGDZLCYzDTmTogNJ5KqJX0j4Dm3099/5GXrw/KHbTUqXw++tpZoWTBARgwoppa1LTIpjv9NYw05zUrHb3ivLmN/VLVvbjrX9JvMYgEb1HrFytGqsJUSRAGt8nrAJkiovUGey20TmrDv8eMr1yP754+LTU3Vvg8+UxjzrGL3/zuxgj+3qq5OCykX1D/U2PSv8B3RrOfYG2Vc2JNe1/hvtjtTaykTKFM7Qld/NTcZNM0UbLBAuxPLt38IWOVO0bupsh+fID8vfFSEjmLT7Yfu8cfgbrYodCQmXC0oC/nqw2R1/27+UurE3bBl502xJwxVnUqERiR6GB04TI+tuviyI20W9bYvYJA5mZw4Pw8EZHQ== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gligfzHUt2Ede3d3LKhu3ZcjSxQO/S6EkIBZKoBkmHtDE1ZHSN/FCbLGYwJRWUYArVio005iizUC/1oKhMvtSMoumRK2CCiRBFa1K+6TtorQIiySX7vx+xZqf8wpFGCHReV6w+2UoE+ziNgmDxTURhy8f2M/vqUYX8ebbDTldRljhyYoO+53BiOAi9AfiFI9PExAjyDwi8wgPGshib1GqrIeIB1i3ywCAZ7a20c6aEfLUPFr3h+l2luDSf4Yvcp18RAciJQ88l9mhSdcysCUIYR0WDD4dAA/QsDSlR6JlD2pDpehD5qvdcnT3vMnp3fwGYSIHyaeUzp1rIXWgT4TIA== 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=BI9WxVY+MdEGVRL3IUJJK9wLL7MMZgwEDEyMfH0lmSA=; b=Ey73/kIXo0mohYVwGsMJSWj5NCQptbwp9p0yuKGZKqSX9Nu5R4s9KCrVQNeHTJ/Vq7CjVMotBsqZFwG4PclSDccvdGu7jOITn+2dSIr8R7haFnMRPLZBdng5R2fAka0piLasBK3JqX8fYRrKp5mtWZW5eM7DTHZA1S/HUs4WG/JidspbWajye28vag88XcMTLJEOzdAiDRet5vKMyD7p5tg7mSmpfhJAflW0n/qM9zxz2BEF3rupsB4/0W9RKBG8Lcs+godFrZ8gZzvU8VeuVYc/5Avs8WLAz0h7eMfktjl5QkyksE4DIq5YnaAkfm+4cIYO4U1u3nkQpMOrLDLijA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BI9WxVY+MdEGVRL3IUJJK9wLL7MMZgwEDEyMfH0lmSA=; b=IFKMix2D7el/xyYI72urvQuW287GqWe5KYUYFN3fXyqhqyetGnR8EdKwSeYY+0XjuwghHh3ZlpJAVc6yPad3Y4E1TmDU/rGqECjGLYWVjQiGj/6pzkb5e3ovC9c+vXFlJHt7Zxxn76FVnyT9QevN+RJvOsVpGP2U5AaE9+p2aYk= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 41ef3252-eab6-418e-a407-08d8490f23d3 x-ms-exchange-crosstenant-originalarrivaltime: 25 Aug 2020 15:54:24.5515 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 5Esuo3s7jwvw9a8Shw1aLmb7oHRWiTL9VNKl03rQtc3l8YzdlZbb3Q3vkHkZbWQjeQstgiyGAIAnr7NyGXPh0K7Fdoound7ieG2YCQJz9A4= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4102 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_329355A9AAFC4F7C909A42D2D5BD793Ccomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsXiEq4ko2tr4hpv0POJz+L/6XVsFo1z7RyY PHbOusvusWTJT6YApigum5TUnMyy1CJ9uwSujLa26YwF08sq7u4oamD8U9TFyMkhIWAi0bry CFsXIxeHkMARJonTt2+xgiSEBHYxSjQvzYNIXGWUWHx8CSuEc4xRYu+Fr1AtS5gkFt2eDOU8 YpR4c38hYxcjBwebgI7Ets32IKNEBJQl9l7ZwQZiMwPZLU/uMoPYwkAlH1ddYoWo0ZW4cqkF yjaSaLt4BsxmEVCV+LdqKyOIzStgJ9HXcQTqPFuJxp5dYHFOoPjMi4/YQWxGATGJ76fWMEHs Epe49WQ+E8SfAhJL9pxnhrBFJV4+/scKcqaogL7Eq3suIOczCvQwSsxatoERosZKovX0C3YI W1bi0vxuqLivxIHpm1ghbC2J9uvroOZnS9xd+JEFwlaTuPGmA2qXnMSq3odQcRmJBze2g8NK QmA3s8Szc1dYJjCazEJy6yygm5gFkiS2PoufBfayoMTJmU9YIMKaEut36UNUK0pM6X7IDmFr SLTOmQtle0jMWN7KhqxmASPHKkYeMws9C3M9Y0M9QzPzTYzg5CO/fAfj9lkZhxgFOBiVeHi/ a7rGC7EmlhVX5h5ilOBgVhLhFbzoHC/Em5JYWZValB9fVJqTWnyIUZqDRUmcd8LVF3FCAumJ JanZqakFqUUwWSYOTqkGxswlIV+luW/uVp9w8o+sg9BJp53SX5fdNxXfcu3x7bNzyi+3L9kh 4fht8/Jbp6sZqiemfpBw6js3cdPn96sMMyo5jl/IfeX4WaHh+7pp5fOMp557OGP1gRuLDyQ9 +Sx5QHfalYkNhqbFp4WvVRnKJhtWNHB+/vOb59miBKGrMxujgybxlXKFcCUpsRRnJBpqMRcV JwIAnLH5CDoDAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-25_06:2020-08-25, 2020-08-25 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] IPR Disclosures to ADD WG 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 Aug 2020 15:54:43 -0000 --_000_329355A9AAFC4F7C909A42D2D5BD793Ccomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQUREDQoNCkkgY2hlY2tlZCB3aXRoIHRoZSBzZWNyZXRhcmlhdCBhbmQgdGhleSBzYWlkIHRo YXQgdGhlIDMgbGlzdGVkIElQUnMgYXJlIGNvcnJlY3QuICAgIDQyNjEgd2FzIGEgbmV3IElQUiBm cm9tIGNvbWJpbmVkIDQyNTggYW5kIDQyNjEgYW5kIHdoaWxlIGl0IG1lbnRpb25zIDQyNTcgaXQg aXMgZGlzdGluY3QgYWNjb3JkaW5nIHRvIGl0cyBzdWJtaXR0ZXIuDQoNClJlZ2FyZHMNCkdsZW5u DQoNCk9uIDgvMjQvMjAsIDQ6NDkgUE0sICJEZWVuLCBHbGVubiIgPEdsZW5uX0RlZW5AY29tY2Fz dC5jb208bWFpbHRvOkdsZW5uX0RlZW5AY29tY2FzdC5jb20+PiB3cm90ZToNCg0KDQpIaSBUZWQs DQoNCkxldCBtZSBjaGVjayB3aXRoIHRoZSBzZWNyZXRhcmlhdC4gICAgVGhlcmUgb3JpZ2luYWxs eSB3aGVyZSAyIG90aGVyIElQUiBzdWJtaXNzaW9ucywgNDI1OCBhbmQgNDI2MCwgIHRoYXQgSSB3 YXMgdG9sZCBoYWQgYmVlbiBjb21iaW5lZCBpbnRvIDQyNjEuICBUaGVzZSBvdGhlcnMgYXJlIG5v dCB2aXNpYmxlIGluIHRoZSBzeXN0ZW0gc28gIEkgbmVlZCB0byBjaGVjayB3aXRoIHRoZSBzZWNy ZXRhcmlhdC4gWW91IGFyZSBjb3JyZWN0IHRoYXQgNDE2MSBkb2VzIHN0YXRlIHRoYXQgaXQgdXBk YXRlcyA0MjU3LiAgIEkgd2lsbCB2ZXJpZnkgYW5kIGxldCB0aGUgbGlzdCBrbm93Lg0KDQoNClRo YW5rcw0KR2xlbm4NCg0KDQoNCk9uIDgvMjQvMjAsIDQ6NDAgUE0sICJBZGQgb24gYmVoYWxmIG9m IFRlZCBIYXJkaWUiIDxhZGQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YWRkLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiB0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRmQGdt YWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBHbGVubiwNCg0KNDI2MSBhcHBlYXJzIHRvIGJlIGFuIHVw ZGF0ZSB0byB0aGUgZGlzY2xvc3VyZSAjNDI1Ny0taXMgdGhlcmUgYXJlIGFub3RoZXIsIGluZGVw ZW5kZW50IGNsYWltIG9yIGFyZSB0aGUgdHdvIGNsYWltcyAoYW5kIDMgZGlzY2xvc3VyZXMpIHRo ZSBmdWxsIHNldCB5b3Ugd2FudGVkIHRvIGNhbGwgb3V0IHRvIHRoZSBncm91cD8NCg0KcmVnYXJk cywNCg0KVGVkDQoNCk9uIE1vbiwgQXVnIDI0LCAyMDIwIGF0IDM6NDYgUE0gRGVlbiwgR2xlbm4g PEdsZW5uX0RlZW5AY29tY2FzdC5jb208bWFpbHRvOkdsZW5uX0RlZW5AY29tY2FzdC5jb20+PiB3 cm90ZToNCkFERCBwbGVhc2UgYmUgYWR2aXNlZCB0aGF0IDMgbmV3IElQUiBkaXNjbG9zdXJlcyBo YXZlIGJlZW4gc3VibWl0dGVkIHJlbGF0aW5nIHRvIHRoZSBBREQgd29ya2luZyBncm91cCBieSBW ZXJpc2lnbi4NCg0KQlRXLSBUaGVzZSB3ZXJlIHN1Ym1pdHRlZCB3aXRob3V0IHJlZmVyZW5jaW5n IGFueSBzcGVjaWZpYyBkb2N1bWVudCBzbyB5b3Ugd29u4oCZdCBzZWUgdGhlbSBpZiB5b3UgbG9v ayBhdCB0aGUgbGlzdCBvZiBBREQgZG9jdW1lbnRzIGluIGRhdGF0cmFja2VyLg0KDQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci80MjU2LzxodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cHM6L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci80MjU2L19fOyEhUElaZWVXNXdzY3lu UlEhN0d5emFXZ2FORUt1LTFPeTBRVjFLRTZpbnhuMWxNY3JydUtuenpBWHVUVWVaaHZkUTF2MjdV cVh6Mmh4RTkzeiQ+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci80MjU3LzxodHRw czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci80 MjU3L19fOyEhUElaZWVXNXdzY3luUlEhN0d5emFXZ2FORUt1LTFPeTBRVjFLRTZpbnhuMWxNY3Jy dUtuenpBWHVUVWVaaHZkUTF2MjdVcVh6NmktdHlvTSQ+DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2lwci80MjYxLzxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L2RhdGF0 cmFja2VyLmlldGYub3JnL2lwci80MjYxL19fOyEhUElaZWVXNXdzY3luUlEhN0d5emFXZ2FORUt1 LTFPeTBRVjFLRTZpbnhuMWxNY3JydUtuenpBWHVUVWVaaHZkUTF2MjdVcVh6eDl0ZVpHeSQ+DQoN CnRoYW5rIHlvdSwNCkdsZW5uIERlZW4sIEFERCBjby1jaGFpcg0KLS0NCkFkZCBtYWlsaW5nIGxp c3QNCkFkZEBpZXRmLm9yZzxtYWlsdG86QWRkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hZGQ8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBz Oi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZGRfXzshIVBJWmVlVzV3c2N5blJRITdH eXphV2dhTkVLdS0xT3kwUVYxS0U2aW54bjFsTWNycnVLbnp6QVh1VFVlWmh2ZFExdjI3VXFYejB5 WUNFcG4kPg0K --_000_329355A9AAFC4F7C909A42D2D5BD793Ccomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <748BC788E7D1EF48A39AAEA230859E5F@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkhlbHZldGljYTsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZl dGljYSI+SGkgQUREPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Okhl bHZldGljYSI+SSBjaGVja2VkIHdpdGggdGhlIHNlY3JldGFyaWF0IGFuZCB0aGV5IHNhaWQgdGhh dCB0aGUgMyBsaXN0ZWQgSVBScyBhcmUgY29ycmVjdC4mbmJzcDsmbmJzcDsmbmJzcDsgNDI2MSB3 YXMgYSBuZXcgSVBSIGZyb20gY29tYmluZWQgNDI1OCBhbmQgNDI2MSBhbmQgd2hpbGUgaXQgbWVu dGlvbnMgNDI1NyBpdCBpcyBkaXN0aW5jdCBhY2NvcmRpbmcgdG8gaXRzIHN1Ym1pdHRlci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5SZWdhcmRz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+R2xlbm48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiA4LzI0LzIwLCA0OjQ5IFBNLCAmcXVvdDtE ZWVuLCBHbGVubiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkdsZW5uX0RlZW5AY29tY2FzdC5j b20iPkdsZW5uX0RlZW5AY29tY2FzdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpI ZWx2ZXRpY2EiPkhpIFRlZCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Okhl bHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2 ZXRpY2EiPkxldCBtZSBjaGVjayB3aXRoIHRoZSBzZWNyZXRhcmlhdC4mbmJzcDsmbmJzcDsmbmJz cDsgVGhlcmUgb3JpZ2luYWxseSB3aGVyZSAyIG90aGVyIElQUiBzdWJtaXNzaW9ucywgNDI1OCBh bmQgNDI2MCwgJm5ic3A7dGhhdCBJIHdhcyB0b2xkIGhhZCBiZWVuIGNvbWJpbmVkIGludG8gNDI2 MS4gJm5ic3A7VGhlc2Ugb3RoZXJzIGFyZSBub3QgdmlzaWJsZQ0KIGluIHRoZSBzeXN0ZW0gc28g Jm5ic3A7SSBuZWVkIHRvIGNoZWNrIHdpdGggdGhlIHNlY3JldGFyaWF0LiBZb3UgYXJlIGNvcnJl Y3QgdGhhdCA0MTYxIGRvZXMgc3RhdGUgdGhhdCBpdCB1cGRhdGVzIDQyNTcuJm5ic3A7Jm5ic3A7 IEkgd2lsbCB2ZXJpZnkgYW5kIGxldCB0aGUgbGlzdCBrbm93LiZuYnNwOyZuYnNwOw0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhhbmtzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPkdsZW5uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS4waW4iPk9uIDgvMjQvMjAsIDQ6NDAgUE0sICZxdW90O0FkZCBvbiBiZWhhbGYgb2YgVGVkIEhh cmRpZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkZC1ib3VuY2VzQGlldGYub3JnIj5hZGQt Ym91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86dGVkLmll dGZAZ21haWwuY29tIj50ZWQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkhp IEdsZW5uLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+ NDI2MSBhcHBlYXJzIHRvIGJlIGFuIHVwZGF0ZSB0byB0aGUgZGlzY2xvc3VyZSAjNDI1Ny0taXMg dGhlcmUgYXJlIGFub3RoZXIsIGluZGVwZW5kZW50IGNsYWltIG9yIGFyZSB0aGUgdHdvIGNsYWlt cyAoYW5kIDMgZGlzY2xvc3VyZXMpIHRoZSBmdWxsIHNldCB5b3Ugd2FudGVkIHRvIGNhbGwgb3V0 IHRvIHRoZSBncm91cD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS4waW4iPnJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluIj5UZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4w aW4iPk9uIE1vbiwgQXVnIDI0LCAyMDIwIGF0IDM6NDYgUE0gRGVlbiwgR2xlbm4gJmx0OzxhIGhy ZWY9Im1haWx0bzpHbGVubl9EZWVuQGNvbWNhc3QuY29tIj5HbGVubl9EZWVuQGNvbWNhc3QuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KQUREIHBsZWFzZSBiZSBhZHZpc2VkIHRo YXQgMyBuZXcgSVBSIGRpc2Nsb3N1cmVzIGhhdmUgYmVlbiBzdWJtaXR0ZWQgcmVsYXRpbmcgdG8g dGhlIEFERCB3b3JraW5nIGdyb3VwIGJ5IFZlcmlzaWduLg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KQlRXLSBUaGVz ZSB3ZXJlIHN1Ym1pdHRlZCB3aXRob3V0IHJlZmVyZW5jaW5nIGFueSBzcGVjaWZpYyBkb2N1bWVu dCBzbyB5b3Ugd29u4oCZdCBzZWUgdGhlbSBpZiB5b3UgbG9vayBhdCB0aGUgbGlzdCBvZiBBREQg ZG9jdW1lbnRzIGluIGRhdGF0cmFja2VyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5jb20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzQyNTYvX187 ISFQSVplZVc1d3NjeW5SUSE3R3l6YVdnYU5FS3UtMU95MFFWMUtFNmlueG4xbE1jcnJ1S256ekFY dVRVZVpodmRRMXYyN1VxWHoyaHhFOTN6JCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByLzQyNTYvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzQyNTcvX187ISFQSVpl ZVc1d3NjeW5SUSE3R3l6YVdnYU5FS3UtMU95MFFWMUtFNmlueG4xbE1jcnJ1S256ekFYdVRVZVpo dmRRMXYyN1VxWHo2aS10eW9NJCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvaXByLzQyNTcvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20v djMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzQyNjEvX187ISFQSVplZVc1d3Nj eW5SUSE3R3l6YVdnYU5FS3UtMU95MFFWMUtFNmlueG4xbE1jcnJ1S256ekFYdVRVZVpodmRRMXYy N1VxWHp4OXRlWkd5JCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvaXByLzQyNjEvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj50aGFuayB5 b3UsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPkdsZW5uIERl ZW4sIEFERCBjby1jaGFpcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPi0tIDxicj4NCkFk ZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QWRkQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+QWRkQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWRkX187ISFQ SVplZVc1d3NjeW5SUSE3R3l6YVdnYU5FS3UtMU95MFFWMUtFNmlueG4xbE1jcnJ1S256ekFYdVRV ZVpodmRRMXYyN1VxWHoweVlDRXBuJCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYWRkPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_329355A9AAFC4F7C909A42D2D5BD793Ccomcastcom_-- From nobody Tue Aug 25 08:55: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 529E53A0E51 for ; Tue, 25 Aug 2020 08:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=verisign.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 zXW_Z4iR15Wn for ; Tue, 25 Aug 2020 08:55:03 -0700 (PDT) Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 719BA3A0ED9 for ; Tue, 25 Aug 2020 08:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=6492; q=dns/txt; s=VRSN; t=1598370902; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6+9q3s9H2SD6nPRho6HzB47zKsOH8jT5vsWFyjWd7Xc=; b=kaZVummMeSyFUASehMYErFz16XHkjsCBuWQ/1g6bd3SMqKFUASZbyVB7 JdduerkMn+7p7H+2acBRASlBxwT6dhnOsVcPb8dY7n3yYPUapeguSh4eP MqPWlQMVi7xDiU3KMU4Jp4hK8XCL+Y4kDoNFGmDGSLpRKxapgVid4ntJT y+Wp3POK2irZonzZ0BkfpgfCtuLsfUd8iEWwIzzfcdGVhEtMQKDB2eZhU iTK4FXsNWGgbnIRMW+W9K1cQCgdiBs4wqae1o2X1iK8XWnQFAS+LYRIxw MzW6Gjy6VLw89Y979Q7k9GcVHhadc4KOhutPSJZK27JqUpFmjqEPx/347 g==; IronPort-SDR: kyh0CH18aECb+0BEQS5qHRjQwOWzF5WFhhBxOfvT7DaP+p43g+L8l/Ir8DAzsqQa3JGvQowLQX G9FQ/kfCu5tdUzoGcdXeqiqyAhibDnEH8oT+6kWYl+EN+GFGiCXHIEchQBrJdUURAo9h6a4L4V yYl1hKCWR5u7cfjbZ5q46EkepCrXtd/ixkDuV9qZ0IDAH742P6D/KkLjY6vJ4BUsR/OsZUjKh7 5yIP/ksIy/BDtkLzMXToy6/0nqafVvi30sln4hVsLebWp4gad8bUh/+LRK6JA/C3Uy1sfnO9WR 7h4= X-IronPort-AV: E=Sophos;i="5.76,353,1592870400"; d="scan'208,217";a="2866650" IronPort-PHdr: =?us-ascii?q?9a23=3AUk/BJxI13UlrjdjusNmcpTZWNBhigK39O0sv0r?= =?us-ascii?q?FitYgXKvr8rarrMEGX3/hxlliBBdydt6sazbOM6+u+CSQp2tWoiDg6aptCVh?= =?us-ascii?q?sI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFR?= =?us-ascii?q?rhKAF7Ovr6GpLIj8Swyuu+54Dfbx9HiTagYL5+Ngi6oRvNusUZgIZvKbs6xw?= =?us-ascii?q?fUrHdPZ+lY335jK0iJnxb76Mew/Zpj/DpVtvk86cNOUrj0crohQ7BAAzsoL2?= =?us-ascii?q?465MvwtRneVgSP/WcTUn8XkhVTHQfI6gzxU4rrvSv7sup93zSaPdHzQLspVz?= =?us-ascii?q?mu87tnRRn1gyoBKjU38nzYitZogaxbvhyvugB/zYDXboGbNvV+f7/SctwBSG?= =?us-ascii?q?VbQspRVTZMDp+gY4YNCecKIOZWr5P6p1sLtRayCwuiBOTryj9MmHD227Y13P?= =?us-ascii?q?o9HgHFxAArAs8Av2jTrNXpKKceX/2+wa7TzTXDaPNW3TP955bOch86v/6DQb?= =?us-ascii?q?FwfNHPyUYxDQPFj06QqY3qPzOTzOgCr2+b7+95WO+plmUopB1/rCK1yccwlo?= =?us-ascii?q?nGmJgVylbc+Chn3Is5ONO2RU15bNK4EZZcqyOXOYV5TM4gQGxltig3x6EatJ?= =?us-ascii?q?KlfCUHzJspyh/QZvGHboWG7A/vWumeLzp6mX9ofq+0iRWq8UW41+HwStO43E?= =?us-ascii?q?tIoydLiNXAq3AA2hLJ5sWITvZx5lqt1SqV2wzO6OxIPVo4mbfUJpMi2LI8i5?= =?us-ascii?q?kevELeFSHsgkr2lrWZdkA89+it7OTof6vpq4eHN49xlgH+KqMumtGjAeggMg?= =?us-ascii?q?gBQWyb+eOk2bD+4UP3WKhGgf0unKfWsZ/WOdoXqrSnAwBJ1YYj8Q6/Ay2839?= =?us-ascii?q?sFh3UHMkhFeAmBj4TzJ17OJ/X4Ae++g1Sqjjhr2+jLMqD9DpnXM3TOkrnsca?= =?us-ascii?q?xg50Ncxgc/199S6pZMBrEEOv3zW0vxtNLCDh8+Ngy52/3nCNV61oMaXWKAHK?= =?us-ascii?q?mZP7jMvlCU5eIiOPeMa5EPuDb8MPgl5vHujXkjlVABeqmp2IMbaGqkEfR+P0?= =?us-ascii?q?WZfX3sj88AH2cOoAU+Surqh0WMXzFNeXmyWbkx6S08CIKjEYjMXJutgKCb0C?= =?us-ascii?q?inGZ1WY3hMCkqQHnfwa4WER/AMZTqOIsB/jzMIT7mhRJE91RGgrwL6xL9nIf?= =?us-ascii?q?DV+i0cr57syN915+jLnxEo6TN0F9id032KT2xshGwHWiI50bt+oUNj1leD37?= =?us-ascii?q?J0g/tCFdxctLt1VVJwGprRyepNJ93/XCrKedKCQU26BN6hBHt5Gv01ztkIVG?= =?us-ascii?q?pwFtOKhRfG1COxH/kekLndQNR+7q/QmXn8O8hVxHPP1a1nhF4jCIMbKWCqwK?= =?us-ascii?q?9y6wb7CIvAkkHfnKGvI/cyxinIoS2jym6KsUdSXQVzFe3+VncDegGe+c/54U?= =?us-ascii?q?fGQrmkBL8kGhVM08+ZK6RMLNbuiAMVF7/YJN3CbjfpyC+LDhGSy+bUYQ=3D?= =?us-ascii?q?=3D?= X-IPAS-Result: =?us-ascii?q?A2HSAgDyM0Vf/zGZrQpfHAEBAQEBAQcBARIBAQQEAQGCC?= =?us-ascii?q?oEjgXeBMwqELZEwiguSEQsBAQEBAQEBAQEHAS8EAQGETAIXgjQlOBMCAwEBC?= =?us-ascii?q?wEBAQUBAQEBAQYDAQEBAoZRgjcig3IBAQEBAyMKQQsQAgEIEQQBASsCAgIfE?= =?us-ascii?q?R0IAgQBDQUIgx+Bfk0DsSZ2gTKFUoJIDYIigTiGU4EChWiBQj6Dcy4+ghqFO?= =?us-ascii?q?oJgBI9Hgz+GZZwJUQMHgmOVJoR5KoMFnTKSRYFti0OSGQIEAgQFAhWBa4F7c?= =?us-ascii?q?FCCaVAXAg2cZnQ3AgYKAQEDCZAHgREBAQ?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 25 Aug 2020 11:54:58 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1979.003; Tue, 25 Aug 2020 11:54:58 -0400 From: "Hollenbeck, Scott" To: "Glenn_Deen@comcast.com" , "ted.ietf@gmail.com" CC: "add@ietf.org" Thread-Topic: [Add] IPR Disclosures to ADD WG Thread-Index: AQHWenE8dutmrRNq9E2xPhrvGj2MY6lI080Q Date: Tue, 25 Aug 2020 15:54:58 +0000 Message-ID: <4df86fc8bff14052b77c1340c9caefd3@verisign.com> References: <94E479FC-78A9-4BA4-87B3-75AD85C72981@nbcuni.com> In-Reply-To: <94E479FC-78A9-4BA4-87B3-75AD85C72981@nbcuni.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: multipart/alternative; boundary="_000_4df86fc8bff14052b77c1340c9caefd3verisigncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Add] IPR Disclosures to ADD WG 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 Aug 2020 15:55:04 -0000 --_000_4df86fc8bff14052b77c1340c9caefd3verisigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogQWRkIDxhZGQtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERlZW4sIEdsZW5u DQpTZW50OiBNb25kYXksIEF1Z3VzdCAyNCwgMjAyMCA3OjUwIFBNDQpUbzogVGVkIEhhcmRpZSA8 dGVkLmlldGZAZ21haWwuY29tPg0KQ2M6IEFERCBNYWlsaW5nIGxpc3QgPGFkZEBpZXRmLm9yZz4N ClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtBZGRdIElQUiBEaXNjbG9zdXJlcyB0byBBREQgV0cN Cg0KDQoNCg0KDQpIaSBUZWQsDQoNCg0KDQpMZXQgbWUgY2hlY2sgd2l0aCB0aGUgc2VjcmV0YXJp YXQuICAgIFRoZXJlIG9yaWdpbmFsbHkgd2hlcmUgMiBvdGhlciBJUFIgc3VibWlzc2lvbnMsIDQy NTggYW5kIDQyNjAsICB0aGF0IEkgd2FzIHRvbGQgaGFkIGJlZW4gY29tYmluZWQgaW50byA0MjYx LiAgVGhlc2Ugb3RoZXJzIGFyZSBub3QgdmlzaWJsZSBpbiB0aGUgc3lzdGVtIHNvICBJIG5lZWQg dG8gY2hlY2sgd2l0aCB0aGUgc2VjcmV0YXJpYXQuIFlvdSBhcmUgY29ycmVjdCB0aGF0IDQxNjEg ZG9lcyBzdGF0ZSB0aGF0IGl0IHVwZGF0ZXMgNDI1Ny4gICBJIHdpbGwgdmVyaWZ5IGFuZCBsZXQg dGhlIGxpc3Qga25vdy4NCg0KDQoNCltTQUhdIEkgc3VibWl0dGVkIHRoZSBkaXNjbG9zdXJlcyAo YW5kIHRoZSB1cGRhdGVzKSB0byBtZWV0IG91ciAiTm90ZSBXZWxsIiBvYmxpZ2F0aW9ucyBwcmlv ciB0byBwYXJ0aWNpcGF0aW5nIGluIHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2lvbnMuIFRoZSB1cGRh dGVzIHdlcmUgbWFkZSB0byBjb3JyZWN0IHRoZSBjb250YWN0IGluZm9ybWF0aW9uIHRoYXQgSSBt aXNzZWQgYmVmb3JlIHN1Ym1pdHRpbmcgb25lIG9mIHRoZSBkaXNjbG9zdXJlcywgYW5kIHRvIG1h a2UgYSBzZWNvbmQgbmVjZXNzYXJ5IHVwZGF0ZSBhZnRlciBzdWJtaXR0aW5nIHRoZSBmaXJzdCB1 cGRhdGUuIFdoZW4gSSBleHBsYWluZWQgdGhlIHNpdHVhdGlvbiB0byB0aGUgU2VjcmV0YXJpYXQs IHRoZXkgb2ZmZXJlZCB0byByZW1vdmUgdGhlIGV4dHJhIHVwZGF0ZXMgdG8gaGVscCBhdm9pZCBj b25mdXNpb24uIENoYW5nZXMgd2VyZSBtYWRlIHRvIHRoZSBjb250YWN0IGluZm9ybWF0aW9uLg0K DQoNCg0KU2NvdHQNCg0K --_000_4df86fc8bff14052b77c1340c9caefd3verisigncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQWRkICZsdDthZGQtYm91bmNlc0BpZXRm Lm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkRlZW4sIEdsZW5uPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgQXVndXN0IDI0LCAyMDIwIDc6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IFRlZCBI YXJkaWUgJmx0O3RlZC5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEFERCBNYWls aW5nIGxpc3QgJmx0O2FkZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVS TkFMXSBSZTogW0FkZF0gSVBSIERpc2Nsb3N1cmVzIHRvIEFERCBXRzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+SGkgVGVkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5M ZXQgbWUgY2hlY2sgd2l0aCB0aGUgc2VjcmV0YXJpYXQuJm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXJl IG9yaWdpbmFsbHkgd2hlcmUgMiBvdGhlciBJUFIgc3VibWlzc2lvbnMsIDQyNTggYW5kIDQyNjAs ICZuYnNwO3RoYXQgSSB3YXMgdG9sZCBoYWQgYmVlbiBjb21iaW5lZCBpbnRvIDQyNjEuICZuYnNw O1RoZXNlIG90aGVycyBhcmUgbm90IHZpc2libGUgaW4gdGhlIHN5c3RlbQ0KIHNvICZuYnNwO0kg bmVlZCB0byBjaGVjayB3aXRoIHRoZSBzZWNyZXRhcmlhdC4gWW91IGFyZSBjb3JyZWN0IHRoYXQg NDE2MSBkb2VzIHN0YXRlIHRoYXQgaXQgdXBkYXRlcyA0MjU3LiZuYnNwOyZuYnNwOyBJIHdpbGwg dmVyaWZ5IGFuZCBsZXQgdGhlIGxpc3Qga25vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPltTQUhdIDxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRl Ij5JIHN1Ym1pdHRlZCB0aGUgZGlzY2xvc3VyZXMgKGFuZCB0aGUgdXBkYXRlcykgdG8gbWVldCBv dXIgJnF1b3Q7Tm90ZSBXZWxsJnF1b3Q7IG9ibGlnYXRpb25zIHByaW9yIHRvIHBhcnRpY2lwYXRp bmcgaW4gd29ya2luZyBncm91cCBkaXNjdXNzaW9ucy4gVGhlIHVwZGF0ZXMgd2VyZSBtYWRlIHRv IGNvcnJlY3QgdGhlIGNvbnRhY3QgaW5mb3JtYXRpb24NCiB0aGF0IEkgbWlzc2VkIGJlZm9yZSBz dWJtaXR0aW5nIG9uZSBvZiB0aGUgZGlzY2xvc3VyZXMsIGFuZCB0byBtYWtlIGEgc2Vjb25kIG5l Y2Vzc2FyeSB1cGRhdGUgYWZ0ZXIgc3VibWl0dGluZyB0aGUgZmlyc3QgdXBkYXRlLiBXaGVuIEkg ZXhwbGFpbmVkIHRoZSBzaXR1YXRpb24gdG8gdGhlIFNlY3JldGFyaWF0LCB0aGV5IG9mZmVyZWQg dG8gcmVtb3ZlIHRoZSBleHRyYSB1cGRhdGVzIHRvIGhlbHAgYXZvaWQgY29uZnVzaW9uLiBDaGFu Z2VzIHdlcmUNCiBtYWRlIHRvIHRoZSBjb250YWN0IGluZm9ybWF0aW9uPC9zcGFuPi48bzpwPjwv bzpwPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PG86cD4mbmJzcDs8 L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPlNjb3R0PC9pPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4df86fc8bff14052b77c1340c9caefd3verisigncom_-- From nobody Wed Aug 26 03:10: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 EC1783A116D for ; Wed, 26 Aug 2020 03:10:12 -0700 (PDT) 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 Gohw04vJl6yQ for ; Wed, 26 Aug 2020 03:10:11 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 D81D73A116E for ; Wed, 26 Aug 2020 03:10:10 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id v6so1483457iow.11 for ; Wed, 26 Aug 2020 03:10:10 -0700 (PDT) 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=oZUVvFvPVpBAfPjd5uVvL4OHic82h0ZXHeGVnGUZnPY=; b=oh/iivlhfnssy36It0ndytdb5neMcot5pDtPeuhZlI+giQ1P6IWX3hvo5n1uVt6cae UdJ30m5IQgCUPKQmWpvmganEcaorcy6iMz9XsGmFjrG2uhMGZ6mvhPDmFsPy5UW8Br3T 6nBRvQlKz1a0UZDXnA+ZE9BugYX+WxYhhLSJIVk1bYh1VXH94bPtg053HluFf6PTQ2LA KSf0dzB5265uOYz+R7kbpeW/JY1Rp+mHtYQoieuaBtuBubZZ+qfhkLUGLeh5y6XALVRB 8/J9Dd1f/vJ+YzemC9pKdux2aX1qTSBo3KV3A6Tc21jgSngWSOlAC9o3kwXFR5BQQKBr WpLA== 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=oZUVvFvPVpBAfPjd5uVvL4OHic82h0ZXHeGVnGUZnPY=; b=qPP9Bak4909KSM3O+WeeRyi/t5BdGre1KsHokJ8YDecGW+ui9J/Z71GMFcfvac2Nvx 7oc8PpJnqyrH18lTSE/CR54xgiurW2LB71HlIKO3mB+0nB6ppRwWGQSVuG7CBKrOzBoX 2m7fRWXVFFvOqofAL3WGlHb0/5GXMKX/vIcX+XmTyNitpqJi3vqj2kFOxiaoQfafZFAt O6+NIQ5z14HqqfwHB4r9JvyYCB3Y2m01XY8+Zu8BVCQ61/Md0NBTrl/d9Oklp1AfEJqz +2IAEeV3YYfHPu7gkLSevlZ1CXFgphUXAQ/8DXFuFuUR5tA0UqLl/xriobdit8OJuA2O TXJg== X-Gm-Message-State: AOAM530sCi6kOKAT6M437r6DBVHdPKf4wPPlZrFxOr1XdKURezp/cDg7 wAxCG18FoKVd7/+y1QNbyyKh4Ge0I7V2RQ35vV8Xg/3WA5byuA== X-Google-Smtp-Source: ABdhPJz7ctX720/WJBy12SNmLfzGXVqYyziL4lOJ7LFvDgwRGviJrkvc42+njOQbawxAVNhq+OXPHahemnHCsPPfpn0= X-Received: by 2002:a02:c8c8:: with SMTP id q8mr6339061jao.46.1598436609958; Wed, 26 Aug 2020 03:10:09 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> In-Reply-To: <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> From: tirumal reddy Date: Wed, 26 Aug 2020 15:39:58 +0530 Message-ID: To: Christopher Wood Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000055259b05adc506fd" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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 Aug 2020 10:10:13 -0000 --00000000000055259b05adc506fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 25 Aug 2020 at 20:19, Christopher Wood wrote: > Thanks for the review! Please see inline below. > > On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote: > > Document: draft-pauly-add-requirements-00.txt > > > > Tommy, > > > > Thanks for posting this. Two comments on the threat model, > > requirements, and what mechanisms it leaves in scope. The points > > below are primarily about local discovery. > > > > > > 1. In S 4, you say you are assuming an RFC 3552 threat model that > > includes on-path active attackers. However, in S 2.1 you indicate that > > one of the benefits of this type of mechanism is to authenticate data > > coming from the true resolver: > > > > * Verify that answers come from the selected DNS resolver > > > > * Authenticate that the DNS resolver is the one provisioned by the > > network > > > > As a side note, I would observe that these benefits derive from the > > use of an authenticated channel, not from an encrypted channel. This > > is sort of a nit in that modern TLS profiles discourage authentication > > only, but I think it's still worth getting right. > > Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use of au= thenticated DoH > and DoT, but I can see how that=E2=80=99s confusing given that we later m= ention > opportunistic encryption (as a contrasting approach). > > > More importantly, this is only really true if either (1) the client > > can accurately determine the nonexistence of a secure resolver or (2) > > the client somehow behaves meaningfully differently in cases where > > it determines that there is no secure resolver. To lay this out in > > more detail, assuming that it's possible to determine the identity > > of a secure resolver if one is present (e.g., by the kind of SPAU > > mechanism that Chrome uses), then there are three cases: > > > > 1. The client connects to a secure resolver > > 2. No authenticated resolver is present > > 3. There is an attack > > > > While it's straightforward to determine whether one is in case (1), > > many users will be in case (2) and so as long as the client treats > > (1), (2), and (3) identically, then this doesn't preclude attack by > > on-path attackers. Thisisn't a new observation, of course, but I think > > it points to the need to sharpen the requirements and potentially > > S 4.2 if they are to be useful in the face of the threat model > > you define. > > That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3) = and (2) > differently, then the attacker can always win. And right now, given the > threat model, it=E2=80=99s unclear *if* a client can differentiate betwee= n these > cases. Or to put it differently (and I think this was how you phrased it > once in the past): the client can=E2=80=99t distinguish between a network= with no > authenticated resolver and an active attack. > > Perhaps we need to relax the attacker=E2=80=99s capabilities here? If DoH= is > blocked, then, well, what is a client left to do? Section 4.2 punts that > problem to the client=E2=80=99s policy, which seems (to me) to be the rig= ht way to > deal with this type of attack. > > Perhaps it=E2=80=99s worth clarifying that one of the motivations for the= se > requirements (and guidance text) is to allow for incremental improvements= . > For example, opportunistic encrypted DNS may be better than no encryption > for some clients. Although clients can=E2=80=99t determine if this is an = attack or > not, there=E2=80=99s arguably some benefit to it. Or put differently: the= attacker > may easily win for opportunistic DNS, but there may be cases where the > attacker loses, and that seems like an improvement. > > > 2. S 4 says that attackers must not be able to: > > > > * Redirect DNS traffic to themselves. > > > > If we try to map this onto the various proposed mechanisms, I think it > > has to be softened to say something like "Redirect secure DNS traffic > > to themselves when DNS traffic would not be" (again a 3552 attacker > > can say whatever they want in DHCP). I think this then precludes this > > mechanism having some kind of indicator of where the secure resolver > > is other than at its own IP. > > I think that=E2=80=99s right. None of the current discovery mechanisms wo= rk well > for local discovery when the attacker controls the network, since none of > the current signals are authenticated. > No, it is possible for the client to defend against an on-path attacker spoofing/blocking encrypted DNS server discovery, see https://tools.ietf.org/html/draft-btw-add-home-08#section-10 -Tiru > > Best, > Chris > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000055259b05adc506fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 25 Aug 2020 at 20:19, Christo= pher Wood <caw@heapingbits.net> wrote:
Tha= nks for the review! Please see inline below.

On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote:
> Document: draft-pauly-add-requirements-00.txt
>
> Tommy,
>
> Thanks for posting this. Two comments on the threat model,
> requirements, and what mechanisms it leaves in scope. The points
> below are primarily about local discovery.
>
>
> 1. In S 4, you say you are assuming an RFC 3552 threat model that
> includes on-path active attackers. However, in S 2.1 you indicate that=
> one of the benefits of this type of mechanism is to authenticate data<= br> > coming from the true resolver:
>
>=C2=A0 =C2=A0 *=C2=A0 Verify that answers come from the selected DNS re= solver
>
>=C2=A0 =C2=A0 *=C2=A0 Authenticate that the DNS resolver is the one pro= visioned by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0network
>
> As a side note, I would observe that these benefits derive from the > use of an authenticated channel, not from an encrypted channel. This > is sort of a nit in that modern TLS profiles discourage authentication=
> only, but I think it's still worth getting right.

Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use of auth= enticated DoH and DoT, but I can see how that=E2=80=99s confusing given tha= t we later mention opportunistic encryption (as a contrasting approach).
> More importantly, this is only really true if either (1) the client > can accurately determine the nonexistence of a secure resolver or (2)<= br> > the client somehow behaves meaningfully differently in cases where
> it determines that there is no secure resolver. To lay this out in
> more detail, assuming that it's possible to determine the identity=
> of a secure resolver if one is present (e.g., by the kind of SPAU
> mechanism that Chrome uses), then there are three cases:
>
> 1. The client connects to a secure resolver
> 2. No authenticated resolver is present
> 3. There is an attack
>
> While it's straightforward to determine whether one is in case (1)= ,
> many users will be in case (2) and so as long as the client treats
> (1), (2), and (3) identically, then this doesn't preclude attack b= y
> on-path attackers. Thisisn't a new observation, of course, but I t= hink
> it points to the need to sharpen the requirements and potentially
> S 4.2 if they are to be useful in the face of the threat model
> you define.

That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3) an= d (2) differently, then the attacker can always win. And right now, given t= he threat model, it=E2=80=99s unclear *if* a client can differentiate betwe= en these cases. Or to put it differently (and I think this was how you phra= sed it once in the past): the client can=E2=80=99t distinguish between a ne= twork with no authenticated resolver and an active attack.

Perhaps we need to relax the attacker=E2=80=99s capabilities here? If DoH i= s blocked, then, well, what is a client left to do? Section 4.2 punts that = problem to the client=E2=80=99s policy, which seems (to me) to be the right= way to deal with this type of attack.

Perhaps it=E2=80=99s worth clarifying that one of the motivations for these= requirements (and guidance text) is to allow for incremental improvements.= For example, opportunistic encrypted DNS may be better than no encryption = for some clients. Although clients can=E2=80=99t determine if this is an at= tack or not, there=E2=80=99s arguably some benefit to it. Or put differentl= y: the attacker may easily win for opportunistic DNS, but there may be case= s where the attacker loses, and that seems like an improvement.

> 2. S 4 says that attackers must not be able to:
>
>=C2=A0 =C2=A0 *=C2=A0 Redirect DNS traffic to themselves.
>
> If we try to map this onto the various proposed mechanisms, I think it=
> has to be softened to say something like "Redirect secure DNS tra= ffic
> to themselves when DNS traffic would not be" (again a 3552 attack= er
> can say whatever they want in DHCP). I think this then precludes this<= br> > mechanism having some kind of indicator of where the secure resolver > is other than at its own IP.

I think that=E2=80=99s right. None of the current discovery mechanisms work= well for local discovery when the attacker controls the network, since non= e of the current signals are authenticated.

=
No, it is possible for the client to defend against an on-path attacke= r spoofing/blocking encrypted=C2=A0

-Tiru
=C2=A0

Best,
Chris

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000055259b05adc506fd-- From nobody Wed Aug 26 04:20: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 111B03A0F2E for ; Wed, 26 Aug 2020 04:20:40 -0700 (PDT) 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 PRYOQ7eviuPN for ; Wed, 26 Aug 2020 04:20:38 -0700 (PDT) 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 9C7803A0F2A for ; Wed, 26 Aug 2020 04:20:37 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id 185so1890060ljj.7 for ; Wed, 26 Aug 2020 04:20:37 -0700 (PDT) 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=iGY3Ec6ZnbXo+miO62ArLkjOGUQ1xzpzCbJxVujSzrg=; b=sGPM3ARwWiNUHgzHqRwYLiUH1tESnM/3cmVPAax4L40YA+wTPUxb8L58P+PRZHWm53 BGaMsigYQUG7A3/YyP9F2XQSFSIHsbUI5V5t+aakYoLgqK/CKplhLXlBFmav7uUAeWKa saAGx8atV4dovxWBdT57v7EeNy1oatsO3pgZjUzk57Io/U++gkrAKxVeipW/Pjf66Q28 wY2KHL/G5qNQT/ghDfLwMx2TJaqz98FAbYhEiD1LBZ+7xJ56q/2vksDJGTH4j+FmI1rC n7JC175eLLVunbMQZ7X90ZnKZ11QJR+Xjm9fb1yBkRZT9MznEDVTCZ/oCMebtamQtdkI 4vQg== 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=iGY3Ec6ZnbXo+miO62ArLkjOGUQ1xzpzCbJxVujSzrg=; b=AdQY+G0eSNLXojuAYXj388JAZ1uObORKY1OjWjflEXQMXPgJmmgjbspOEwj1NCvVJm /Iw8Z8smPYdKTw4/ogXJNRSjn1/SoL80BsO/6UBzR+hjnGXWMKjeNA8acrZ7xdv1tlDz cu9EKtlkzpEuPgyH7ry/+YQKS064KsrFzRONRmt427l71szCSBGrBIV+kmvb/F2W52Of KmuK6LrqlljylxEaFabNVFHOBclGiJsY7WMUAH6KptTj0Ba8PnuhNz2sCz0rfwJIxHUk 0Xi5Coftd9uiCn1vSBO0OPp2feR2aAdWCvKE/3X9SNltdbZPx1l0OufOyALUXTwKC9Nn Wm1w== X-Gm-Message-State: AOAM530YBUcdv8BSwb8txP0Ph+ZjechgvxK+JARzVJgV5fYJRLVNjyXH vNQdxp8O+goZW5NhAZTuAvhAZ5iaiQ9BqMJB+BZyUw== X-Google-Smtp-Source: ABdhPJwgK848Km/L7Of7y1Bg4zcpH+Yv3mJ9dojWXb9/S2eDkilwbr/HZau2RYnbXxIn3HNHlz9SnSi3FgFltER1LrA= X-Received: by 2002:a2e:908a:: with SMTP id l10mr6654145ljg.409.1598440835837; Wed, 26 Aug 2020 04:20:35 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Wed, 26 Aug 2020 04:19:59 -0700 Message-ID: To: tirumal reddy Cc: Christopher Wood , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000037032d05adc60291" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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 Aug 2020 11:20:40 -0000 --00000000000037032d05adc60291 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2020 at 3:10 AM tirumal reddy wrote: > > > On Tue, 25 Aug 2020 at 20:19, Christopher Wood > wrote: > >> Thanks for the review! Please see inline below. >> >> On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote: >> > Document: draft-pauly-add-requirements-00.txt >> > >> > Tommy, >> > >> > Thanks for posting this. Two comments on the threat model, >> > requirements, and what mechanisms it leaves in scope. The points >> > below are primarily about local discovery. >> > >> > >> > 1. In S 4, you say you are assuming an RFC 3552 threat model that >> > includes on-path active attackers. However, in S 2.1 you indicate that >> > one of the benefits of this type of mechanism is to authenticate data >> > coming from the true resolver: >> > >> > * Verify that answers come from the selected DNS resolver >> > >> > * Authenticate that the DNS resolver is the one provisioned by the >> > network >> > >> > As a side note, I would observe that these benefits derive from the >> > use of an authenticated channel, not from an encrypted channel. This >> > is sort of a nit in that modern TLS profiles discourage authentication >> > only, but I think it's still worth getting right. >> >> Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use of a= uthenticated DoH >> and DoT, but I can see how that=E2=80=99s confusing given that we later = mention >> opportunistic encryption (as a contrasting approach). >> >> > More importantly, this is only really true if either (1) the client >> > can accurately determine the nonexistence of a secure resolver or (2) >> > the client somehow behaves meaningfully differently in cases where >> > it determines that there is no secure resolver. To lay this out in >> > more detail, assuming that it's possible to determine the identity >> > of a secure resolver if one is present (e.g., by the kind of SPAU >> > mechanism that Chrome uses), then there are three cases: >> > >> > 1. The client connects to a secure resolver >> > 2. No authenticated resolver is present >> > 3. There is an attack >> > >> > While it's straightforward to determine whether one is in case (1), >> > many users will be in case (2) and so as long as the client treats >> > (1), (2), and (3) identically, then this doesn't preclude attack by >> > on-path attackers. Thisisn't a new observation, of course, but I think >> > it points to the need to sharpen the requirements and potentially >> > S 4.2 if they are to be useful in the face of the threat model >> > you define. >> >> That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3)= and (2) >> differently, then the attacker can always win. And right now, given the >> threat model, it=E2=80=99s unclear *if* a client can differentiate betwe= en these >> cases. Or to put it differently (and I think this was how you phrased it >> once in the past): the client can=E2=80=99t distinguish between a networ= k with no >> authenticated resolver and an active attack. >> >> Perhaps we need to relax the attacker=E2=80=99s capabilities here? If Do= H is >> blocked, then, well, what is a client left to do? Section 4.2 punts that >> problem to the client=E2=80=99s policy, which seems (to me) to be the ri= ght way to >> deal with this type of attack. >> >> Perhaps it=E2=80=99s worth clarifying that one of the motivations for th= ese >> requirements (and guidance text) is to allow for incremental improvement= s. >> For example, opportunistic encrypted DNS may be better than no encryptio= n >> for some clients. Although clients can=E2=80=99t determine if this is an= attack or >> not, there=E2=80=99s arguably some benefit to it. Or put differently: th= e attacker >> may easily win for opportunistic DNS, but there may be cases where the >> attacker loses, and that seems like an improvement. >> >> > 2. S 4 says that attackers must not be able to: >> > >> > * Redirect DNS traffic to themselves. >> > >> > If we try to map this onto the various proposed mechanisms, I think it >> > has to be softened to say something like "Redirect secure DNS traffic >> > to themselves when DNS traffic would not be" (again a 3552 attacker >> > can say whatever they want in DHCP). I think this then precludes this >> > mechanism having some kind of indicator of where the secure resolver >> > is other than at its own IP. >> >> I think that=E2=80=99s right. None of the current discovery mechanisms w= ork well >> for local discovery when the attacker controls the network, since none o= f >> the current signals are authenticated. >> > > No, it is possible for the client to defend against an on-path attacker > spoofing/blocking encrypted > DNS server discovery, see > https://tools.ietf.org/html/draft-btw-add-home-08#section-10 > You describe three mechanisms. The first two seem to involve some sort of external configuration, and so are not of use in the generic case. I do not believe the third, STUN-based mechanism works. The attacker can make the client believe that it has any external IP of its choice by tunnelling the STUN traffic. -Ekr > -Tiru > > >> >> Best, >> Chris >> >> -- >> 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 > --00000000000037032d05adc60291 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 26, 2020 at 3:10 AM tirum= al reddy <kondtir@gmail.com>= wrote:


On Tue, 25 Aug 2020 at 20:19, Christopher Woo= d <caw@heapingb= its.net> wrote:
Thanks for the review! Please see inline below.

On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote:
> Document: draft-pauly-add-requirements-00.txt
>
> Tommy,
>
> Thanks for posting this. Two comments on the threat model,
> requirements, and what mechanisms it leaves in scope. The points
> below are primarily about local discovery.
>
>
> 1. In S 4, you say you are assuming an RFC 3552 threat model that
> includes on-path active attackers. However, in S 2.1 you indicate that=
> one of the benefits of this type of mechanism is to authenticate data<= br> > coming from the true resolver:
>
>=C2=A0 =C2=A0 *=C2=A0 Verify that answers come from the selected DNS re= solver
>
>=C2=A0 =C2=A0 *=C2=A0 Authenticate that the DNS resolver is the one pro= visioned by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0network
>
> As a side note, I would observe that these benefits derive from the > use of an authenticated channel, not from an encrypted channel. This > is sort of a nit in that modern TLS profiles discourage authentication=
> only, but I think it's still worth getting right.

Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use of auth= enticated DoH and DoT, but I can see how that=E2=80=99s confusing given tha= t we later mention opportunistic encryption (as a contrasting approach).
> More importantly, this is only really true if either (1) the client > can accurately determine the nonexistence of a secure resolver or (2)<= br> > the client somehow behaves meaningfully differently in cases where
> it determines that there is no secure resolver. To lay this out in
> more detail, assuming that it's possible to determine the identity=
> of a secure resolver if one is present (e.g., by the kind of SPAU
> mechanism that Chrome uses), then there are three cases:
>
> 1. The client connects to a secure resolver
> 2. No authenticated resolver is present
> 3. There is an attack
>
> While it's straightforward to determine whether one is in case (1)= ,
> many users will be in case (2) and so as long as the client treats
> (1), (2), and (3) identically, then this doesn't preclude attack b= y
> on-path attackers. Thisisn't a new observation, of course, but I t= hink
> it points to the need to sharpen the requirements and potentially
> S 4.2 if they are to be useful in the face of the threat model
> you define.

That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3) an= d (2) differently, then the attacker can always win. And right now, given t= he threat model, it=E2=80=99s unclear *if* a client can differentiate betwe= en these cases. Or to put it differently (and I think this was how you phra= sed it once in the past): the client can=E2=80=99t distinguish between a ne= twork with no authenticated resolver and an active attack.

Perhaps we need to relax the attacker=E2=80=99s capabilities here? If DoH i= s blocked, then, well, what is a client left to do? Section 4.2 punts that = problem to the client=E2=80=99s policy, which seems (to me) to be the right= way to deal with this type of attack.

Perhaps it=E2=80=99s worth clarifying that one of the motivations for these= requirements (and guidance text) is to allow for incremental improvements.= For example, opportunistic encrypted DNS may be better than no encryption = for some clients. Although clients can=E2=80=99t determine if this is an at= tack or not, there=E2=80=99s arguably some benefit to it. Or put differentl= y: the attacker may easily win for opportunistic DNS, but there may be case= s where the attacker loses, and that seems like an improvement.

> 2. S 4 says that attackers must not be able to:
>
>=C2=A0 =C2=A0 *=C2=A0 Redirect DNS traffic to themselves.
>
> If we try to map this onto the various proposed mechanisms, I think it=
> has to be softened to say something like "Redirect secure DNS tra= ffic
> to themselves when DNS traffic would not be" (again a 3552 attack= er
> can say whatever they want in DHCP). I think this then precludes this<= br> > mechanism having some kind of indicator of where the secure resolver > is other than at its own IP.

I think that=E2=80=99s right. None of the current discovery mechanisms work= well for local discovery when the attacker controls the network, since non= e of the current signals are authenticated.

=
No, it is possible for the client to defend against an on-path attacke= r spoofing/blocking encrypted=C2=A0

You describe thr= ee mechanisms. The first two seem to involve some sort of external configur= ation, and so are not of use in the generic case.

= I do not believe the third, STUN-based mechanism works. The attacker can ma= ke the client believe that it has any external IP of its choice by tunnelli= ng the STUN traffic.

-Ekr


-Tiru
=C2=A0

Best,
Chris

--
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
--00000000000037032d05adc60291-- From nobody Wed Aug 26 22:15:07 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 46AC83A0D0E for ; Wed, 26 Aug 2020 22:15:05 -0700 (PDT) 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 u01cOUHY8at3 for ; Wed, 26 Aug 2020 22:15:01 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 D140E3A0CEB for ; Wed, 26 Aug 2020 22:15:00 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id j9so3839950ilc.11 for ; Wed, 26 Aug 2020 22:15:00 -0700 (PDT) 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=ULyKpm39cCgeMXGMEozo0jhXHSc4f9I/IflFz/gLK/s=; b=Ee+nlnVtKkXPd7orxzDHPNTcpi7LU7C/xnPh4Pp0qhJjYIn+zrDMSfICqZSmuuJADN Jc4maSOQZ8zK6Hy2hhFCr+koStgXOOM6u1DD4vhfkkxYmoS+7YN3BAqWn5mW60I4UDHJ QTGJBrftHog4OB1E0RcmTQ9Ph3p8eNxIHnAXeEYj1CNFob7PyyY9BYHKZcd8NA3K79st K+3U7ga9aRhvhbPEjCQLjtRv9gbihWLYAvyQ8CMDwqCTFhFrCw9ARi7xtsJ01qfw7JFS gqJ0Sw16CU11BX/lrd9FvcOycF0ertXFWk/r4TlLN8bRZXwcBrve7Ps7zQp9MTNYDBD2 tqGA== 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=ULyKpm39cCgeMXGMEozo0jhXHSc4f9I/IflFz/gLK/s=; b=Q4IuV3bJyOha3PEe7EhgAdTrMDbBB33Zh+IP6V52mAqy3C1E03Gzn6FyDwpXX9GKaD a/JlpUaOuX2yM1qqrQkZXj4mQvH5LuIRqTDfxXrnw+KZfvFerXPemsInGv9bUEJegOcB E7/pVzdzC1OZ84r8sJgHIta51HNtiMNQ0RlT1/HorXjguh5T+hVra3sLEYo08bz6kgPj n6bxsScwiY8UA76zShvUWm/xOnwt4K/OWY7BuZnrXpOBPPZd5cr9kKdr1DAhUDH/kuUK bi4H/45AmwM8Cc2rkHXMb3ppeTsJsOoz8PmeUJ9jWP9xHheNcTXQZCqArlUWi/tN8cLy 9s5w== X-Gm-Message-State: AOAM531XldwmF/y+hVqdfZaa2bq9iXgUXPKJWXGs5bxPJwQXRH7twe9h PKE7TuHPMKz7BDQX7YyuKX0DTtcuJjsbosv2kbRERMhEPrfgfw== X-Google-Smtp-Source: ABdhPJzBBaReJQL/ZDXyVaEgkUyS0HdahC4r9d3LOY9fKlh2ELdLH38FRyiZ0n9Kr49sHRdPn0FhqyUNXQUdrvp48uM= X-Received: by 2002:a92:c50e:: with SMTP id r14mr16385640ilg.161.1598505299858; Wed, 26 Aug 2020 22:14:59 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> In-Reply-To: From: tirumal reddy Date: Thu, 27 Aug 2020 10:44:47 +0530 Message-ID: To: Eric Rescorla Cc: Christopher Wood , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000091da7e05add50439" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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, 27 Aug 2020 05:15:05 -0000 --00000000000091da7e05add50439 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric, Please see inline On Wed, 26 Aug 2020 at 16:50, Eric Rescorla wrote: > > > On Wed, Aug 26, 2020 at 3:10 AM tirumal reddy wrote: > >> >> >> On Tue, 25 Aug 2020 at 20:19, Christopher Wood >> wrote: >> >>> Thanks for the review! Please see inline below. >>> >>> On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote: >>> > Document: draft-pauly-add-requirements-00.txt >>> > >>> > Tommy, >>> > >>> > Thanks for posting this. Two comments on the threat model, >>> > requirements, and what mechanisms it leaves in scope. The points >>> > below are primarily about local discovery. >>> > >>> > >>> > 1. In S 4, you say you are assuming an RFC 3552 threat model that >>> > includes on-path active attackers. However, in S 2.1 you indicate tha= t >>> > one of the benefits of this type of mechanism is to authenticate data >>> > coming from the true resolver: >>> > >>> > * Verify that answers come from the selected DNS resolver >>> > >>> > * Authenticate that the DNS resolver is the one provisioned by th= e >>> > network >>> > >>> > As a side note, I would observe that these benefits derive from the >>> > use of an authenticated channel, not from an encrypted channel. This >>> > is sort of a nit in that modern TLS profiles discourage authenticatio= n >>> > only, but I think it's still worth getting right. >>> >>> Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use of = authenticated DoH >>> and DoT, but I can see how that=E2=80=99s confusing given that we later= mention >>> opportunistic encryption (as a contrasting approach). >>> >>> > More importantly, this is only really true if either (1) the client >>> > can accurately determine the nonexistence of a secure resolver or (2) >>> > the client somehow behaves meaningfully differently in cases where >>> > it determines that there is no secure resolver. To lay this out in >>> > more detail, assuming that it's possible to determine the identity >>> > of a secure resolver if one is present (e.g., by the kind of SPAU >>> > mechanism that Chrome uses), then there are three cases: >>> > >>> > 1. The client connects to a secure resolver >>> > 2. No authenticated resolver is present >>> > 3. There is an attack >>> > >>> > While it's straightforward to determine whether one is in case (1), >>> > many users will be in case (2) and so as long as the client treats >>> > (1), (2), and (3) identically, then this doesn't preclude attack by >>> > on-path attackers. Thisisn't a new observation, of course, but I thin= k >>> > it points to the need to sharpen the requirements and potentially >>> > S 4.2 if they are to be useful in the face of the threat model >>> > you define. >>> >>> That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3= ) and (2) >>> differently, then the attacker can always win. And right now, given the >>> threat model, it=E2=80=99s unclear *if* a client can differentiate betw= een these >>> cases. Or to put it differently (and I think this was how you phrased i= t >>> once in the past): the client can=E2=80=99t distinguish between a netwo= rk with no >>> authenticated resolver and an active attack. >>> >>> Perhaps we need to relax the attacker=E2=80=99s capabilities here? If D= oH is >>> blocked, then, well, what is a client left to do? Section 4.2 punts tha= t >>> problem to the client=E2=80=99s policy, which seems (to me) to be the r= ight way to >>> deal with this type of attack. >>> >>> Perhaps it=E2=80=99s worth clarifying that one of the motivations for t= hese >>> requirements (and guidance text) is to allow for incremental improvemen= ts. >>> For example, opportunistic encrypted DNS may be better than no encrypti= on >>> for some clients. Although clients can=E2=80=99t determine if this is a= n attack or >>> not, there=E2=80=99s arguably some benefit to it. Or put differently: t= he attacker >>> may easily win for opportunistic DNS, but there may be cases where the >>> attacker loses, and that seems like an improvement. >>> >>> > 2. S 4 says that attackers must not be able to: >>> > >>> > * Redirect DNS traffic to themselves. >>> > >>> > If we try to map this onto the various proposed mechanisms, I think i= t >>> > has to be softened to say something like "Redirect secure DNS traffic >>> > to themselves when DNS traffic would not be" (again a 3552 attacker >>> > can say whatever they want in DHCP). I think this then precludes this >>> > mechanism having some kind of indicator of where the secure resolver >>> > is other than at its own IP. >>> >>> I think that=E2=80=99s right. None of the current discovery mechanisms = work well >>> for local discovery when the attacker controls the network, since none = of >>> the current signals are authenticated. >>> >> >> No, it is possible for the client to defend against an on-path attacker >> spoofing/blocking encrypted >> DNS server discovery, see >> https://tools.ietf.org/html/draft-btw-add-home-08#section-10 >> > > You describe three mechanisms. The first two seem to involve some sort of > external configuration, and so are not of use in the generic case. > No, only the first mechanism requires external configuration. Please clarify why you think the three mechanisms are not generic ? > > I do not believe the third, STUN-based mechanism works. The attacker can > make the client believe that it has any external IP of its choice by > tunnelling the STUN traffic. > Yes, it may be easy for an attacker to identify STUN traffic but challenging to identify TURN server running on port 443 (TURN-over-TLS). Further, an attacker may or may not be always on-path and the client can remember that an encrypted resolver is provided by the attached network (e.g., associate the domain name/organization hosting the encrypted resolver with the SSID:BSSID). If later the endpoint cannot discover the network-provided resolver, it can assume an attacker blocked the discovery. -Tiru > > -Ekr > > >> -Tiru >> >> >>> >>> Best, >>> Chris >>> >>> -- >>> 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 >> > --00000000000091da7e05add50439 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

Please see inline

On Wed, 26 Aug 2020 at 16:50, Eric Resc= orla <ekr@rtfm.com> wrote:


On Wed, Aug 26, 2020 at 3:10 AM = tirumal reddy <ko= ndtir@gmail.com> wrote:


On Tue, 25 Aug 2020 = at 20:19, Christopher Wood <caw@heapingbits.net> wrote:
Thanks for the review! Please see inline b= elow.

On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote:
> Document: draft-pauly-add-requirements-00.txt
>
> Tommy,
>
> Thanks for posting this. Two comments on the threat model,
> requirements, and what mechanisms it leaves in scope. The points
> below are primarily about local discovery.
>
>
> 1. In S 4, you say you are assuming an RFC 3552 threat model that
> includes on-path active attackers. However, in S 2.1 you indicate that=
> one of the benefits of this type of mechanism is to authenticate data<= br> > coming from the true resolver:
>
>=C2=A0 =C2=A0 *=C2=A0 Verify that answers come from the selected DNS re= solver
>
>=C2=A0 =C2=A0 *=C2=A0 Authenticate that the DNS resolver is the one pro= visioned by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0network
>
> As a side note, I would observe that these benefits derive from the > use of an authenticated channel, not from an encrypted channel. This > is sort of a nit in that modern TLS profiles discourage authentication=
> only, but I think it's still worth getting right.

Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use of auth= enticated DoH and DoT, but I can see how that=E2=80=99s confusing given tha= t we later mention opportunistic encryption (as a contrasting approach).
> More importantly, this is only really true if either (1) the client > can accurately determine the nonexistence of a secure resolver or (2)<= br> > the client somehow behaves meaningfully differently in cases where
> it determines that there is no secure resolver. To lay this out in
> more detail, assuming that it's possible to determine the identity=
> of a secure resolver if one is present (e.g., by the kind of SPAU
> mechanism that Chrome uses), then there are three cases:
>
> 1. The client connects to a secure resolver
> 2. No authenticated resolver is present
> 3. There is an attack
>
> While it's straightforward to determine whether one is in case (1)= ,
> many users will be in case (2) and so as long as the client treats
> (1), (2), and (3) identically, then this doesn't preclude attack b= y
> on-path attackers. Thisisn't a new observation, of course, but I t= hink
> it points to the need to sharpen the requirements and potentially
> S 4.2 if they are to be useful in the face of the threat model
> you define.

That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3) an= d (2) differently, then the attacker can always win. And right now, given t= he threat model, it=E2=80=99s unclear *if* a client can differentiate betwe= en these cases. Or to put it differently (and I think this was how you phra= sed it once in the past): the client can=E2=80=99t distinguish between a ne= twork with no authenticated resolver and an active attack.

Perhaps we need to relax the attacker=E2=80=99s capabilities here? If DoH i= s blocked, then, well, what is a client left to do? Section 4.2 punts that = problem to the client=E2=80=99s policy, which seems (to me) to be the right= way to deal with this type of attack.

Perhaps it=E2=80=99s worth clarifying that one of the motivations for these= requirements (and guidance text) is to allow for incremental improvements.= For example, opportunistic encrypted DNS may be better than no encryption = for some clients. Although clients can=E2=80=99t determine if this is an at= tack or not, there=E2=80=99s arguably some benefit to it. Or put differentl= y: the attacker may easily win for opportunistic DNS, but there may be case= s where the attacker loses, and that seems like an improvement.

> 2. S 4 says that attackers must not be able to:
>
>=C2=A0 =C2=A0 *=C2=A0 Redirect DNS traffic to themselves.
>
> If we try to map this onto the various proposed mechanisms, I think it=
> has to be softened to say something like "Redirect secure DNS tra= ffic
> to themselves when DNS traffic would not be" (again a 3552 attack= er
> can say whatever they want in DHCP). I think this then precludes this<= br> > mechanism having some kind of indicator of where the secure resolver > is other than at its own IP.

I think that=E2=80=99s right. None of the current discovery mechanisms work= well for local discovery when the attacker controls the network, since non= e of the current signals are authenticated.

=
No, it is possible for the client to defend against an on-path attacke= r spoofing/blocking encrypted=C2=A0

You describe thr= ee mechanisms. The first two seem to involve some sort of external configur= ation, and so are not of use in the generic case.

No, only the first mechanism requires external con= figuration. Please clarify why you think the three mechanisms are not gener= ic ?
=C2=A0

I do not = believe the third, STUN-based mechanism works. The attacker can make the cl= ient believe that it has any external IP of its choice by tunnelling the ST= UN traffic.

Yes, it may b= e easy for an attacker to identify STUN traffic but challenging to identify= TURN server running on port 443 (TURN-over-TLS).=C2=A0

Further, an attacker may or may not be always on-path and the client = can remember=C2=A0that an encrypted resolver is provided by the attached network (e.g., associate the domain name/organizat= ion hosting the encrypted resolver with the SSID:BSSID). If later the endpo= int cannot discover the network-provided resolver, it can assume an attacker blocked the discovery.

-T= iru
=C2=A0

-Ekr


-Tiru
= =C2=A0

Best,
Chris

--
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
--00000000000091da7e05add50439-- From nobody Thu Aug 27 06:16: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 638B63A0898 for ; Thu, 27 Aug 2020 06:16:35 -0700 (PDT) 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 TT5LhrE60fcM for ; Thu, 27 Aug 2020 06:16:33 -0700 (PDT) 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 889663A086D for ; Thu, 27 Aug 2020 06:16:32 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id t23so6382235ljc.3 for ; Thu, 27 Aug 2020 06:16:32 -0700 (PDT) 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=IztxJzGtTPsEqIY1YGNBNUdE0j1TFk181OYR8FjM3HE=; b=dsCMnI7abVCR4wIYkU7ISEg3l07VNi3O5yitSDI3MP6X4lPJIkl6ujlM+17RBf9qPy qS6+fh5xF4/KMZA2y0rril12kYLZuQmUE5Uw0Iade3yO96SHJ1argV6aV7ElRInTWLaG p6OFy8h4B2FdWPs3iJ0mUnv//8wx7HfrSQPn16LuTfoLgcX//Ty76WUKZ9XBdHMOKWY9 lpCP7nBu0kme7cR87MYNOjxpkqQRPwMZcoHNR7KsxBXFtc+LnFyHlP8swRaeNs/D1FVz 8uhHzGTpaX9qkczodPKa9hTlVreioLrTCFRS4Gqel6CZGgcyElKhm/mdpIuHZ6WKRqli iQXg== 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=IztxJzGtTPsEqIY1YGNBNUdE0j1TFk181OYR8FjM3HE=; b=awNSKKu5PMZzOYUoAa7A9x3QX5Eeke/uMo3M7Z1zRk9oC6ObBuj34lhN35t7PgEOFV ApdRyDFXwoA1gPpLnotR3lVwzCjp/EdhFANOKlItlL5DZyqGq6//EM7xeHY+X9l+0sUv mPi7BMkY0bfc8qkGx6ltqkuuNg2FaO1GE+aKnpMW+VA9qF8snfD44LHJl2mT/yU2iuuO Q1U7+V45cnQ8Oo/RCOEe0SvCFOcL4LQnww5G72rCoTaRmeVMPGWNoLFYgtwj2xlSFIAK 7fuqP1e81EZVSjVRoSsqFSfTt1xUv6SWp04+PUPGYom4fvxowhr3g/w7HC8nK6vhHgPe v0VQ== X-Gm-Message-State: AOAM5337r7Gb6o6z6H0n8mbKkgr2+iHcds3ZDBx7stC4xPHtFer6FJrR FBqDbuML10cdj+l2FJeDdzMKbcx4wp7lXpDQ/T6n/bU5hNaZq0d2 X-Google-Smtp-Source: ABdhPJxfR51HLi6AJBf+FlrDfd+e0Y+mhs43ggcSRTzArVZ0O+O027lM+RnWlLbdeKGRUdshkZa0F+uY2r95ILvL2cI= X-Received: by 2002:a2e:9ace:: with SMTP id p14mr1315978ljj.199.1598534190558; Thu, 27 Aug 2020 06:16:30 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Thu, 27 Aug 2020 06:15:53 -0700 Message-ID: To: tirumal reddy Cc: Christopher Wood , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000970a0405addbbe9c" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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, 27 Aug 2020 13:16:35 -0000 --000000000000970a0405addbbe9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2020 at 10:15 PM tirumal reddy wrote: > Hi Eric, > > Please see inline > > On Wed, 26 Aug 2020 at 16:50, Eric Rescorla wrote: > >> >> >> On Wed, Aug 26, 2020 at 3:10 AM tirumal reddy wrote: >> >>> >>> >>> On Tue, 25 Aug 2020 at 20:19, Christopher Wood >>> wrote: >>> >>>> Thanks for the review! Please see inline below. >>>> >>>> On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote: >>>> > Document: draft-pauly-add-requirements-00.txt >>>> > >>>> > Tommy, >>>> > >>>> > Thanks for posting this. Two comments on the threat model, >>>> > requirements, and what mechanisms it leaves in scope. The points >>>> > below are primarily about local discovery. >>>> > >>>> > >>>> > 1. In S 4, you say you are assuming an RFC 3552 threat model that >>>> > includes on-path active attackers. However, in S 2.1 you indicate th= at >>>> > one of the benefits of this type of mechanism is to authenticate dat= a >>>> > coming from the true resolver: >>>> > >>>> > * Verify that answers come from the selected DNS resolver >>>> > >>>> > * Authenticate that the DNS resolver is the one provisioned by t= he >>>> > network >>>> > >>>> > As a side note, I would observe that these benefits derive from the >>>> > use of an authenticated channel, not from an encrypted channel. This >>>> > is sort of a nit in that modern TLS profiles discourage authenticati= on >>>> > only, but I think it's still worth getting right. >>>> >>>> Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use of= authenticated >>>> DoH and DoT, but I can see how that=E2=80=99s confusing given that we = later mention >>>> opportunistic encryption (as a contrasting approach). >>>> >>>> > More importantly, this is only really true if either (1) the client >>>> > can accurately determine the nonexistence of a secure resolver or (2= ) >>>> > the client somehow behaves meaningfully differently in cases where >>>> > it determines that there is no secure resolver. To lay this out in >>>> > more detail, assuming that it's possible to determine the identity >>>> > of a secure resolver if one is present (e.g., by the kind of SPAU >>>> > mechanism that Chrome uses), then there are three cases: >>>> > >>>> > 1. The client connects to a secure resolver >>>> > 2. No authenticated resolver is present >>>> > 3. There is an attack >>>> > >>>> > While it's straightforward to determine whether one is in case (1), >>>> > many users will be in case (2) and so as long as the client treats >>>> > (1), (2), and (3) identically, then this doesn't preclude attack by >>>> > on-path attackers. Thisisn't a new observation, of course, but I thi= nk >>>> > it points to the need to sharpen the requirements and potentially >>>> > S 4.2 if they are to be useful in the face of the threat model >>>> > you define. >>>> >>>> That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (= 3) and (2) >>>> differently, then the attacker can always win. And right now, given th= e >>>> threat model, it=E2=80=99s unclear *if* a client can differentiate bet= ween these >>>> cases. Or to put it differently (and I think this was how you phrased = it >>>> once in the past): the client can=E2=80=99t distinguish between a netw= ork with no >>>> authenticated resolver and an active attack. >>>> >>>> Perhaps we need to relax the attacker=E2=80=99s capabilities here? If = DoH is >>>> blocked, then, well, what is a client left to do? Section 4.2 punts th= at >>>> problem to the client=E2=80=99s policy, which seems (to me) to be the = right way to >>>> deal with this type of attack. >>>> >>>> Perhaps it=E2=80=99s worth clarifying that one of the motivations for = these >>>> requirements (and guidance text) is to allow for incremental improveme= nts. >>>> For example, opportunistic encrypted DNS may be better than no encrypt= ion >>>> for some clients. Although clients can=E2=80=99t determine if this is = an attack or >>>> not, there=E2=80=99s arguably some benefit to it. Or put differently: = the attacker >>>> may easily win for opportunistic DNS, but there may be cases where the >>>> attacker loses, and that seems like an improvement. >>>> >>>> > 2. S 4 says that attackers must not be able to: >>>> > >>>> > * Redirect DNS traffic to themselves. >>>> > >>>> > If we try to map this onto the various proposed mechanisms, I think = it >>>> > has to be softened to say something like "Redirect secure DNS traffi= c >>>> > to themselves when DNS traffic would not be" (again a 3552 attacker >>>> > can say whatever they want in DHCP). I think this then precludes thi= s >>>> > mechanism having some kind of indicator of where the secure resolver >>>> > is other than at its own IP. >>>> >>>> I think that=E2=80=99s right. None of the current discovery mechanisms= work >>>> well for local discovery when the attacker controls the network, since= none >>>> of the current signals are authenticated. >>>> >>> >>> No, it is possible for the client to defend against an on-path attacker >>> spoofing/blocking encrypted >>> DNS server discovery, see >>> https://tools.ietf.org/html/draft-btw-add-home-08#section-10 >>> >> >> You describe three mechanisms. The first two seem to involve some sort o= f >> external configuration, and so are not of use in the generic case. >> > > No, only the first mechanism requires external configuration. Please > clarify why you think the three mechanisms are not generic ? > " Cryptographically assert the DNS server identity to identify the DNS client is connecting to an encrypted DNS server hosted by a specific organization" The client has no way of knowing what organizations are acceptable. The reason these aren't generic is that clients in general will not be so configured. > > >> >> I do not believe the third, STUN-based mechanism works. The attacker can >> make the client believe that it has any external IP of its choice by >> tunnelling the STUN traffic. >> > > Yes, it may be easy for an attacker to identify STUN traffic but > challenging to identify TURN server running on port 443 (TURN-over-TLS). > Well, it will be public information (because it's embedded in many clients) where the servers are. Further, an attacker may or may not be always on-path and the client can > remember that an encrypted resolver is provided by the attached network > (e.g., associate the domain name/organization hosting the encrypted > resolver with the SSID:BSSID). If later the endpoint cannot discover the > network-provided resolver, it can assume an attacker blocked the discover= y. > Or that network conditions changed in some way or other, which might result in unacceptable numbers of false positives. In any case, this is a weaker threat model than described in the draft. -Ekr > -Tiru > > >> >> -Ekr >> >> >>> -Tiru >>> >>> >>>> >>>> Best, >>>> Chris >>>> >>>> -- >>>> 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 >>> >> --000000000000970a0405addbbe9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 26, 2020 at 10:15 PM tiru= mal reddy <kondtir@gmail.com>= ; wrote:
Hi Eric,

Please see inline

On Wed, 26 Aug 2020 at 16:50, Eric Rescorla &l= t;ekr@rtfm.com> wr= ote:


On Wed, Aug 26, 2020= at 3:10 AM tirumal reddy <kondtir@gmail.com> wrote:

On Tue, = 25 Aug 2020 at 20:19, Christopher Wood <caw@heapingbits.net> wrote:
Thanks for the review! Please s= ee inline below.

On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote:
> Document: draft-pauly-add-requirements-00.txt
>
> Tommy,
>
> Thanks for posting this. Two comments on the threat model,
> requirements, and what mechanisms it leaves in scope. The points
> below are primarily about local discovery.
>
>
> 1. In S 4, you say you are assuming an RFC 3552 threat model that
> includes on-path active attackers. However, in S 2.1 you indicate that=
> one of the benefits of this type of mechanism is to authenticate data<= br> > coming from the true resolver:
>
>=C2=A0 =C2=A0 *=C2=A0 Verify that answers come from the selected DNS re= solver
>
>=C2=A0 =C2=A0 *=C2=A0 Authenticate that the DNS resolver is the one pro= visioned by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0network
>
> As a side note, I would observe that these benefits derive from the > use of an authenticated channel, not from an encrypted channel. This > is sort of a nit in that modern TLS profiles discourage authentication=
> only, but I think it's still worth getting right.

Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use of auth= enticated DoH and DoT, but I can see how that=E2=80=99s confusing given tha= t we later mention opportunistic encryption (as a contrasting approach).
> More importantly, this is only really true if either (1) the client > can accurately determine the nonexistence of a secure resolver or (2)<= br> > the client somehow behaves meaningfully differently in cases where
> it determines that there is no secure resolver. To lay this out in
> more detail, assuming that it's possible to determine the identity=
> of a secure resolver if one is present (e.g., by the kind of SPAU
> mechanism that Chrome uses), then there are three cases:
>
> 1. The client connects to a secure resolver
> 2. No authenticated resolver is present
> 3. There is an attack
>
> While it's straightforward to determine whether one is in case (1)= ,
> many users will be in case (2) and so as long as the client treats
> (1), (2), and (3) identically, then this doesn't preclude attack b= y
> on-path attackers. Thisisn't a new observation, of course, but I t= hink
> it points to the need to sharpen the requirements and potentially
> S 4.2 if they are to be useful in the face of the threat model
> you define.

That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3) an= d (2) differently, then the attacker can always win. And right now, given t= he threat model, it=E2=80=99s unclear *if* a client can differentiate betwe= en these cases. Or to put it differently (and I think this was how you phra= sed it once in the past): the client can=E2=80=99t distinguish between a ne= twork with no authenticated resolver and an active attack.

Perhaps we need to relax the attacker=E2=80=99s capabilities here? If DoH i= s blocked, then, well, what is a client left to do? Section 4.2 punts that = problem to the client=E2=80=99s policy, which seems (to me) to be the right= way to deal with this type of attack.

Perhaps it=E2=80=99s worth clarifying that one of the motivations for these= requirements (and guidance text) is to allow for incremental improvements.= For example, opportunistic encrypted DNS may be better than no encryption = for some clients. Although clients can=E2=80=99t determine if this is an at= tack or not, there=E2=80=99s arguably some benefit to it. Or put differentl= y: the attacker may easily win for opportunistic DNS, but there may be case= s where the attacker loses, and that seems like an improvement.

> 2. S 4 says that attackers must not be able to:
>
>=C2=A0 =C2=A0 *=C2=A0 Redirect DNS traffic to themselves.
>
> If we try to map this onto the various proposed mechanisms, I think it=
> has to be softened to say something like "Redirect secure DNS tra= ffic
> to themselves when DNS traffic would not be" (again a 3552 attack= er
> can say whatever they want in DHCP). I think this then precludes this<= br> > mechanism having some kind of indicator of where the secure resolver > is other than at its own IP.

I think that=E2=80=99s right. None of the current discovery mechanisms work= well for local discovery when the attacker controls the network, since non= e of the current signals are authenticated.

=
No, it is possible for the client to defend against an on-path attacke= r spoofing/blocking encrypted=C2=A0

You describe thr= ee mechanisms. The first two seem to involve some sort of external configur= ation, and so are not of use in the generic case.

No, only the first mechanism requires external con= figuration. Please clarify why you think the three mechanisms are not gener= ic ?

" Cryptographic= ally assert the DNS server identity to identify the DNS client is conn= ecting to an encrypted DNS server hosted by a specific organization&qu= ot;

The client has no way of knowing what organiza= tions are acceptable.

The reason these aren't = generic is that clients in general will not be so configured.
=C2=A0

I do not believe the third, STUN-based mechanism works. The attack= er can make the client believe that it has any external IP of its choice by= tunnelling the STUN traffic.

=
Yes, it may be easy for an attacker to identify STUN traffic but chall= enging to identify TURN server running on port 443 (TURN-over-TLS).=C2=A0

Well, it will be public in= formation (because it's embedded in many clients) where the servers are= .


Further, = an attacker may or may not be always on-path and the client can remember=C2= =A0that an en= crypted resolver is provided by the attached network (e.g., associate the domain name/organizat= ion hosting the encrypted resolver with the SSID:BSSID). If later the endpo= int cannot discover the network-provided resolver, it can assume an attacker blocked the discovery.

Or that network conditions changed in some way = or other, which might result in unacceptable numbers of false positives.
In any case, this is a weaker threat model than described in t= he draft.

-Ekr

=
-Tiru
=C2=A0

-Ekr

--000000000000970a0405addbbe9c-- From nobody Thu Aug 27 07:52: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 7B7543A0E15 for ; Thu, 27 Aug 2020 07:52:34 -0700 (PDT) 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, 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 (2048-bit key) header.d=heapingbits.net header.b=n1Hxx53A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qTjIqW6o 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 Z-DDFBKUzJgN for ; Thu, 27 Aug 2020 07:52:32 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2BC3A0E0F for ; Thu, 27 Aug 2020 07:52:32 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2F5155C022E; Thu, 27 Aug 2020 10:52:31 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Thu, 27 Aug 2020 10:52:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=zN w4+guRdy6YMWic7IOPc+9FDpZpRk+DBWxfA3SpowQ=; b=n1Hxx53AvK0tN6jzbq b2Uz4YeHPA1GJQSVlEzi2tetcmUVkp9WQFGeI9F0YUDaTCk+JzHbCNWTJ+LqyGKk 2gJSYu6RmJLSERR4jh+txkaAXuA40OPuDAKpvmIx3H1LJnOPWkmOKX+c8v418HF5 w4QX33HyLG/E/WOHz5l2uXgnA46FpM6K+3foRK9jQMDnbsNIJxFLVGzdGvYTIpaC VSFduzyHRLDyG03aZDlUnBqQGhvtSH6TmEq3BMNTPFjrYqLXk6dMWbbo4gN7WA3t 9T4GoT6L5xLAqfPPuMsxXb6m/ovo9KSwiR1z0fWGcbiatqyYoDMSqCmWDwI7YFel t/PQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=zNw4+guRdy6YMWic7IOPc+9FDpZpRk+DBWxfA3Spo wQ=; b=qTjIqW6obYHoVGsILb9pVA1cAL0yH4nxMzEXxx5j9YrQsbJmPk2sMoIY7 OIIFlo4gQ/2F3sJC8reaiKMslAnlvszI4c/x/Dc0pW41aaNx9gbgFc25+rf20lQ+ 6WPSZWNNHTCSwwJ8xINLyyIymGNjJFHV9DCzryOg1QPmeQ561NmPln+ZFnOWBpqq LhNUYQUbZM61FjDKDSSeYWo3f/pBiQ3ghSd0AD44r/PSp6ytdfy2M+GUs2e2Bp8e mOwYbadHRuHbVQuVbVYIb0zpfQPC0/pHsOIf3qDZbLf+oh+zm+p4GYSwuFKBV2wX K05zfVpMcAO/7OD9UV+2y8pRbm5nw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvgedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggr fieshhgvrghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepteeivdelff eftddvlefhtdfhvdfgteffhedtjeelgfehkeelledvudffledtleeknecuffhomhgrihhn pehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BC8053C00A1; Thu, 27 Aug 2020 10:52:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-232-g4bdb081-fm-20200825.002-g4bdb081a Mime-Version: 1.0 Message-Id: <57b35b9f-5b9c-4184-966e-82e29cde34f4@www.fastmail.com> In-Reply-To: References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> Date: Thu, 27 Aug 2020 07:52:10 -0700 From: "Christopher Wood" To: "Eric Rescorla" , "tirumal reddy" Cc: "ADD Mailing list" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] ADD Requirements Draft 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, 27 Aug 2020 14:52:35 -0000 On Thu, Aug 27, 2020, at 6:15 AM, Eric Rescorla wrote: >=20 >=20 > On Wed, Aug 26, 2020 at 10:15 PM tirumal reddy wro= te: > > Hi Eric, > >=20 > > Please see inline > >=20 > > On Wed, 26 Aug 2020 at 16:50, Eric Rescorla wrote: > >>=20 > >>=20 > >> On Wed, Aug 26, 2020 at 3:10 AM tirumal reddy w= rote: > >>>=20 > >>>=20 > >>> On Tue, 25 Aug 2020 at 20:19, Christopher Wood wrote: > >>>> Thanks for the review! Please see inline below. > >>>>=20 > >>>> On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote: > >>>> > Document: draft-pauly-add-requirements-00.txt > >>>> >=20 > >>>> > Tommy, > >>>> >=20 > >>>> > Thanks for posting this. Two comments on the threat model, > >>>> > requirements, and what mechanisms it leaves in scope. The point= s > >>>> > below are primarily about local discovery. > >>>> >=20 > >>>> >=20 > >>>> > 1. In S 4, you say you are assuming an RFC 3552 threat model th= at > >>>> > includes on-path active attackers. However, in S 2.1 you indica= te that > >>>> > one of the benefits of this type of mechanism is to authenticat= e data > >>>> > coming from the true resolver: > >>>> >=20 > >>>> > * Verify that answers come from the selected DNS resolver > >>>> >=20 > >>>> > * Authenticate that the DNS resolver is the one provisioned= by the > >>>> > network > >>>> >=20 > >>>> > As a side note, I would observe that these benefits derive from= the > >>>> > use of an authenticated channel, not from an encrypted channel.= This > >>>> > is sort of a nit in that modern TLS profiles discourage authent= ication > >>>> > only, but I think it's still worth getting right. > >>>>=20 > >>>> Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the u= se of authenticated DoH and DoT, but I can see how that=E2=80=99s confus= ing given that we later mention opportunistic encryption (as a contrasti= ng approach). > >>>>=20 > >>>> > More importantly, this is only really true if either (1) the cl= ient > >>>> > can accurately determine the nonexistence of a secure resolver = or (2) > >>>> > the client somehow behaves meaningfully differently in cases wh= ere > >>>> > it determines that there is no secure resolver. To lay this out= in > >>>> > more detail, assuming that it's possible to determine the ident= ity > >>>> > of a secure resolver if one is present (e.g., by the kind of SP= AU > >>>> > mechanism that Chrome uses), then there are three cases: > >>>> >=20 > >>>> > 1. The client connects to a secure resolver > >>>> > 2. No authenticated resolver is present > >>>> > 3. There is an attack > >>>> >=20 > >>>> > While it's straightforward to determine whether one is in case = (1), > >>>> > many users will be in case (2) and so as long as the client tre= ats > >>>> > (1), (2), and (3) identically, then this doesn't preclude attac= k by > >>>> > on-path attackers. Thisisn't a new observation, of course, but = I think > >>>> > it points to the need to sharpen the requirements and potential= ly > >>>> > S 4.2 if they are to be useful in the face of the threat model > >>>> > you define. > >>>>=20 > >>>> That=E2=80=99s a good point to raise. If clients don=E2=80=99t tr= eat (3) and (2) differently, then the attacker can always win. And right= now, given the threat model, it=E2=80=99s unclear *if* a client can dif= ferentiate between these cases. Or to put it differently (and I think th= is was how you phrased it once in the past): the client can=E2=80=99t di= stinguish between a network with no authenticated resolver and an active= attack.=20 > >>>>=20 > >>>> Perhaps we need to relax the attacker=E2=80=99s capabilities here= ? If DoH is blocked, then, well, what is a client left to do? Section 4.= 2 punts that problem to the client=E2=80=99s policy, which seems (to me)= to be the right way to deal with this type of attack. > >>>>=20 > >>>> Perhaps it=E2=80=99s worth clarifying that one of the motivations= for these requirements (and guidance text) is to allow for incremental = improvements. For example, opportunistic encrypted DNS may be better tha= n no encryption for some clients. Although clients can=E2=80=99t determi= ne if this is an attack or not, there=E2=80=99s arguably some benefit to= it. Or put differently: the attacker may easily win for opportunistic D= NS, but there may be cases where the attacker loses, and that seems like= an improvement. > >>>>=20 > >>>> > 2. S 4 says that attackers must not be able to: > >>>> >=20 > >>>> > * Redirect DNS traffic to themselves. > >>>> >=20 > >>>> > If we try to map this onto the various proposed mechanisms, I t= hink it > >>>> > has to be softened to say something like "Redirect secure DNS t= raffic > >>>> > to themselves when DNS traffic would not be" (again a 3552 atta= cker > >>>> > can say whatever they want in DHCP). I think this then preclude= s this > >>>> > mechanism having some kind of indicator of where the secure res= olver > >>>> > is other than at its own IP. > >>>>=20 > >>>> I think that=E2=80=99s right. None of the current discovery mecha= nisms work well for local discovery when the attacker controls the netwo= rk, since none of the current signals are authenticated. > >>>=20 > >>> No, it is possible for the client to defend against an on-path att= acker spoofing/blocking encrypted=20 > >>> DNS server discovery, see https://tools.ietf.org/html/draft-btw-ad= d-home-08#section-10 > >>=20 > >> You describe three mechanisms. The first two seem to involve some s= ort of external configuration, and so are not of use in the generic case= . > >=20 > > No, only the first mechanism requires external configuration. Please= clarify why you think the three mechanisms are not generic ? >=20 > " Cryptographically assert the DNS server identity to identify the DNS= =20 > client is connecting to an encrypted DNS server hosted by a specific=20= > organization" >=20 > The client has no way of knowing what organizations are acceptable. >=20 > The reason these aren't generic is that clients in general will not be= =20 > so configured.=20 > > =20 > >>=20 > >> I do not believe the third, STUN-based mechanism works. The attacke= r can make the client believe that it has any external IP of its choice = by tunnelling the STUN traffic. > >=20 > > Yes, it may be easy for an attacker to identify STUN traffic but cha= llenging to identify TURN server running on port 443 (TURN-over-TLS).=20= >=20 > Well, it will be public information (because it's embedded in many=20 > clients) where the servers are. >=20 >=20 > > Further, an attacker may or may not be always on-path and the client= can remember that an encrypted resolver is provided by the attached net= work (e.g., associate the domain name/organization hosting the encrypted= resolver with the SSID:BSSID). If later the endpoint cannot discover th= e network-provided resolver, it can assume an attacker blocked the disco= very. >=20 > Or that network conditions changed in some way or other, which might=20= > result in unacceptable numbers of false positives.=20 > In any case, this is a weaker threat model than described in the draft= . Indeed. And it seems useful to ask whether or not this weaker threat mod= el, for local discovery, is realistic, or if we're just moving the goal = post to build a protocol that works.=20 Best, Chris From nobody Fri Aug 28 00:35:30 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 726403A0DF6 for ; Fri, 28 Aug 2020 00:35:28 -0700 (PDT) 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 mRO-0FgvqM8c for ; Fri, 28 Aug 2020 00:35:26 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 6C1CC3A0DED for ; Fri, 28 Aug 2020 00:35:26 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id h10so298193ioq.6 for ; Fri, 28 Aug 2020 00:35:26 -0700 (PDT) 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=WizQRSQUL1snjv8Jgkfb8Gv7XKL1BbmwvZMNVG5WTH8=; b=gY4zuT9z6jbOvuLtn0JriXbrNeU9VBCxHF41E4MFwtiXYLVJF0Xx3ofgYGpQXFKdvR fbQIac4vrf2sS0ZB81NczqJr6jwTaZrAjBL11F2+8dGZpxKIJF5YKQKDKTt3ykBrGwE7 2BXJOioIMoI1PS8Ue1HLpgvgTXOyIRcByhhpT+dTMc9f3VLO/GbMLM1fY3/Ztm9W78hq p83HC/B+QufFH6wIpiB1H6EZYlVfXpvPCApNMxoTuKZKTPat1shKkdVzkbhH9f05QzLs LArtwSltIeZq+QIyPhQETtwteienlYlXI3HT3U+g9ndQ/mqJoetiaVel6aU0frngihj2 cmOg== 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=WizQRSQUL1snjv8Jgkfb8Gv7XKL1BbmwvZMNVG5WTH8=; b=dGKFPzT8s89MgTh/48s634Vehy6kVOPuvTnriDvd+NcEQPl4nfPHfaB5qOjXFrJuwK DYYf8+WAec1HJ0U+P02Kt8ejDyeWvusIJRlWA4pQD49O7y9MN6xff3ZaMYAzpUuw4xFX s8aBVRNKJWR+N0oEkTh6mEUM1ZUabXQxAsSYZmR0/ZhChDZU1Ffr7A2wFZqNYBNH4tec PNreE4K8XT5CKWUl1Q/OPXOTn9emHnViLepycEj6M0J6x3Av/TbvFm/K4q3E4bcny3Tx wfvfnOXXDGzDjptNp1s5RJsU2rTQ3fyOqMV2+zxg3ghvzJ0PFa0YOwf5jks/kYXnPX3f lYSA== X-Gm-Message-State: AOAM531DGGfJWdMoy/UX+JrAtNsVHEQQ/3H3zJBlPY2gSn76eht1viiY vWgnS1WIiGyNk/uVoNX+Vbp/DbHMO/9UFdO1V34+4O4diQYMPg== X-Google-Smtp-Source: ABdhPJydJQHlJn2gnVoAAd+5bHxjtaENmd9fkRSXzJCcBzySR/l2lNxeD8J6gCCxLoDEUofUcelOnE1bxzBWbCXYAaw= X-Received: by 2002:a5e:d514:: with SMTP id e20mr283307iom.183.1598600125326; Fri, 28 Aug 2020 00:35:25 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> In-Reply-To: From: tirumal reddy Date: Fri, 28 Aug 2020 13:05:13 +0530 Message-ID: To: Eric Rescorla Cc: Christopher Wood , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000009bae5d05adeb18eb" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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: Fri, 28 Aug 2020 07:35:28 -0000 --0000000000009bae5d05adeb18eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 27 Aug 2020 at 18:46, Eric Rescorla wrote: > > > On Wed, Aug 26, 2020 at 10:15 PM tirumal reddy wrote: > >> Hi Eric, >> >> Please see inline >> >> On Wed, 26 Aug 2020 at 16:50, Eric Rescorla wrote: >> >>> >>> >>> On Wed, Aug 26, 2020 at 3:10 AM tirumal reddy wrote= : >>> >>>> >>>> >>>> On Tue, 25 Aug 2020 at 20:19, Christopher Wood >>>> wrote: >>>> >>>>> Thanks for the review! Please see inline below. >>>>> >>>>> On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote: >>>>> > Document: draft-pauly-add-requirements-00.txt >>>>> > >>>>> > Tommy, >>>>> > >>>>> > Thanks for posting this. Two comments on the threat model, >>>>> > requirements, and what mechanisms it leaves in scope. The points >>>>> > below are primarily about local discovery. >>>>> > >>>>> > >>>>> > 1. In S 4, you say you are assuming an RFC 3552 threat model that >>>>> > includes on-path active attackers. However, in S 2.1 you indicate >>>>> that >>>>> > one of the benefits of this type of mechanism is to authenticate da= ta >>>>> > coming from the true resolver: >>>>> > >>>>> > * Verify that answers come from the selected DNS resolver >>>>> > >>>>> > * Authenticate that the DNS resolver is the one provisioned by >>>>> the >>>>> > network >>>>> > >>>>> > As a side note, I would observe that these benefits derive from the >>>>> > use of an authenticated channel, not from an encrypted channel. Thi= s >>>>> > is sort of a nit in that modern TLS profiles discourage >>>>> authentication >>>>> > only, but I think it's still worth getting right. >>>>> >>>>> Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use o= f authenticated >>>>> DoH and DoT, but I can see how that=E2=80=99s confusing given that we= later mention >>>>> opportunistic encryption (as a contrasting approach). >>>>> >>>>> > More importantly, this is only really true if either (1) the client >>>>> > can accurately determine the nonexistence of a secure resolver or (= 2) >>>>> > the client somehow behaves meaningfully differently in cases where >>>>> > it determines that there is no secure resolver. To lay this out in >>>>> > more detail, assuming that it's possible to determine the identity >>>>> > of a secure resolver if one is present (e.g., by the kind of SPAU >>>>> > mechanism that Chrome uses), then there are three cases: >>>>> > >>>>> > 1. The client connects to a secure resolver >>>>> > 2. No authenticated resolver is present >>>>> > 3. There is an attack >>>>> > >>>>> > While it's straightforward to determine whether one is in case (1), >>>>> > many users will be in case (2) and so as long as the client treats >>>>> > (1), (2), and (3) identically, then this doesn't preclude attack by >>>>> > on-path attackers. Thisisn't a new observation, of course, but I >>>>> think >>>>> > it points to the need to sharpen the requirements and potentially >>>>> > S 4.2 if they are to be useful in the face of the threat model >>>>> > you define. >>>>> >>>>> That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat = (3) and (2) >>>>> differently, then the attacker can always win. And right now, given t= he >>>>> threat model, it=E2=80=99s unclear *if* a client can differentiate be= tween these >>>>> cases. Or to put it differently (and I think this was how you phrased= it >>>>> once in the past): the client can=E2=80=99t distinguish between a net= work with no >>>>> authenticated resolver and an active attack. >>>>> >>>>> Perhaps we need to relax the attacker=E2=80=99s capabilities here? If= DoH is >>>>> blocked, then, well, what is a client left to do? Section 4.2 punts t= hat >>>>> problem to the client=E2=80=99s policy, which seems (to me) to be the= right way to >>>>> deal with this type of attack. >>>>> >>>>> Perhaps it=E2=80=99s worth clarifying that one of the motivations for= these >>>>> requirements (and guidance text) is to allow for incremental improvem= ents. >>>>> For example, opportunistic encrypted DNS may be better than no encryp= tion >>>>> for some clients. Although clients can=E2=80=99t determine if this is= an attack or >>>>> not, there=E2=80=99s arguably some benefit to it. Or put differently:= the attacker >>>>> may easily win for opportunistic DNS, but there may be cases where th= e >>>>> attacker loses, and that seems like an improvement. >>>>> >>>>> > 2. S 4 says that attackers must not be able to: >>>>> > >>>>> > * Redirect DNS traffic to themselves. >>>>> > >>>>> > If we try to map this onto the various proposed mechanisms, I think >>>>> it >>>>> > has to be softened to say something like "Redirect secure DNS traff= ic >>>>> > to themselves when DNS traffic would not be" (again a 3552 attacker >>>>> > can say whatever they want in DHCP). I think this then precludes th= is >>>>> > mechanism having some kind of indicator of where the secure resolve= r >>>>> > is other than at its own IP. >>>>> >>>>> I think that=E2=80=99s right. None of the current discovery mechanism= s work >>>>> well for local discovery when the attacker controls the network, sinc= e none >>>>> of the current signals are authenticated. >>>>> >>>> >>>> No, it is possible for the client to defend against an on-path attacke= r >>>> spoofing/blocking encrypted >>>> DNS server discovery, see >>>> https://tools.ietf.org/html/draft-btw-add-home-08#section-10 >>>> >>> >>> You describe three mechanisms. The first two seem to involve some sort >>> of external configuration, and so are not of use in the generic case. >>> >> >> No, only the first mechanism requires external configuration. Please >> clarify why you think the three mechanisms are not generic ? >> > > " Cryptographically assert the DNS server identity to identify the DNS > client is connecting to an encrypted DNS server hosted by a specific > organization" > > The client has no way of knowing what organizations are acceptable. > > The reason these aren't generic is that clients in general will not be so > configured. > I see the confusion, and will fix the text. The intent is to say the cryptographic assertion of the DNS server identity proves to the client the encrypted server is hosted by a legal organization/entity. It prevents the attack scenario where an attacker hosts an encrypted server and claims the best DNS privacy preservation policy. The client can then prompt the user to decide whether the encrypted DNS server hosted by a specific organization is acceptable or not. The resolver information published by the DNS server also includes a privacy statement URL, optional audit URL, whether the DNS server performs filtering and reasons for filtering. > >> >>> >>> I do not believe the third, STUN-based mechanism works. The attacker ca= n >>> make the client believe that it has any external IP of its choice by >>> tunnelling the STUN traffic. >>> >> >> Yes, it may be easy for an attacker to identify STUN traffic but >> challenging to identify TURN server running on port 443 (TURN-over-TLS). >> > > Well, it will be public information (because it's embedded in many > clients) where the servers are. > Yes, good point. If many services are hosted on the same IP address, it will be challenging to identify the TURN-over-TLS/STUN-over-TLS session. > > > Further, an attacker may or may not be always on-path and the client can >> remember that an encrypted resolver is provided by the attached network >> (e.g., associate the domain name/organization hosting the encrypted >> resolver with the SSID:BSSID). If later the endpoint cannot discover the >> network-provided resolver, it can assume an attacker blocked the discove= ry. >> > > Or that network conditions changed in some way or other, which might > result in unacceptable numbers of false positives. > In any case, this is a weaker threat model than described in the draft. > Agreed, if the client cannot take an action at least it can notify the user that it cannot discover the previously seen network-provided encrypted resolver. -Tiru > > -Ekr > > >> -Tiru >> >> >>> >>> -Ekr >>> >>> >>>> -Tiru >>>> >>>> >>>>> >>>>> Best, >>>>> Chris >>>>> >>>>> -- >>>>> 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 >>>> >>> --0000000000009bae5d05adeb18eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 27 Aug 2020 at 18:46, Eric Rescor= la <ekr@rtfm.com> wrote:


On Wed, Aug 26, 2020 at 10:15 PM t= irumal reddy <kon= dtir@gmail.com> wrote:
Hi Eric,

Pleas= e see inline

On Wed, 26 Aug 2020 at 16= :50, Eric Rescorla <ek= r@rtfm.com> wrote:

=

= On Wed, Aug 26, 2020 at 3:10 AM tirumal reddy <kondtir@gmail.com> wrote:


On Tue, 25 Aug 2020 at 20:19, Christopher Wood <caw@heapingbits.net> wrot= e:
Thanks for th= e review! Please see inline below.

On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote:
> Document: draft-pauly-add-requirements-00.txt
>
> Tommy,
>
> Thanks for posting this. Two comments on the threat model,
> requirements, and what mechanisms it leaves in scope. The points
> below are primarily about local discovery.
>
>
> 1. In S 4, you say you are assuming an RFC 3552 threat model that
> includes on-path active attackers. However, in S 2.1 you indicate that=
> one of the benefits of this type of mechanism is to authenticate data<= br> > coming from the true resolver:
>
>=C2=A0 =C2=A0 *=C2=A0 Verify that answers come from the selected DNS re= solver
>
>=C2=A0 =C2=A0 *=C2=A0 Authenticate that the DNS resolver is the one pro= visioned by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0network
>
> As a side note, I would observe that these benefits derive from the > use of an authenticated channel, not from an encrypted channel. This > is sort of a nit in that modern TLS profiles discourage authentication=
> only, but I think it's still worth getting right.

Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use of auth= enticated DoH and DoT, but I can see how that=E2=80=99s confusing given tha= t we later mention opportunistic encryption (as a contrasting approach).
> More importantly, this is only really true if either (1) the client > can accurately determine the nonexistence of a secure resolver or (2)<= br> > the client somehow behaves meaningfully differently in cases where
> it determines that there is no secure resolver. To lay this out in
> more detail, assuming that it's possible to determine the identity=
> of a secure resolver if one is present (e.g., by the kind of SPAU
> mechanism that Chrome uses), then there are three cases:
>
> 1. The client connects to a secure resolver
> 2. No authenticated resolver is present
> 3. There is an attack
>
> While it's straightforward to determine whether one is in case (1)= ,
> many users will be in case (2) and so as long as the client treats
> (1), (2), and (3) identically, then this doesn't preclude attack b= y
> on-path attackers. Thisisn't a new observation, of course, but I t= hink
> it points to the need to sharpen the requirements and potentially
> S 4.2 if they are to be useful in the face of the threat model
> you define.

That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3) an= d (2) differently, then the attacker can always win. And right now, given t= he threat model, it=E2=80=99s unclear *if* a client can differentiate betwe= en these cases. Or to put it differently (and I think this was how you phra= sed it once in the past): the client can=E2=80=99t distinguish between a ne= twork with no authenticated resolver and an active attack.

Perhaps we need to relax the attacker=E2=80=99s capabilities here? If DoH i= s blocked, then, well, what is a client left to do? Section 4.2 punts that = problem to the client=E2=80=99s policy, which seems (to me) to be the right= way to deal with this type of attack.

Perhaps it=E2=80=99s worth clarifying that one of the motivations for these= requirements (and guidance text) is to allow for incremental improvements.= For example, opportunistic encrypted DNS may be better than no encryption = for some clients. Although clients can=E2=80=99t determine if this is an at= tack or not, there=E2=80=99s arguably some benefit to it. Or put differentl= y: the attacker may easily win for opportunistic DNS, but there may be case= s where the attacker loses, and that seems like an improvement.

> 2. S 4 says that attackers must not be able to:
>
>=C2=A0 =C2=A0 *=C2=A0 Redirect DNS traffic to themselves.
>
> If we try to map this onto the various proposed mechanisms, I think it=
> has to be softened to say something like "Redirect secure DNS tra= ffic
> to themselves when DNS traffic would not be" (again a 3552 attack= er
> can say whatever they want in DHCP). I think this then precludes this<= br> > mechanism having some kind of indicator of where the secure resolver > is other than at its own IP.

I think that=E2=80=99s right. None of the current discovery mechanisms work= well for local discovery when the attacker controls the network, since non= e of the current signals are authenticated.

=
No, it is possible for the client to defend against an on-path attacke= r spoofing/blocking encrypted=C2=A0

You describe thr= ee mechanisms. The first two seem to involve some sort of external configur= ation, and so are not of use in the generic case.

No, only the first mechanism requires external con= figuration. Please clarify why you think the three mechanisms are not gener= ic ?

" Cryptographic= ally assert the DNS server identity to identify the DNS client is conn= ecting to an encrypted DNS server hosted by a specific organization&qu= ot;

The client has no way of knowing what organiza= tions are acceptable.

The reason these aren't = generic is that clients in general will not be so configured.

I see the confusion, and will fix= the text. The intent is to say the cryptographic assertion of the DNS serv= er identity
proves to the client the encrypted server is hosted b= y a legal organization/entity.=C2=A0It prevents the attack scenario where= =C2=A0
an attacker hosts an encrypted server and claims the best = DNS privacy preservation policy.

The client can th= en prompt the user to decide whether the encrypted DNS server hosted by a s= pecific organization is=C2=A0
acceptable or not. The resolver inf= ormation published by the DNS server also includes a privacy statement URL,= optional audit URL,=C2=A0
whether the DNS server performs filter= ing and reasons for filtering.
=C2=A0
=
=C2=A0

I do not believe the third, STUN-based mechanism w= orks. The attacker can make the client believe that it has any external IP = of its choice by tunnelling the STUN traffic.

Yes, it may be easy for an attacker to identify STUN t= raffic but challenging to identify TURN server running on port 443 (TURN-ov= er-TLS).=C2=A0

Well, it w= ill be public information (because it's embedded in many clients) where= the servers are.

Yes= , good point. If many services are hosted on the same IP address, it will b= e challenging to identify the=C2=A0
TURN-over-TLS/STUN-over-TLS s= ession.
=C2=A0

=

Further, an attacker may or may no= t be always on-path and the client can remember=C2=A0that an encrypted resolver is provided by the attached network (e.g., associate the domain name/organizat= ion hosting the encrypted resolver with the SSID:BSSID). If later the endpo= int cannot discover the network-provided resolver, it can assume an attacker blocked the discovery.

Or that network conditions changed in some way = or other, which might result in unacceptable numbers of false positives.
In any case, this is a weaker threat model than described in t= he draft.

Agreed, if = the client cannot take an action at least it can notify the user that it ca= nnot discover the previously seen=C2=A0
network-provided encrypte= d resolver.=C2=A0

-Tiru
=C2=A0

-Ekr


-Tiru
=C2=A0

-Ekr


-Tiru
=C2=A0

Best,
Chris

--
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
--0000000000009bae5d05adeb18eb-- From nobody Fri Aug 28 06:38: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 6BD533A0522 for ; Fri, 28 Aug 2020 06:38:57 -0700 (PDT) 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 serIHp2lTfA0 for ; Fri, 28 Aug 2020 06:38:53 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 A213C3A0486 for ; Fri, 28 Aug 2020 06:38:52 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id j15so730084lfg.7 for ; Fri, 28 Aug 2020 06:38:52 -0700 (PDT) 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=zVjkCEAs2eVbnFdZk4dxBpvMagd5fgdhFFq5yRYA5r4=; b=VWSsLgxXXrzU/J/fQI/zypXTzfL2dK74YuXI0ur8385V7d8BQkGE+7xY4MBnPkhx/k ynoC9O/WBfwa09holB651pYhx0uKmFaHdNr5sdORvKqpFhCvAY+Ib1VCqJ+7mMgfGExQ EZsXaQjEUhug0/982Joq65CWzFow2V0JBqHniXPzBdYLq0I32LKtxw8AopU4m/N9G5KO fz0mCbhkGXffpla7mCEYmcqLIbjakLa6SycABFruEYoAI3g66y6hP2Dk9tuxg8RFKF0X VzF4rAI3K9K688Gw1fxqMHyCx2Q8wLRtQb6bWg315GLNhTY4+tszQWPs01VLICiHUtmv 0kiQ== 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=zVjkCEAs2eVbnFdZk4dxBpvMagd5fgdhFFq5yRYA5r4=; b=I0aYXQ3zLzEG8JSxWAp1HsBmF40ULZaii6Y3gjcogISm0fcHatYN6dUw2ATbRSVN7n pZZcKrilp95hhjzdYDphCZKs79VYdpzx/1htod24q+WU4U7JnHpcUT5gRx15JYfXbsXW aBbuwkgwbJILCaX578vNtUueLOp0EzWR9GTMjoVc96nInL0pq/DJ7QHEyNzHGyuwKEBN rEEuGLy6oBrVPwxRjMxeDrrZk4RysnbJiuyK7ocMgtxpZaxsrOF5ox5FfhVLYeybNLZ3 pqgcUZTtXhyiB+7Yex8Q6sZP5u8luZjJ/gxUAzlbi+e+16Lo3pEv550ts0wmBA4lI3EB Uosw== X-Gm-Message-State: AOAM532zz7K/6y6vChRa5Sez7q1n57n169YSwE50H4GLcSJxWl+T+slC sIcllY/zAt6bhk71bG93X0f/FG8TgidnePBrxMicOhKzMKGw9g== X-Google-Smtp-Source: ABdhPJwFFoAfr9hwjYOPQs1l34uAd1+WzEra62ExEG+xTSFquJAb6Jl9ryZQ4aUwhnOp47cQAY+Z5mKid653QayOSr8= X-Received: by 2002:ac2:5e8a:: with SMTP id b10mr842703lfq.14.1598621930654; Fri, 28 Aug 2020 06:38:50 -0700 (PDT) MIME-Version: 1.0 References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Fri, 28 Aug 2020 06:38:14 -0700 Message-ID: To: tirumal reddy Cc: Christopher Wood , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000004ea47805adf02c99" Archived-At: Subject: Re: [Add] ADD Requirements Draft 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: Fri, 28 Aug 2020 13:38:57 -0000 --0000000000004ea47805adf02c99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 28, 2020 at 12:35 AM tirumal reddy wrote: > On Thu, 27 Aug 2020 at 18:46, Eric Rescorla wrote: > >> >> >> On Wed, Aug 26, 2020 at 10:15 PM tirumal reddy wrote= : >> >>> Hi Eric, >>> >>> Please see inline >>> >>> On Wed, 26 Aug 2020 at 16:50, Eric Rescorla wrote: >>> >>>> >>>> >>>> On Wed, Aug 26, 2020 at 3:10 AM tirumal reddy >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, 25 Aug 2020 at 20:19, Christopher Wood >>>>> wrote: >>>>> >>>>>> Thanks for the review! Please see inline below. >>>>>> >>>>>> On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote: >>>>>> > Document: draft-pauly-add-requirements-00.txt >>>>>> > >>>>>> > Tommy, >>>>>> > >>>>>> > Thanks for posting this. Two comments on the threat model, >>>>>> > requirements, and what mechanisms it leaves in scope. The points >>>>>> > below are primarily about local discovery. >>>>>> > >>>>>> > >>>>>> > 1. In S 4, you say you are assuming an RFC 3552 threat model that >>>>>> > includes on-path active attackers. However, in S 2.1 you indicate >>>>>> that >>>>>> > one of the benefits of this type of mechanism is to authenticate >>>>>> data >>>>>> > coming from the true resolver: >>>>>> > >>>>>> > * Verify that answers come from the selected DNS resolver >>>>>> > >>>>>> > * Authenticate that the DNS resolver is the one provisioned by >>>>>> the >>>>>> > network >>>>>> > >>>>>> > As a side note, I would observe that these benefits derive from th= e >>>>>> > use of an authenticated channel, not from an encrypted channel. Th= is >>>>>> > is sort of a nit in that modern TLS profiles discourage >>>>>> authentication >>>>>> > only, but I think it's still worth getting right. >>>>>> >>>>>> Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use = of authenticated >>>>>> DoH and DoT, but I can see how that=E2=80=99s confusing given that w= e later mention >>>>>> opportunistic encryption (as a contrasting approach). >>>>>> >>>>>> > More importantly, this is only really true if either (1) the clien= t >>>>>> > can accurately determine the nonexistence of a secure resolver or >>>>>> (2) >>>>>> > the client somehow behaves meaningfully differently in cases where >>>>>> > it determines that there is no secure resolver. To lay this out in >>>>>> > more detail, assuming that it's possible to determine the identity >>>>>> > of a secure resolver if one is present (e.g., by the kind of SPAU >>>>>> > mechanism that Chrome uses), then there are three cases: >>>>>> > >>>>>> > 1. The client connects to a secure resolver >>>>>> > 2. No authenticated resolver is present >>>>>> > 3. There is an attack >>>>>> > >>>>>> > While it's straightforward to determine whether one is in case (1)= , >>>>>> > many users will be in case (2) and so as long as the client treats >>>>>> > (1), (2), and (3) identically, then this doesn't preclude attack b= y >>>>>> > on-path attackers. Thisisn't a new observation, of course, but I >>>>>> think >>>>>> > it points to the need to sharpen the requirements and potentially >>>>>> > S 4.2 if they are to be useful in the face of the threat model >>>>>> > you define. >>>>>> >>>>>> That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat= (3) and (2) >>>>>> differently, then the attacker can always win. And right now, given = the >>>>>> threat model, it=E2=80=99s unclear *if* a client can differentiate b= etween these >>>>>> cases. Or to put it differently (and I think this was how you phrase= d it >>>>>> once in the past): the client can=E2=80=99t distinguish between a ne= twork with no >>>>>> authenticated resolver and an active attack. >>>>>> >>>>>> Perhaps we need to relax the attacker=E2=80=99s capabilities here? I= f DoH is >>>>>> blocked, then, well, what is a client left to do? Section 4.2 punts = that >>>>>> problem to the client=E2=80=99s policy, which seems (to me) to be th= e right way to >>>>>> deal with this type of attack. >>>>>> >>>>>> Perhaps it=E2=80=99s worth clarifying that one of the motivations fo= r these >>>>>> requirements (and guidance text) is to allow for incremental improve= ments. >>>>>> For example, opportunistic encrypted DNS may be better than no encry= ption >>>>>> for some clients. Although clients can=E2=80=99t determine if this i= s an attack or >>>>>> not, there=E2=80=99s arguably some benefit to it. Or put differently= : the attacker >>>>>> may easily win for opportunistic DNS, but there may be cases where t= he >>>>>> attacker loses, and that seems like an improvement. >>>>>> >>>>>> > 2. S 4 says that attackers must not be able to: >>>>>> > >>>>>> > * Redirect DNS traffic to themselves. >>>>>> > >>>>>> > If we try to map this onto the various proposed mechanisms, I thin= k >>>>>> it >>>>>> > has to be softened to say something like "Redirect secure DNS >>>>>> traffic >>>>>> > to themselves when DNS traffic would not be" (again a 3552 attacke= r >>>>>> > can say whatever they want in DHCP). I think this then precludes >>>>>> this >>>>>> > mechanism having some kind of indicator of where the secure resolv= er >>>>>> > is other than at its own IP. >>>>>> >>>>>> I think that=E2=80=99s right. None of the current discovery mechanis= ms work >>>>>> well for local discovery when the attacker controls the network, sin= ce none >>>>>> of the current signals are authenticated. >>>>>> >>>>> >>>>> No, it is possible for the client to defend against an on-path >>>>> attacker spoofing/blocking encrypted >>>>> DNS server discovery, see >>>>> https://tools.ietf.org/html/draft-btw-add-home-08#section-10 >>>>> >>>> >>>> You describe three mechanisms. The first two seem to involve some sort >>>> of external configuration, and so are not of use in the generic case. >>>> >>> >>> No, only the first mechanism requires external configuration. Please >>> clarify why you think the three mechanisms are not generic ? >>> >> >> " Cryptographically assert the DNS server identity to identify the DNS >> client is connecting to an encrypted DNS server hosted by a specific >> organization" >> >> The client has no way of knowing what organizations are acceptable. >> >> The reason these aren't generic is that clients in general will not be s= o >> configured. >> > > I see the confusion, and will fix the text. The intent is to say the > cryptographic assertion of the DNS server identity > proves to the client the encrypted server is hosted by a legal > organization/entity. It prevents the attack scenario where > an attacker hosts an encrypted server and claims the best DNS privacy > preservation policy. > > The client can then prompt the user to decide whether the encrypted DNS > server hosted by a specific organization is > acceptable or not. The resolver information published by the DNS server > also includes a privacy statement URL, optional audit URL, > whether the DNS server performs filtering and reasons for filtering. > As I said when you first proposed this in an ADD meeting, I do not believe that anything of this kind is viable. 1. Certificates tied to a legal entity have not been effective, which is why browsers are removing EV. 2. There is ample evidence that users do not read privacy policies. > >> >> >>> >>>> I do not believe the third, STUN-based mechanism works. The attacker >>>> can make the client believe that it has any external IP of its choice = by >>>> tunnelling the STUN traffic. >>>> >>> >>> Yes, it may be easy for an attacker to identify STUN traffic but >>> challenging to identify TURN server running on port 443 (TURN-over-TLS)= . >>> >> >> Well, it will be public information (because it's embedded in many >> clients) where the servers are. >> > > Yes, good point. If many services are hosted on the same IP address, it > will be challenging to identify the > TURN-over-TLS/STUN-over-TLS session. > They will also have a different ALPN value. > >> >> >> Further, an attacker may or may not be always on-path and the client can >>> remember that an encrypted resolver is provided by the attached network >>> (e.g., associate the domain name/organization hosting the encrypted >>> resolver with the SSID:BSSID). If later the endpoint cannot discover th= e >>> network-provided resolver, it can assume an attacker blocked the discov= ery. >>> >> >> Or that network conditions changed in some way or other, which might >> result in unacceptable numbers of false positives. >> In any case, this is a weaker threat model than described in the draft. >> > > Agreed, if the client cannot take an action at least it can notify the > user that it cannot discover the previously seen > network-provided encrypted resolver. > A dialog which the user will see a lot and therefore likely click through. -Ekr > -Tiru > > >> >> -Ekr >> >> >>> -Tiru >>> >>> >>>> >>>> -Ekr >>>> >>>> >>>>> -Tiru >>>>> >>>>> >>>>>> >>>>>> Best, >>>>>> Chris >>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>> --0000000000004ea47805adf02c99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 28, 2020 at 12:35 AM tiru= mal reddy <kondtir@gmail.com>= ; wrote:
On Thu, 27 Aug 2020 at 18:46, Eric Rescorla <= ekr@rtfm.com> wrot= e:


On Wed, Aug 26, 2020 at= 10:15 PM tirumal reddy <kondtir@gmail.com> wrote:
Hi Eric,

Please see inline

On Wed, 26 Aug= 2020 at 16:50, Eric Rescorla <ekr@rtfm.com> wrote:


On Wed, Aug 26, 2020 at 3:10 AM tirumal reddy <kondtir@gmail.com> wrote:=


On Tue, 25 Aug 2020 at 20:19, Christopher Wood <<= a href=3D"mailto:caw@heapingbits.net" target=3D"_blank">caw@heapingbits.net= > wrote:
= Thanks for the review! Please see inline below.

On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote:
> Document: draft-pauly-add-requirements-00.txt
>
> Tommy,
>
> Thanks for posting this. Two comments on the threat model,
> requirements, and what mechanisms it leaves in scope. The points
> below are primarily about local discovery.
>
>
> 1. In S 4, you say you are assuming an RFC 3552 threat model that
> includes on-path active attackers. However, in S 2.1 you indicate that=
> one of the benefits of this type of mechanism is to authenticate data<= br> > coming from the true resolver:
>
>=C2=A0 =C2=A0 *=C2=A0 Verify that answers come from the selected DNS re= solver
>
>=C2=A0 =C2=A0 *=C2=A0 Authenticate that the DNS resolver is the one pro= visioned by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0network
>
> As a side note, I would observe that these benefits derive from the > use of an authenticated channel, not from an encrypted channel. This > is sort of a nit in that modern TLS profiles discourage authentication=
> only, but I think it's still worth getting right.

Agreed. Use of =E2=80=9Cencrypted=E2=80=9D was referring to the use of auth= enticated DoH and DoT, but I can see how that=E2=80=99s confusing given tha= t we later mention opportunistic encryption (as a contrasting approach).
> More importantly, this is only really true if either (1) the client > can accurately determine the nonexistence of a secure resolver or (2)<= br> > the client somehow behaves meaningfully differently in cases where
> it determines that there is no secure resolver. To lay this out in
> more detail, assuming that it's possible to determine the identity=
> of a secure resolver if one is present (e.g., by the kind of SPAU
> mechanism that Chrome uses), then there are three cases:
>
> 1. The client connects to a secure resolver
> 2. No authenticated resolver is present
> 3. There is an attack
>
> While it's straightforward to determine whether one is in case (1)= ,
> many users will be in case (2) and so as long as the client treats
> (1), (2), and (3) identically, then this doesn't preclude attack b= y
> on-path attackers. Thisisn't a new observation, of course, but I t= hink
> it points to the need to sharpen the requirements and potentially
> S 4.2 if they are to be useful in the face of the threat model
> you define.

That=E2=80=99s a good point to raise. If clients don=E2=80=99t treat (3) an= d (2) differently, then the attacker can always win. And right now, given t= he threat model, it=E2=80=99s unclear *if* a client can differentiate betwe= en these cases. Or to put it differently (and I think this was how you phra= sed it once in the past): the client can=E2=80=99t distinguish between a ne= twork with no authenticated resolver and an active attack.

Perhaps we need to relax the attacker=E2=80=99s capabilities here? If DoH i= s blocked, then, well, what is a client left to do? Section 4.2 punts that = problem to the client=E2=80=99s policy, which seems (to me) to be the right= way to deal with this type of attack.

Perhaps it=E2=80=99s worth clarifying that one of the motivations for these= requirements (and guidance text) is to allow for incremental improvements.= For example, opportunistic encrypted DNS may be better than no encryption = for some clients. Although clients can=E2=80=99t determine if this is an at= tack or not, there=E2=80=99s arguably some benefit to it. Or put differentl= y: the attacker may easily win for opportunistic DNS, but there may be case= s where the attacker loses, and that seems like an improvement.

> 2. S 4 says that attackers must not be able to:
>
>=C2=A0 =C2=A0 *=C2=A0 Redirect DNS traffic to themselves.
>
> If we try to map this onto the various proposed mechanisms, I think it=
> has to be softened to say something like "Redirect secure DNS tra= ffic
> to themselves when DNS traffic would not be" (again a 3552 attack= er
> can say whatever they want in DHCP). I think this then precludes this<= br> > mechanism having some kind of indicator of where the secure resolver > is other than at its own IP.

I think that=E2=80=99s right. None of the current discovery mechanisms work= well for local discovery when the attacker controls the network, since non= e of the current signals are authenticated.

=
No, it is possible for the client to defend against an on-path attacke= r spoofing/blocking encrypted=C2=A0

You describe thr= ee mechanisms. The first two seem to involve some sort of external configur= ation, and so are not of use in the generic case.

No, only the first mechanism requires external con= figuration. Please clarify why you think the three mechanisms are not gener= ic ?

" Cryptographic= ally assert the DNS server identity to identify the DNS client is conn= ecting to an encrypted DNS server hosted by a specific organization&qu= ot;

The client has no way of knowing what organiza= tions are acceptable.

The reason these aren't = generic is that clients in general will not be so configured.

I see the confusion, and will fix= the text. The intent is to say the cryptographic assertion of the DNS serv= er identity
proves to the client the encrypted server is hosted b= y a legal organization/entity.=C2=A0It prevents the attack scenario where= =C2=A0
an attacker hosts an encrypted server and claims the best = DNS privacy preservation policy.

The client can th= en prompt the user to decide whether the encrypted DNS server hosted by a s= pecific organization is=C2=A0
acceptable or not. The resolver inf= ormation published by the DNS server also includes a privacy statement URL,= optional audit URL,=C2=A0
whether the DNS server performs filter= ing and reasons for filtering.

As I said when you first proposed this in an ADD meeting, I do not be= lieve that anything of this kind is viable.

1. Cer= tificates tied to a legal entity have not been effective, which is why brow= sers are removing EV.
2. There is ample evidence that users do no= t read privacy policies.

=C2=A0=
=C2=A0

I do not believe the third, STU= N-based mechanism works. The attacker can make the client believe that it h= as any external IP of its choice by tunnelling the STUN traffic.

Yes, it may be easy for an attacker= to identify STUN traffic but challenging to identify TURN server running o= n port 443 (TURN-over-TLS).=C2=A0

Well, it will be public information (because it's embedded in = many clients) where the servers are.

Yes, good point. If many services are hosted on the same IP= address, it will be challenging to identify the=C2=A0
TURN-over-= TLS/STUN-over-TLS session.

They will also have a different ALPN value.

=C2=A0


Further, an attacker may or may not be= always on-path and the client can remember=C2=A0that an encrypted resolver is provided by the attached network (e.g., associate the domain name/organizat= ion hosting the encrypted resolver with the SSID:BSSID). If later the endpo= int cannot discover the network-provided resolver, it can assume an attacker blocked the discovery.

Or that network conditions changed in some way = or other, which might result in unacceptable numbers of false positives.
In any case, this is a weaker threat model than described in t= he draft.

Agreed, if = the client cannot take an action at least it can notify the user that it ca= nnot discover the previously seen=C2=A0
network-provided encrypte= d resolver.=C2=A0

A dialo= g which the user will see a lot and therefore likely click through.

-Ekr


-Tiru
=C2=A0

=
-Ekr


-Tiru<= br>
=C2=A0

-Ekr
=


-Tiru
=C2= =A0

Best,
Chris

--
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
--0000000000004ea47805adf02c99--