From nobody Sun Nov 1 14:13:39 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE6C1B2EFD for ; Sun, 1 Nov 2015 14:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 3ZvT9dbYnc64 for ; Sun, 1 Nov 2015 14:13:30 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 F3D641B2EF7 for ; Sun, 1 Nov 2015 14:13:29 -0800 (PST) Received: by wikq8 with SMTP id q8so40568664wik.1 for ; Sun, 01 Nov 2015 14:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aMCGRVIt15nu6A8U/j+99YqFN4aUXfv18jKgrF9jqes=; b=nFyTS9b9TY4hkoMzutDEh9htb8drsiCA4IWBqFefKtg74P8gVmxvYjqdqf7M61NI+8 t6R+M28xHuPwAK/6JeTBMsKI1LAyIuE05wtZBB+DzFS2C/dt1dKEvHn0MSGm4EZtFdKT MoLqV63RaW9emHO9pjobly2pvoQ231FKYOPZxX7mVQUNuOSVtC+O0KOnjVeqSHp+l9Av jC3Larg+z0FAKa+UpOH/v8ic6LKYvrWyCbOP2nQaCCFxe61xW6CjfTZ6SKMxe7UwZHU/ hFXdfZyINeZuzFJPuvz6lPKI349lXwkxLGRV+1loaxfLja3WU6LiBmicP+qzCjCtd4CP /+6w== MIME-Version: 1.0 X-Received: by 10.194.60.179 with SMTP id i19mr19775411wjr.135.1446416008546; Sun, 01 Nov 2015 14:13:28 -0800 (PST) Received: by 10.27.175.104 with HTTP; Sun, 1 Nov 2015 14:13:28 -0800 (PST) Date: Mon, 2 Nov 2015 07:13:28 +0900 Message-ID: From: "Murray S. Kucherawy" To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=047d7ba973ce630df7052381f8cd Archived-At: Subject: [dbound] IETF 94 agenda posted X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 22:13:34 -0000 --047d7ba973ce630df7052381f8cd Content-Type: text/plain; charset=UTF-8 Colleagues, Pete and I have had difficulty syncing up in recent weeks which led to delays in deciding on an agenda. So, with apologies to you all for its tardiness, the agenda for our IETF 94 meeting has been posted: https://datatracker.ietf.org/meeting/94/agenda/dbound/ We will say this at the meeting but also wanted to say it early as well for those who will be remote: We are concerned that the working group is still in a phase of discussing the problem definition. This is our second in-person meeting and we still have no concrete milestones, and there hasn't been sufficient progress since Honolulu in July to get us there. We would like to come away from Tuesday's session with some deliverables to which the working group is prepared to commit. Failing that, we won't be requesting any further in-person meetings (they are expensive and space is in high demand) until committed milestones have been established. The list will of course remain active for the purpose of sorting that out. -MSK, DBOUND co-chair --047d7ba973ce630df7052381f8cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

Pete and I have ha= d difficulty syncing up in recent weeks which led to delays in deciding on = an agenda.=C2=A0 So, with apologies to you all for its tardiness, the agend= a for our IETF 94 meeting has been posted:

https://datatracker.ietf.org/meet= ing/94/agenda/dbound/

We will say this at the m= eeting but also wanted to say it early as well for those who will be remote= :

We are concerned that the working group is still in a phase of dis= cussing the problem definition.=C2=A0 This is our second in-person meeting = and we still have no concrete milestones, and there hasn't been suffici= ent progress since Honolulu in July to get us there.

We would like t= o come away from Tuesday's session with some deliverables to which the = working group is prepared to commit.=C2=A0 Failing that, we won't be re= questing any further in-person meetings (they are expensive and space is in= high demand) until committed milestones have been established.=C2=A0 The l= ist will of course remain active for the purpose of sorting that out.
-MSK, DBOUND co-chair


--047d7ba973ce630df7052381f8cd-- From nobody Sun Nov 1 22:56:08 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCF71A01E2 for ; Sun, 1 Nov 2015 22:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 clSLWvfw-1K1 for ; Sun, 1 Nov 2015 22:56:05 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEFB1A0196 for ; Sun, 1 Nov 2015 22:56:05 -0800 (PST) Received: (qmail 24566 invoked from network); 2 Nov 2015 06:56:04 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Nov 2015 06:56:04 -0000 Date: 2 Nov 2015 06:55:41 -0000 Message-ID: <20151102065541.44322.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 06:56:06 -0000 >We are concerned that the working group is still in a phase of discussing >the problem definition. Here are three problems: * the browser cookie problem * the CA name/wildcard problem * the DMARC organizational domain problem Here are three axes to characterize technical approaches 1) DNS vs. non-DNS a) single boundary in a name vs. multiple I) self publishing vs. third party For example, the existing PSL is non-DNS, multiple boundary, third party. This is not every possible problem and every possible axis, but I think it's a large enough set that if we came up with an approach that addressed all three problems, and we generally agreed that the point on the axes meets people's practical needs, we could declare success. If we came up with an approach per problem we might declare success depending on how confident we were that the points on the axes were the ones that people need. R's, John From nobody Mon Nov 2 01:17:24 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706811B355B for ; Mon, 2 Nov 2015 01:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 wSXX_5j-55FQ for ; Mon, 2 Nov 2015 01:17:20 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 125161B3574 for ; Mon, 2 Nov 2015 01:17:20 -0800 (PST) Received: by lbbec13 with SMTP id ec13so84548115lbb.0 for ; Mon, 02 Nov 2015 01:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jothan_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LNGEeY+GWFkTTJ3umuET4n1GaXOlEnnb2NU2cPZ19xA=; b=hnkDVLcmOYtB9C76ZDBCBcLy74ksISvVgAXHcQ52FixiS/ZyL+taPKQDiIj7WdwXPE VhX3xQtfGQpTRi7hAkfyJSQXnuLUikBagKyCR3G9RW6zFIuz9nYqVtxN3BdNqq7uWT06 E95ZLoFWsCeENNovcctQCRarKuijxhoInl2t59hx9iIb2KrBWde3mOv42C028x9OfMKb UmwtSYPy/mpgYFDUH4FmD/CW3hydnqeH9UTLYjEeAr0uR+ZIZcH8bB4nbfLGuLoMi5bg lF7o/7SZxPP4J2oTOQ4K4LiciFvMX6jmDTpMZRQmRZnzvNkmOZccsmjGERAb2erdwgLV XlKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LNGEeY+GWFkTTJ3umuET4n1GaXOlEnnb2NU2cPZ19xA=; b=J0kfgTAtIHHcE+Jbi1+nsVldgz5E7BrhUD6Pt8f5xagJR126TQFHTpUshhTIVkGWVY igVC+x+eRZmX+IY+qyR9avKhMzvaMb8v6wfOeHRZt5woLcmLxiX2pnTGIGAbR7BIQy20 FHuc0AVUI87FoSHzRUA3baynWIRe2x7b7sqW4B2V9arZUs4NBHpprjTf8/+QWugdZpJZ CyN1GbG3x6nAYcgzhHOkDTHFVW9d91vNbhIjW9Hhn1aLeEqUZtKOQfnfXDY6g1vPp09g kY7EoD6XPpWWPmGXZ4zyLnhMNs1qfySAFjl9B00/A+PmR9e+CIQz2/ZyOO9ubvSAM1KE o52Q== X-Gm-Message-State: ALoCoQkn5XubmIZETDBagpx4ypa3e+eooDcfRb5yxgt/YgqACskG1Najr5A7zx2NFlRH96bAEhhr MIME-Version: 1.0 X-Received: by 10.112.147.232 with SMTP id tn8mr9317048lbb.84.1446455838201; Mon, 02 Nov 2015 01:17:18 -0800 (PST) Received: by 10.25.140.3 with HTTP; Mon, 2 Nov 2015 01:17:18 -0800 (PST) In-Reply-To: <20151102065541.44322.qmail@ary.lan> References: <20151102065541.44322.qmail@ary.lan> Date: Mon, 2 Nov 2015 10:17:18 +0100 Message-ID: From: Jothan Frakes To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a83de6b7b9e05238b3ecc Archived-At: Cc: John Levine , "superuser@gmail.com" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 09:17:22 -0000 --047d7b3a83de6b7b9e05238b3ecc Content-Type: text/plain; charset=UTF-8 On Monday, November 2, 2015, John Levine wrote: > > Here are three axes to characterize technical approaches > > 1) DNS vs. non-DNS > a) single boundary in a name vs. multiple > I) self publishing vs. third party > > On the third of these, thinking root-down, where there is an authority chain from a parent entity (in Delegation) to child, I am pondering is "self-publishing vs third party" stretches to fit the status quo if there is a concept of authoritative chain. What I mean is that within the concept of "trust", if one were to pick between "self published" and "third party", which would be more trusted? Would the parent zone in DNS be "third party", for example? The IANA public suffix list (which gets generated from the root zone) is a "third party" list as it would relate to most everything with (perhaps excluding .int or .arpa to be pedantic). -- Jothan Frakes Tel: +1.206-355-0230 --047d7b3a83de6b7b9e05238b3ecc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, November 2, 2015, John Levine <johnl@taugh.com> wrote:

Here are three axes to characterize technical approaches

1) DNS vs. non-DNS
a) single boundary in a name vs. multiple
I) self publishing vs. third party


On the third of these, thinking root-down,= where there is an authority chain from a parent entity (in Delegation) to = child, I am pondering is "self-publishing vs third party"=C2=A0st= retches to fit the status quo if there is a concept of authoritative chain.=

What I mean is that within the concept=C2=A0of &q= uot;trust", if one were to pick between "self published" and= "third party", which would be more trusted? =C2=A0
Would the parent zone in DNS be "third party", for example= ?

The IANA public suffix list (which gets generated from= the root zone) is a "third party" list as it would relate to mos= t everything with (perhaps excluding .int or .arpa to be pedantic).






--

Jothan Frakes
Tel: +1.206-355-0230


--047d7b3a83de6b7b9e05238b3ecc-- From nobody Mon Nov 2 01:24:28 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA3D1B3590 for ; Mon, 2 Nov 2015 01:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 hBymlcF5ef9B for ; Mon, 2 Nov 2015 01:24:25 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18AAF1B358F for ; Mon, 2 Nov 2015 01:24:24 -0800 (PST) Received: (qmail 45979 invoked from network); 2 Nov 2015 09:24:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b39a.56372bc5.k1511; bh=7td42Xy4teiepVqnTBHow1U35qlDXECYBBvD90GHpuw=; b=aHH9bsnWe09+PGmhaq0ZziJKnqZU9D/poqHUcLDxyjjlwUBL30SZ4AHeNwvgB6DXMquv1VIKMFwcVpwTxD+kNi+ME4sPGHHXEDJhZfKnEw4Zg1YO9VgNFeHk2I0a2f/D/FllV1zGmBk+/KYl06LvVT/qD0p/g9BedmoZsCay3BIpv2vFpnt3Hx3Huy06I6Z8zsvW+foX31z1nnQ9fhBtZPxFsstOdfIh7QmvdQH7facmkKI98qh7mwwup+anwj5O DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b39a.56372bc5.k1511; bh=7td42Xy4teiepVqnTBHow1U35qlDXECYBBvD90GHpuw=; b=ou7chms1KnsmZLS2FO88V9eajhcf+aUNnhbK7AhB4RcZUfIQd7srpM8aaQrIIKZb0/ncy2z2cxRmD/luo6Seyvr5bSdnsFv7OhiR3lWcqk0Tw8rrag8hR+4PELML6lTo5ZdzFI9MJA1Xh6Jp/x7iQL/KIqXZXotAQhOjhoMTDScBCa3rfrbqq/Ny8AuzWL7+xhwlH023JwNrc8kbtQJ7FUAKIFWBIOavZNSJIbz64H9UnGH3G1l3HAlck78bJvdH Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 02 Nov 2015 09:24:21 -0000 Date: 2 Nov 2015 18:24:18 +0900 Message-ID: From: "John R Levine" To: "Jothan Frakes" In-Reply-To: References: <20151102065541.44322.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 09:24:26 -0000 >> I) self publishing vs. third party >> > On the third of these, thinking root-down, where there is an authority > chain from a parent entity (in Delegation) to child, I am pondering is > "self-publishing vs third party" stretches to fit the status quo if there > is a concept of authoritative chain. I'd say that was self publishing. By third party I was thinking of someone like the group at Mozilla that maintains the current PSL. Self publishing would be something like putting the info in a standard place in the part of DNS tree that the publisher controls. > What I mean is that within the concept of "trust", if one were to pick > between "self published" and "third party", which would be more trusted? That depends entirely on who the third party is and what we think of the entities publishing. > The IANA public suffix list (which gets generated from the root zone) is a > "third party" list as it would relate to most everything with (perhaps > excluding .int or .arpa to be pedantic). IANA publishes a list of TLDs but that is extremely definitely not a public suffix list since, among other things, they make no assertion about the structure of the names underneath each TLD. R's, John From nobody Mon Nov 2 07:36:27 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D722B1B488E for ; Mon, 2 Nov 2015 07:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 A_4XqPglVi_D for ; Mon, 2 Nov 2015 07:36:24 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 B67461B47D5 for ; Mon, 2 Nov 2015 07:36:23 -0800 (PST) Received: by lfgh9 with SMTP id h9so16650738lfg.1 for ; Mon, 02 Nov 2015 07:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jothan_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SjgfRRhFfFgFZrW6LM4MXK13xYfccnPhZCf4u9ZpdF0=; b=XsxgvLvc0Jf6kyAtstpeP3y0mJl5FV2b2YDpvZD2CgTD+XQ7SEXZhclLz6eryqNHXJ 6idPWA8W4k+aawWt7J0VxXSb2Ta4t6aF6bOmF6Qp5qeM5Ize3tuzU7Pjfvq0/iH1t67l y/KEaLD+Os1TUYWQCcgzcyFvIXx33yGu87+/+EYeRs+vCjKJQs6qHQpZrFRAl6iRS07j /bcTt11IJpbsJcmvfa3d0rXaV5Qfi1lIFxQkuYcm9CqGspjOR+ntmAltBEWxLr+TNPHE jH5b7P3TsR+0SHOJRm+N00+HUMd4jlwklnzXV9bWFojTH0NJ/MeMXQ/dDSboekW6JP5H 3Awg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SjgfRRhFfFgFZrW6LM4MXK13xYfccnPhZCf4u9ZpdF0=; b=U2xE4RQ5LJ1SXaFAh1dcThPGOFJhJUeQ657X4c6ucMiueuvNeVzKgtpAUL6tau9sYH 6hfkkMhtRj29Tx9fKnJRKNZ10k2e/m7xhMQ7HgrT/dL3K3kzK6kx4Vj0kZxzfVvaTAFh GQTGocj1dVuaL+Hsae6XMCoCMiDgMGbkYZViFBJ9KbOUjogtoSaLskIfstTT1/Rwicwo S4VV4crMCAZnaUx/bAwgTG+NoTTsaTxExBpCbQ5HcAPJQ+ep4g/SdYTY0IM78HeYgJYD SXq8TEgBtF2DBXffwHr3c9cyHFimJXI9vp5EVczNUFFCZTjoy85HbSB2V+SKUaH9jTOg vXhA== X-Gm-Message-State: ALoCoQklHNV9D67B0L38dBWbMSJLFAFpjLjRphhDnWlVgsNRFtJ7gXTF2y99mfFlnN8YORsSH7cF X-Received: by 10.25.86.198 with SMTP id k189mr3083685lfb.36.1446478581643; Mon, 02 Nov 2015 07:36:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.140.3 with HTTP; Mon, 2 Nov 2015 07:35:52 -0800 (PST) In-Reply-To: References: <20151102065541.44322.qmail@ary.lan> From: Jothan Frakes Date: Mon, 2 Nov 2015 07:35:52 -0800 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a1141777a08e2a90523908adc Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 15:36:26 -0000 --001a1141777a08e2a90523908adc Content-Type: text/plain; charset=UTF-8 > > > On Mon, Nov 2, 2015 at 1:24 AM, John R Levine wrote: > I) self publishing vs. third party >>> >>> On the third of these, thinking root-down, where there is an authority >> chain from a parent entity (in Delegation) to child, I am pondering is >> "self-publishing vs third party" stretches to fit the status quo if there >> is a concept of authoritative chain. >> > > I'd say that was self publishing. By third party I was thinking of > someone like the group at Mozilla that maintains the current PSL. Self > publishing would be something like putting the info in a standard place in > the part of DNS tree that the publisher controls. > > My point was that it is not a clear fit in either without using subjectivity - and that subjectivity lends itself to softening the benefit of the classification. I respect where you see it as self publishing, and hold your opinion as being a completely reasonable and a possible one that someone could come to. I can also see a reasonable person coming to a different conclusion in how they would categorize it as I do, as a third party list. The challenge here is that it is neither your or my categorization being right or wrong is the issue - the challenge is that we should help ensure that how it gets categorized requires as little subjectivity as possible so that there is a consistent and clear outcome. > What I mean is that within the concept of "trust", if one were to pick >> between "self published" and "third party", which would be more trusted? >> > > That depends entirely on who the third party is and what we think of the > entities publishing. Right - this is the subjectivity. I think at the core of my comment on this was 'authority' as part of trust of the list. Which still might prove to be subjective as well - or application/use/purpose dependant. > > > The IANA public suffix list (which gets generated from the root zone) is a >> "third party" list as it would relate to most everything with (perhaps >> excluding .int or .arpa to be pedantic). >> > > IANA publishes a list of TLDs but that is extremely definitely not a > public suffix list since, among other things, they make no assertion about > the structure of the names underneath each TLD. > > Completely hear you on the current state of that - yet unfortunately many integrators and developers use the IANA list for what 'tis or 'taint a TLD for validation purposes. Anyway, I was more alluding to 'future state' of IANA PSL - I should have probably been better about citing what the ICANN SSAC concluded with respect to this so that it did not sound like I was proclaiming my opinion on the IANA list in its current form to be fact. https://www.icann.org/en/system/files/files/sac-070-en.pdf (see recommendation 5 from ICANN's Security and Stability Advisory Committee (SSAC) was that IANA create and distribute a PSL), --001a1141777a08e2a90523908adc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 2, 2015 at 1:24 AM, John R Levin= e <johnl@taugh.com> wrote:
I) self publishing vs. third party

On the third of these, thinking root-down, where there is an authority
chain from a parent entity (in Delegation) to child, I am pondering is
"self-publishing vs third party" stretches to fit the status quo = if there
is a concept of authoritative chain.

 I'd say that was self publishing.=C2=A0 By third party I was thinking o= f someone like the group at Mozilla that maintains the current PSL.=C2=A0 S= elf publishing would be something like putting the info in a standard place= in the part of DNS tree that the publisher controls.


My point was that it is not a c= lear fit in either without using subjectivity - and that subjectivity lends= itself to softening the benefit of the classification. =C2=A0=C2=A0
<= div>
I respect where you see it as self publishing, and hold = your opinion as being a completely reasonable and a possible one that someo= ne could come to.=C2=A0 I can also see a reasonable person coming to a diff= erent conclusion in how they would categorize it as I do, as a third party = list.=C2=A0 The challenge here is that it is neither your or my categorizat= ion being right or wrong is the issue - the challenge is that we should hel= p ensure that how it gets categorized requires as little subjectivity as po= ssible so that there is a consistent and clear outcome.
=C2=A0
What I mean is that within the concept of "trust", if one were to= pick
between "self published" and "third party", which would= be more trusted?

 That depends entirely on who the third party is and what we think of the en= tities publishing.

Right - this is the subj= ectivity.=C2=A0 I think at the core of my comment on this was 'authorit= y' as part of trust of the list. =C2=A0 Which still might prove to be s= ubjective as well - or application/use/purpose dependant.
=C2=A0<= /div>


The IANA public suffix list (which gets generated from the root zone) is a<= br> "third party" list as it would relate to most everything with (pe= rhaps
excluding .int or .arpa to be pedantic).

 IANA publishes a list of TLDs but that is extremely definitely not a public= suffix list since, among other things, they make no assertion about the st= ructure of the names underneath each TLD.


Completely hear you on the current state o= f that - yet unfortunately many integrators and developers use the IANA lis= t for what 'tis or 'taint a TLD for validation purposes.
=
Anyway, I was more alluding to 'future state' of IAN= A PSL - I should have probably been better about citing what the ICANN SSAC= concluded with respect to this so that it did not sound like I was proclai= ming my opinion on the IANA list in its current form to be fact. =C2=A0https://= www.icann.org/en/system/files/files/sac-070-en.pdf=C2=A0(see recommenda= tion 5 from ICANN's Security and Stability Advisory Committee (SSAC) wa= s that IANA create and distribute a PSL),


=
--001a1141777a08e2a90523908adc-- From nobody Mon Nov 2 16:28:20 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C76B1A9308 for ; Mon, 2 Nov 2015 16:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 2wSPbcNv0kJo for ; Mon, 2 Nov 2015 16:28:18 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E17C1A9302 for ; Mon, 2 Nov 2015 16:28:17 -0800 (PST) Received: (qmail 99099 invoked from network); 3 Nov 2015 00:28:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1831a.5637ffa1.k1511; bh=Xp6kTv1TL3n46/f/KBz/t+ZKJr/wr4MqXnSSQIY6lSg=; b=FcGcVYFmJ0VoVkiyL2wYG8SCmdJQBi1kwG4YKxZC+LDYhaTDt0ovrYYPNYtDpO92ONcNHSCxvzilLvUXLjir7Kl5kmJSIa3YD9E+VFKDC8Y7txZFjPFxxuWSSe6xd6ZNDuy0jVrGvxvpKljI/xg8qDboiIfTaIVnRW1Emv540zppVjCjZXbT7gOWIB5R5ru6Qa9sowKW2pCiw4Flpw2WdFxU9+4C6WDu8XgiI7HEkgdnd/e0uY+MGbROfwKKmfOj DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1831a.5637ffa1.k1511; bh=Xp6kTv1TL3n46/f/KBz/t+ZKJr/wr4MqXnSSQIY6lSg=; b=RSYDQXFi+nfZXluQg4sot+U0+LctIShLF3+xnHfC1x/O9PAuzDHUJ4XksIOfeWMU4ktBG5pXcGNCLGDDQdzgmQkRIOnFRCK/ul+tfSs1tX7AeMEK+RMOPEdbNgzfQdVKViEN2azR72gt7XCP2VI9VnHVbG7CrqIrDMg6WjMfDEh/tX0BQXc8BXXQMXh1965xTCYbmbB2uh6B6td4cA0WUR6/Ca13GfWijJ+Gw/mzi1gLaFtfp4xhswdtco2QqkE8 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 03 Nov 2015 00:28:16 -0000 Date: 3 Nov 2015 09:28:11 +0900 Message-ID: From: "John R Levine" To: "Jothan Frakes" In-Reply-To: References: <20151102065541.44322.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 00:28:19 -0000 > Completely hear you on the current state of that - yet unfortunately many > integrators and developers use the IANA list for what 'tis or 'taint a TLD > for validation purposes. Please don't confuse public suffixes with TLDs. For example, .co.uk is a public suffix but not a TLD, while .bloomberg is a TLD, but it's not a public suffix.* Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. * - yes, I know it's in the PSL but that's due to the limits of the current text format, not because it's actually public. From nobody Mon Nov 2 18:15:34 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD4E1ACC83 for ; Mon, 2 Nov 2015 18:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 cIhggMDTFUzy for ; Mon, 2 Nov 2015 18:15:32 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2FA1ACD65 for ; Mon, 2 Nov 2015 18:15:31 -0800 (PST) Received: by ioll68 with SMTP id l68so5775616iol.3 for ; Mon, 02 Nov 2015 18:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AhAqLXiMKB60SyimYejtVmngKVctTGV2rqhS9/KQ8cs=; b=X+MG+4KFINjx3rj+s/inAhe7jirMUtl41p73MfQsfwmpVqG1kUIS0MBl7d5RpOEmOR SNzSK9xLjJdVodKDBmZ/hH/sDtJQbDKw/IMUZfCrDkhTfsVPlWaciJceGmyeCn8k2ZGe laFVrnM+U2y5J+HF6D4vZowc/eVLv8NKAqzzE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=AhAqLXiMKB60SyimYejtVmngKVctTGV2rqhS9/KQ8cs=; b=elpys5V/OERS7DMDpx/MMD4LLZrzBC22M7zBHTV6SEZ607mqmq7WCZs2sLowiIUe63 edDDi9n2bB1u1Uld1K98eGM2+WZ8+6MWp/5MocK4l6gByioz9LfNaArLuB211nziGtPr eKAfmolF/e53piZkDAkdAXeyYpMvrly07Ogrb4BYCmfSpDlz8d54GE5eWgtiRCJ+lCji bUryC8IytXUpiaC8jYDgeaHZimccRotoKiDdoLOIFgYVTlzHDK+8+hNr3C+XsTtkCt81 9rmOq9BnWhmeQu+pGNa3EkU21LLkUCVnbAC758xb9H4YRJccYqS43HCaIQfWSD3ema22 IzvQ== X-Gm-Message-State: ALoCoQnifRwMDlXTNiCVQ4woWvzKGIDVr6zL5K5F/JBH2Hdj6I2cMaH16Qyq1Zbd4AwENQsc3v3S MIME-Version: 1.0 X-Received: by 10.107.19.219 with SMTP id 88mr30057056iot.41.1446516930539; Mon, 02 Nov 2015 18:15:30 -0800 (PST) Received: by 10.50.202.71 with HTTP; Mon, 2 Nov 2015 18:15:30 -0800 (PST) In-Reply-To: References: <20151102065541.44322.qmail@ary.lan> Date: Mon, 2 Nov 2015 21:15:30 -0500 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=001a113f94bece93030523997773 Archived-At: Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:15:33 -0000 --001a113f94bece93030523997773 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 2, 2015 at 4:17 AM, Jothan Frakes wrote: > > > On Monday, November 2, 2015, John Levine wrote: > >> >> Here are three axes to characterize technical approaches >> >> 1) DNS vs. non-DNS >> a) single boundary in a name vs. multiple >> I) self publishing vs. third party >> >> > On the third of these, thinking root-down, where there is an authority > chain from a parent entity (in Delegation) to child, I am pondering is > "self-publishing vs third party" stretches to fit the status quo if there > is a concept of authoritative chain. > > What I mean is that within the concept of "trust", if one were to pick > between "self published" and "third party", which would be more trusted? > > If I understand what you are saying, this is in part a question of backwards compatibility. draft-deccio-dbound-organizational-domain-policy [1] addresses this by building a "policy-negative realm" into the top of the DNS hierarchy under the _odup domain name, such that all names in the _odup DNS domain comprise what is essentially equivalent to the current public suffix list. This makes it so one can effectively be generated by the other for a time. See Section 5 for details. > Would the parent zone in DNS be "third party", for example? > > The IANA public suffix list (which gets generated from the root zone) is a > "third party" list as it would relate to most everything with (perhaps > excluding .int or .arpa to be pedantic). > I'm not sure there is anything claiming to be a public suffix list from IANA or how it could be generated from the root zone. The root zone contains delegations to top-level (i.e., single-label) domains; their "public" or non-public status is not inherent in their name. Casey [1] http://datatracker.ietf.org/doc/draft-deccio-dbound-organizational-domain-policy/ (version 00) --001a113f94bece93030523997773 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 2, 2015 at 4:17 AM, Jothan Frakes <jothan@jothan.com> wrote:


On Monday, November 2, 2015, Joh= n Levine <johnl@tau= gh.com> wrote:

Here are three axes to characterize technical approaches

1) DNS vs. non-DNS
a) single boundary in a name vs. multiple
I) self publishing vs. third party


On the third of these, thinking roo= t-down, where there is an authority chain from a parent entity (in Delegati= on) to child, I am pondering is "self-publishing vs third party"= =C2=A0stretches to fit the status quo if there is a concept of authoritativ= e chain.=C2=A0

What = I mean is that within the concept=C2=A0of "trust", if one were to= pick between "self published" and "third party", which= would be more trusted? =C2=A0


If I understand what you are saying, this is in part a question of= backwards compatibility.

draft-deccio-dbound-orga= nizational-domain-policy [1] addresses this by building a "policy-nega= tive realm" into the top of the DNS hierarchy under the _odup domain n= ame, such that all names in the _odup DNS domain comprise what is essential= ly equivalent to the current public suffix list.=C2=A0 This makes it so one= can effectively be generated by the other for a time. See Section 5 for de= tails.
=C2=A0
Would the parent z= one in DNS be "third party", for example?

The = IANA public suffix list (which gets generated from the root zone) is a &quo= t;third party" list as it would relate to most everything with (perhap= s excluding .int or .arpa to be pedantic).

I'm not sure there is anything claiming to be a public suffix lis= t from IANA or how it could be generated from the root zone.=C2=A0 The root= zone contains delegations to top-level (i.e., single-label) domains; their= "public" or non-public status is not inherent in their name.

Casey

--001a113f94bece93030523997773-- From nobody Mon Nov 2 19:00:07 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57F51ACEA2 for ; Mon, 2 Nov 2015 19:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 9utj4TpRYYiR for ; Mon, 2 Nov 2015 19:00:05 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 881D81ACE95 for ; Mon, 2 Nov 2015 19:00:05 -0800 (PST) Received: by iody8 with SMTP id y8so6528367iod.1 for ; Mon, 02 Nov 2015 19:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T3/QYtj0ZTyRTPwd6ncMyLzZfRqKCmrKrcixXxxNBoM=; b=ROlCTkTY4MfVYnPnQh5KdwXBkHIyftLR6Q7QZynzLry9ixunp2+0XFiYKZiajkdzxt KObRgLVQrd2XpaxVLsQjkWKlh/CXmpP0xx8IB8m6LCZU0GRShUN0YIehUcM8Au1/marZ SXW23oBDhruzJHHu9Ol1bnP78Sbhm4WYWJH+Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T3/QYtj0ZTyRTPwd6ncMyLzZfRqKCmrKrcixXxxNBoM=; b=PZNxA7RjGU0jscNyj6k1j1AfIu6vwcE0wsJJaK11pZg0iJ2Bg61rT5uSLYH5d30h6A zwQyepXP3FVsPsgMEh1hOn6g8MUFe/86di4AjluKTLA8R5CNc8GBoiiGWww8Z9/EjSsh Nw4723nUQrVMF0rjYJnpTVLQCvE89/m4u8ETEthXQvzJWG7BnTzQSBhi1LE0gaeadc3g RxyAXhhLBnbTv5uffJ0Y6TJ/MixtQ2xsEfxg/U+5FV/xAFeDs3u1NWvuDG+UmFvGCbrg +KjnWL6N5BacPnF7O2XFSJhnwmZr9EmipwW1VrP+C81IYTDYuUe9t7iFdChtAUhoG4LT 7tGw== X-Gm-Message-State: ALoCoQnFQq2FVbyNhr805azYi4u1h0z7o5tKf4hCwuJZzOre26nJY6GNbTtDp89Q12B9ZoSnrccD MIME-Version: 1.0 X-Received: by 10.107.19.219 with SMTP id 88mr30232539iot.41.1446519604870; Mon, 02 Nov 2015 19:00:04 -0800 (PST) Received: by 10.50.202.71 with HTTP; Mon, 2 Nov 2015 19:00:04 -0800 (PST) In-Reply-To: <20151102065541.44322.qmail@ary.lan> References: <20151102065541.44322.qmail@ary.lan> Date: Mon, 2 Nov 2015 22:00:04 -0500 Message-ID: From: Casey Deccio To: John Levine Content-Type: multipart/alternative; boundary=001a113f94be3594be05239a17c4 Archived-At: Cc: Murray Kucherawy , "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 03:00:06 -0000 --001a113f94be3594be05239a17c4 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 2, 2015 at 1:55 AM, John Levine wrote: > >We are concerned that the working group is still in a phase of discussing > >the problem definition. > > Here are three problems: > > * the browser cookie problem > * the CA name/wildcard problem > * the DMARC organizational domain problem > > +1 Solid examples. I insert here a third category: "solution scope" * hierarchical domain bounding * cross-domain bounding There was agreement in the working group meeting in Prague that both should be considered. But it's not to say that a single solution can/should address both. > Here are three axes to characterize technical approaches > > 1) DNS vs. non-DNS > a) single boundary in a name vs. multiple > I) self publishing vs. third party > > For example, the existing PSL is non-DNS, multiple boundary, third party. > These are good. Although I think the second item (single vs. multiple boundaries) is probably moot since single *is* the current state of things and thus really isn't an option for future solutions. Also, because of the "solution scope" category I added above, "single boundary in a name" or "boundary in a name" at all might not make sense in some paradigms (e.g., the cross-domain). Although, this is kind of a nit. > This is not every possible problem and every possible axis, but I > think it's a large enough set that if we came up with an approach that > addressed all three problems, and we generally agreed that the point > on the axes meets people's practical needs, we could declare success. > +1 Casey --001a113f94be3594be05239a17c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 2, 2015 at 1:55 AM, John Levine <johnl@taugh.com> wrot= e:
>We are concerned that the working group is still= in a phase of discussing
>the problem definition.

Here are three problems:

* the browser cookie problem
* the CA name/wildcard problem
* the DMARC organizational domain problem


+1

Solid exam= ples.

I insert here a third category: "soluti= on scope"

* hierarchical domain bounding
* cross-domain bounding

There was agreement = in the working group meeting in Prague that both should be considered.=C2= =A0 But it's not to say that a single solution can/should address both.=
=C2=A0
Here are three axes to characterize technical approaches

1) DNS vs. non-DNS
a) single boundary in a name vs. multiple
I) self publishing vs. third party

For example, the existing PSL is non-DNS, multiple boundary, third party.

These are good.=C2=A0 Although I think t= he second item (single vs. multiple boundaries) is probably moot since sing= le *is* the current state of things and thus really isn't an option for= future solutions.=C2=A0 Also, because of the "solution scope" ca= tegory I added above, "single boundary in a name" or "bounda= ry in a name" at all might not make sense in some paradigms (e.g., the= cross-domain).=C2=A0 Although, this is kind of a nit.

=

This is not every possible problem and every possible axis, but I
think it's a large enough set that if we came up with an approach that<= br> addressed all three problems, and we generally agreed that the point
on the axes meets people's practical needs, we could declare success.

+1

Casey
--001a113f94be3594be05239a17c4-- From nobody Mon Nov 2 20:13:07 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A4B1B2CEB for ; Mon, 2 Nov 2015 20:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 y4-1ygT7bt8t for ; Mon, 2 Nov 2015 20:13:04 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1E81B2CB4 for ; Mon, 2 Nov 2015 20:13:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 354371E59F6 for ; Mon, 2 Nov 2015 20:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8Ka51lrZ4f2 for ; Mon, 2 Nov 2015 20:12:30 -0800 (PST) Received: from t20010c400000302418ef1e5e1effddeb.v6.meeting.ietf94.jp (t20010c400000302418ef1e5e1effddeb.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:18ef:1e5e:1eff:ddeb]) by c8a.amsl.com (Postfix) with ESMTPA id D94321E59F2 for ; Mon, 2 Nov 2015 20:12:29 -0800 (PST) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2015 20:13:02 -0800 Message-Id: <595705A5-A883-42F3-AC54-A133CE460F2C@amsl.com> To: dbound@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Sendlaterdate: Mon, 2 Nov 2015 20:13:02 -0800 X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [dbound] Queue for DBOUND Remote Attendees X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:13:05 -0000 If you are planning to participate in the DBOUND session here at IETF 94 = today =97 either locally in Yokohama or as a remote participant =97 we = want to make sure that you are aware that the IETF is providing a remote = participants with a fairly new way to ask questions or make comments. In = addition to using the Jabber room, for the DBOUND session there is also = the opportunity for remote participants to enter a virtual queue and ask = questions directly into the meeting room.=20 This experimental queue was used in several sessions at IETF 92 and IETF = 93, so you may have already seen it in action. There will be two queues = for the DBOUND session =97 a virtual queue and an actual (in-room) = queue. Remote attendees will log into the Meetecho platform and will = have a virtual mic line that they can enter if they have a question or = comment. In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20 Information on how to join the Meetecho session is at = http://ietf94.conf.meetecho.com/. Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf94.conf.meetecho.com/index.php/Self_Test.=20 Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From nobody Mon Nov 2 22:24:16 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C28B1B2A69 for ; Mon, 2 Nov 2015 22:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 g3l0E55ZnxH6 for ; Mon, 2 Nov 2015 22:24:13 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CFDD1B2A60 for ; Mon, 2 Nov 2015 22:24:13 -0800 (PST) Received: (qmail 42859 invoked from network); 3 Nov 2015 06:24:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a76a.5638530b.k1511; bh=tPrb9Xzfgwm9+XPxn/VXNtVwFhilimjcqEa2IaV0OxI=; b=wdx4g6iqFoZk39HF/IvnZS8ofOaowwxc1XAbG53CcAm3XSn4hAocOLC3YyJ/tjH1Q+wHJQqoO7qbREfHKB95KE8K9tFVkFQQVZ73Skz2qYmJovlhcjTF/J8k1m37do3dCI09pLD6btlslLQP6yZaak0Y5ZP14u3nkWSxqEWsf1FW5u6HTSAyhZnbySjbRv2F6zfp4ZfFoWbMETetSj4FL5iTy8DnqHrEbDp7x/68Qn6P+Hn7itu2bfsAkcf8lFvL DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a76a.5638530b.k1511; bh=tPrb9Xzfgwm9+XPxn/VXNtVwFhilimjcqEa2IaV0OxI=; b=elL31zqE9/IOG+EqzxJPnrr8MyX/SpVTsaeDsPk1+Zt55DxlSlwoMU7TraoDbK6/SspVoHmwmkZoQFqatFSEJ3uYEMaMoOszK7/cXlUCzjos7CsTF48/i1SJKgScZ5z7MagxRJX2RkfNsk7KtWNsGbDxYuPo6S7CocVWppqoMRnEx4IOkWc7SRbYStgvLNuOcmz45Q0ScmQGoLBEeLktPIWn8fd1ohE7qSE/0tNZ+ox2PKPHZV+mFBIPwOUbCRU9 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 03 Nov 2015 06:24:11 -0000 Date: 3 Nov 2015 15:24:08 +0900 Message-ID: From: "John R Levine" To: "Casey Deccio" In-Reply-To: References: <20151102065541.44322.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 06:24:14 -0000 > * hierarchical domain bounding > * cross-domain bounding > > There was agreement in the working group meeting in Prague that both should > be considered. But it's not to say that a single solution can/should > address both. I know, but in view of the lack of progress I propose we limit the scope to hierarchies. > Although I think the second item (single vs. multiple boundaries) is > probably moot since single *is* the current state of things and thus > really isn't an option for future solutions. Really? Look in the PSL and you'll find com and compute.amazonaws.com and eu-central-1.compute.amazonaws.com. R's, John From nobody Mon Nov 2 23:29:10 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94C91A0103 for ; Mon, 2 Nov 2015 23:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham 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 TYrO9WYY7-Fb for ; Mon, 2 Nov 2015 23:28:30 -0800 (PST) Received: from lvs-ipout-01-data1.paypalcorp.com (lvs-ipout-01-data1.paypalcorp.com [173.224.161.143]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78CF91A00CF for ; Mon, 2 Nov 2015 23:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1446535710; x=1478071710; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TvJySapS0G9NDv5AsOSBJ9FYdBSnDOg60wygn5NjgN8=; b=d+LHfHY9I1KtrZlByAOMbOy8esSRVd4G4cygvPaW5MBSJnTLF0gkdnUh uMb2Wylbi8aL+qL5HByGtiTDVVHydQ+x1w/ae3Q/ZQx/Ctk2J3YsKgXsm dX319xsdH9pEL9sA04lyz5UiDM5YuyvSLzTML9QBxApqX3hgNrFpgZlUc 6RH+AZzO1Rwbf+RH6HOPJzbGNThDEYHVLtPBfeTFME4zDX9j93WDKU6qd y7YYgmwRxSSpYpRTl4ND7tbegrIzuGLPIGzoThIEe/P8mSTY8/B2WEffq C6ytA8i9k2SlDk2U8+6miCa2UpeX6YX5lelPbcGdsLf40TQvVmodKmXq6 w==; X-IronPort-AV: E=Sophos;i="5.20,238,1444719600"; d="scan'208,217";a="5175485" Received: from unknown (HELO den-ipcld-02-data1.paypalcorp.com) ([10.185.246.167]) by lvs-ipout-01-data1.paypalcorp.com with ESMTP; 02 Nov 2015 23:28:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,238,1444716000"; d="scan'208,217";a="3490407" X-CloudService: Office365 Received: from mail-by2lp0236.outbound.protection.outlook.com (HELO na01-by2-obe.outbound.protection.outlook.com) ([207.46.163.236]) by den-ipcld-02-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA; 03 Nov 2015 00:28:28 -0700 Received: from CO2PR06MB457.namprd06.prod.outlook.com (10.141.196.142) by CO2PR06MB457.namprd06.prod.outlook.com (10.141.196.142) with Microsoft SMTP Server (TLS) id 15.1.306.13; Tue, 3 Nov 2015 07:28:25 +0000 Received: from CO2PR06MB457.namprd06.prod.outlook.com ([10.141.196.142]) by CO2PR06MB457.namprd06.prod.outlook.com ([10.141.196.142]) with mapi id 15.01.0306.003; Tue, 3 Nov 2015 07:28:25 +0000 From: "Hodges, Jeff" To: "dbound@ietf.org" Thread-Topic: [dbound] Proposed scope of work Thread-Index: AQHRFTuPlkJmjg5RcE6MJ/WnuoSDNp6JUU0A Date: Tue, 3 Nov 2015 07:28:25 +0000 Message-ID: References: <20151102065541.44322.qmail@ary.lan> In-Reply-To: <20151102065541.44322.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jeff.hodges@paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.93.37.221] x-microsoft-exchange-diagnostics: 1; CO2PR06MB457; 5:etp/jNG2CcD8ce6AasHwNodw8RFxwLJTBgYX5zXloBpjTKG8th/I6LFJ71Lr+Mb1T20ZgxDKtFzk5xvjym2rozNVbTZe5X7zC+xvr0tBEbvfU9InOjkbshUOnu2IB4juF8dOmfdkrmQel1Be3t9jpg==; 24:wVHqNju+2+whdrz15xCOvGzClkiWiru8aIHgGIYFyoGK077lH5r8gTrymkTUnsjPn7st7xKpOFs4EmMSd8PLhhPUtCPaNZa5+9pOEBccBB4=; 20:Y6CDe7YvIVcdJVsh9zfriu7hjxuUbAAZrdrvIUG2u+HZePqflKmmYNSB6SKMpyObqvmRhWmYYBO5nZTHMZf8bg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR06MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:CO2PR06MB457; BCL:0; PCL:0; RULEID:; SRVR:CO2PR06MB457; x-forefront-prvs: 0749DC2CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(24454002)(377454003)(52604005)(199003)(189002)(5002640100001)(5007970100001)(5004730100002)(10770500003)(87936001)(19580395003)(11100500001)(19580405001)(10630500004)(99286002)(102836002)(189998001)(15975445007)(77096005)(107886002)(2351001)(86362001)(110136002)(105586002)(106356001)(106116001)(50986999)(54356999)(76176999)(5001960100002)(97736004)(5008740100001)(4500500003)(81156007)(101416001)(2900100001)(19617315012)(2950100001)(66066001)(10130500003)(92566002)(10400500002)(10290500002)(73692002)(82432001)(10300500001)(450100001)(36756003)(40100003)(2501003)(16236675004)(122556002)(77072002)(56826009)(10010500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR06MB457; H:CO2PR06MB457.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: paypal.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D25DA0693C44Ajehodgespaypalcorpcom_" MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2015 07:28:25.5141 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR06MB457 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 07:29:08 -0000 --_000_D25DA0693C44Ajehodgespaypalcorpcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable the below seems useful, thanks for writing it up. I have an additional "p= roblem" to add, below: On 11/1/15, 10:55 PM, "John Levine" > wrote: We are concerned that the working group is still in a phase of discussing the problem definition. Here are three problems: * the browser cookie problem * the CA name/wildcard problem * the DMARC organizational domain problem * HSTS & HPKP feature an "includeSubDomains" directive which means that th= e policy in question (HTTP Strict Transport Security, or HTTP Public Key Pi= ning) applies not only to the hostname that declared the policy, but ALL su= bdomains thereof. In terms of how a dbound solution might be applied here: It would be advant= ageous to be able to have it apply to all subdomains down the inverted doma= in name tree UNTIL a declaration of different policy realm is encountered. HTH, =3DjeffH Here are three axes to characterize technical approaches 1) DNS vs. non-DNS a) single boundary in a name vs. multiple I) self publishing vs. third party For example, the existing PSL is non-DNS, multiple boundary, third party. This is not every possible problem and every possible axis, but I think it's a large enough set that if we came up with an approach that addressed all three problems, and we generally agreed that the point on the axes meets people's practical needs, we could declare success. If we came up with an approach per problem we might declare success depending on how confident we were that the points on the axes were the ones that people need. R's, John _______________________________________________ dbound mailing list dbound@ietf.org https://www.ietf.org/mailman/listinfo/dbound --_000_D25DA0693C44Ajehodgespaypalcorpcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8D890AAE5963B44D86728A21795172BD@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
the below seems useful, thanks for writing it up.   I have an add= itional "problem" to add, below:

On 11/1/15, 10:55 PM, "John Levine" <johnl@taugh.com> wrote:

We are concerned that the working group is still in a phase of discuss= ing
the problem definition.

Here are three problems:

* the browser cookie problem
* the CA name/wildcard problem
* the DMARC organizational domain problem

*  HSTS & HPKP feature an "includeSubDomains" direc= tive which means that the policy in question (HTTP Strict Transport Securit= y, or HTTP Public Key Pining) applies not only to the hostname that declare= d the policy, but ALL subdomains thereof.  

In terms of how a dbound solution might be applied here: It would be a= dvantageous to be able to have it apply to all subdomains down the inverted= domain name tree UNTIL a declaration of different policy realm is encounte= red. 

HTH,

=3DjeffH


Here are three axes to characterize technical approaches

1) DNS vs. non-DNS
a) single boundary in a name vs. multiple
I) self publishing vs. third party

For example, the existing PSL is non-DNS, multiple boundary, third par= ty.

This is not every possible problem and every possible axis, but I
think it's a large enough set that if we came up with an approach that=
addressed all three problems, and we generally agreed that the point
on the axes meets people's practical needs, we could declare success.<= /div>

If we came up with an approach per problem we might declare success
depending on how confident we were that the points on the axes were
the ones that people need.

R's,
John

_______________________________________________
dbound mailing list


--_000_D25DA0693C44Ajehodgespaypalcorpcom_-- From nobody Tue Nov 3 00:03:33 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710951B2F4C for ; Tue, 3 Nov 2015 00:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 K69GdzbxEL-J for ; Tue, 3 Nov 2015 00:03:31 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 F036F1B2F4B for ; Tue, 3 Nov 2015 00:03:30 -0800 (PST) Received: by ioll68 with SMTP id l68so11224042iol.3 for ; Tue, 03 Nov 2015 00:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x6/wyOslwkjG0VtD30X2KLTHKmyo8TG750PWGqAIBWI=; b=Ds5E8H0n4YFhleoz88bCoI7qd4l7AI7GHjNn8kZZS7XQQl2OUmse+kvDw7psDNzAo5 flldRjF9wvbYusPjWXbjQT2pWk7KZSZvmAFtOdHpaa21GnW0d4ZfvVut9y9FGNJKtD0q Ch9UDAzZYzHho42G76x/OO1J8nPj03QY8+qKI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x6/wyOslwkjG0VtD30X2KLTHKmyo8TG750PWGqAIBWI=; b=aaw7QkB/oqEIBavCyKPsaNcjHni2Sigo9dGPCr5N/U49uk0TjiDawMuv1FDaJaxnu4 htPYvxaHe4HY/Cw+px03l3FWEC90igCKsFS5qQoEGKCCRrcUzEy3pEcunzqMhvBFSKg1 mSduaJGqXLLSw0rBHyt5fdetzKzb/FoGOMGyiZYUMNjxZEXWKZbTNhsxa6nZpyOTt/1A RrqorepEyc5BbT6leMlrZ5xe7to1SqMRQOmmGDQrBsgIJTUX67CGqjf+1MqvWYx5a8lQ cJe3jn+H2viSnog1rwL56iziMfi8eKdwbyCaBi3XLeNUg56zlXFmM8ryedPOaMKCRSOi cbdw== X-Gm-Message-State: ALoCoQkj4bRVdFbhwxGx5GvhfJgNsZHsD6ow1TmGGv8uvZ6EaVk8aJcu15HRd3JN9IvNC1xcncS+ MIME-Version: 1.0 X-Received: by 10.107.131.97 with SMTP id f94mr27333372iod.100.1446537810353; Tue, 03 Nov 2015 00:03:30 -0800 (PST) Received: by 10.50.202.71 with HTTP; Tue, 3 Nov 2015 00:03:30 -0800 (PST) In-Reply-To: References: <20151102065541.44322.qmail@ary.lan> Date: Tue, 3 Nov 2015 03:03:30 -0500 Message-ID: From: Casey Deccio To: John R Levine Content-Type: multipart/alternative; boundary=001a113ecac8573cf805239e544e Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 08:03:32 -0000 --001a113ecac8573cf805239e544e Content-Type: text/plain; charset=UTF-8 On Tue, Nov 3, 2015 at 1:24 AM, John R Levine wrote: > * hierarchical domain bounding >> * cross-domain bounding >> >> There was agreement in the working group meeting in Prague that both >> should >> be considered. But it's not to say that a single solution can/should >> address both. >> > > I know, but in view of the lack of progress I propose we limit the scope > to hierarchies. It works for me. At the very least we shouldn't block one, waiting on a silver bullet approach for both. > > Although I think the second item (single vs. multiple boundaries) is >> probably moot since single *is* the current state of things and thus really >> isn't an option for future solutions. >> > > Really? Look in the PSL and you'll find com and compute.amazonaws.com and > eu-central-1.compute.amazonaws.com. > > Yep, really :) The effective outcome of any PSL lookup is the "public suffix" of the name. The algorithm is longest match [1]. That's why there's only one possible organizational domain with the current DMARC algorithm, for example. Casey [1] https://publicsuffix.org/list/ > > R's, > John > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > --001a113ecac8573cf805239e544e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 3, 2015 at 1:24 AM, John R Levine <johnl@taugh.com> wr= ote:
* hierarchical domain bounding
* cross-domain bounding

There was agreement in the working group meeting in Prague that both should=
be considered.=C2=A0 But it's not to say that a single solution can/sho= uld
address both.

 I know, but in view of the lack of progress I propose we limit the scope to= hierarchies.

It works for me.=C2=A0 At the= very least we shouldn't block one, waiting on a silver bullet approach= for both.
=C2=A0

Although I think the second item (single vs. multiple boundaries) is probab= ly moot since single *is* the current state of things and thus really isn&#= 39;t an option for future solutions.

 Really? Look in the PSL and you'll find com and compute.amazonaws.co= m and eu-central-1.compute.amazonaws.com.


Ye= p, really :)

The effective outcome of any PSL look= up is the "public suffix" of the name.=C2=A0 The algorithm is lon= gest match [1].=C2=A0 That's why there's only one possible organiza= tional domain with the current DMARC algorithm, for example.

=
Casey

=C2=A0

R's,
John

_______________________________________________
dbound mailing list
dbound@ietf.org https://www.ietf.org/mailman/listinfo/dbound

--001a113ecac8573cf805239e544e-- From nobody Tue Nov 3 00:08:07 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7BB1B2F7E for ; Tue, 3 Nov 2015 00:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 ohmnJxXMEnpX for ; Tue, 3 Nov 2015 00:08:04 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8661B2F8F for ; Tue, 3 Nov 2015 00:08:01 -0800 (PST) Received: (qmail 64307 invoked from network); 3 Nov 2015 08:07:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fb32.56386b5f.k1511; bh=81do5F0r0nTrCDAPTGgNX8jr2YJ4BOko4ufdLeRFZsg=; b=cy0pANWqzi0vdwnwsX7fJRE4p50fZcY/TfJdL+7PKiMYsVz/fj6cUghtaAvrtEirTx7r0wK4dJPI8uZ3F7x1XfTu1d7VAAO/+ou4h+xKMiYRTzY9ydB9A91RQFvGPCTzxyv+b44QddbdSicJhiRMYukPlHwnPZIxwRUrQKOpSAJeDCOH5dVfpFent9pjAoq6Rw2hWGBsE1zAoZMhz6+oB5vUoN11Ci4x45pGl46+awe2JaSJ7iTwu8WjmASYYW5g DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fb32.56386b5f.k1511; bh=81do5F0r0nTrCDAPTGgNX8jr2YJ4BOko4ufdLeRFZsg=; b=Y/EbOsUUWamtxvFRYmDSTetMjo2Z6QKoMg6VSIH0+SSRy2Zl1yvj233SCxdh5bVltAMC5Oop5ECA4tlO+GdFxcEIQWwubIJ04ZQPt1ft9dKGJ7uVwqUPTxkMDbj3mVyB/dxWod8JxWv3SRENYtI0zAKDAWYRDE2dYntjI8hfdboryOogl4ly9JQdZqSK39fUd6Q00//Xe3xLD8abOdi9SHJ52XBjJn8ttidqEzrLJpLj3PnjSWW/nj7P1kl3VDJd Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 03 Nov 2015 08:07:45 -0000 Date: 3 Nov 2015 17:07:35 +0900 Message-ID: From: "John R Levine" To: "Casey Deccio" In-Reply-To: References: <20151102065541.44322.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 08:08:05 -0000 >> Really? Look in the PSL and you'll find com and compute.amazonaws.com and >> eu-central-1.compute.amazonaws.com. >> > Yep, really :) > > The effective outcome of any PSL lookup is the "public suffix" of the > name. The algorithm is longest match [1]. That's why there's only one > possible organizational domain with the current DMARC algorithm, for > example. Oh, in that case we agree. By multiple I meant that there could be multiple boundaries in a path, not that any particular lookup would return more than one of them. R's, John From nobody Tue Nov 3 00:16:05 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEE81B2F51 for ; Tue, 3 Nov 2015 00:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham 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 QJh2V-YVumP0 for ; Tue, 3 Nov 2015 00:15:59 -0800 (PST) Received: from den-ipout-03-data1.paypalcorp.com (den-ipout-03-data1.paypalcorp.com [173.224.160.157]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951131B2F4F for ; Tue, 3 Nov 2015 00:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1446538558; x=1478074558; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XGqejlDEdd46LvLcCSlmWlV37m64/C1gDU31tS/trIU=; b=uCaP3d10xNGdJa0XXrEMsBcRyokXe+Pjmk4PBgujqR/3ZJtPx3+FnY8i tnPMDU63ImkSyvE9Mj3KAdKo4B37D3nQ1GFw2g/hCbuSd9JE/j3gFm/4e fs1jbkxx3/jqKVCcF7Luwj6t3yYzk6qNipc4ZnQc2m2ajOtP9xS/LFJO5 DLComalCXfwuk3W8MDaY4NBLUKSgSUjhygILrmIGgkJtL6177jNpxFEsn LGT2vfS3bhL3n/v3e7S0kp9QTrLlvDQvL7aH8cg1PNwxak/EAUG0CAgV0 PYeTXq5+Ukm4k+9UrP0L/MysZBVgO67Uf7GaefSjf2KzicixUelnhcwEt g==; X-IronPort-AV: E=Sophos;i="5.20,238,1444716000"; d="scan'208,217";a="5663293" Received: from unknown (HELO lvs-ipcld-02-data1.paypalcorp.com) ([10.184.246.166]) by den-ipout-03-data1.paypalcorp.com with ESMTP; 03 Nov 2015 01:15:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,238,1444719600"; d="scan'208,217";a="2084336" X-CloudService: Office365 Received: from mail-bl2lp0203.outbound.protection.outlook.com (HELO na01-bl2-obe.outbound.protection.outlook.com) ([207.46.163.203]) by lvs-ipcld-02-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA; 03 Nov 2015 00:15:56 -0800 Received: from CO2PR06MB457.namprd06.prod.outlook.com (10.141.196.142) by CO2PR06MB457.namprd06.prod.outlook.com (10.141.196.142) with Microsoft SMTP Server (TLS) id 15.1.306.13; Tue, 3 Nov 2015 08:15:53 +0000 Received: from CO2PR06MB457.namprd06.prod.outlook.com ([10.141.196.142]) by CO2PR06MB457.namprd06.prod.outlook.com ([10.141.196.142]) with mapi id 15.01.0306.003; Tue, 3 Nov 2015 08:15:53 +0000 From: "Hodges, Jeff" To: Andrew Sullivan Thread-Topic: [dbound] on "control" Thread-Index: AQHRAf5cn0ypr4ybWEG9HaQsb/GfeJ5iA5gAgABlEQCAANb7AIAAE1mAgA+4CwCAFnoCAA== Date: Tue, 3 Nov 2015 08:15:52 +0000 Message-ID: References: <20151008195908.35761.qmail@ary.lan> <87k2qwyf57.fsf@alice.fifthhorseman.net> <20151009155933.GF20427@mx2.yitter.info> <20151019160210.GA43722@mx2.yitter.info> In-Reply-To: <20151019160210.GA43722@mx2.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jeff.hodges@paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.93.28.188] x-microsoft-exchange-diagnostics: 1; CO2PR06MB457; 5:1udhGjDeMg1rwpyurdmsik1sYyugD9w+VaWmPwxGpL05WWA/lB1mcGdjc7oJRdGIxPgMMYUHT8i4JXcB2OiNLgj/D4XyI8duuMuFOGwNtdQTocnpyXyYGc8hEYlIJHEGD8i+96OEyfCuo+64z8VETg==; 24:r992ahFMUuYerpbk1ivSgFXc0I0UQG7DBlEdocaB0QuAyKcCPmY6DpWfUIznYKS4Rmo9j49eg1Z4eTr45UK6weNASObMhR0f8ErJVQWlfI0=; 20:JLTBf9cP3WywG9NW/9BNq5N3go1KPixt5FcMMng1ux9chvP4Y6dq3bmdl9LjUxs0eUbdMhryE9dhqN8R9Y7ehQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR06MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:CO2PR06MB457; BCL:0; PCL:0; RULEID:; SRVR:CO2PR06MB457; x-forefront-prvs: 0749DC2CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(24454002)(479174004)(82432001)(10300500001)(10290500002)(73692002)(10400500002)(2950100001)(66066001)(2900100001)(10130500003)(92566002)(122556002)(16236675004)(77072002)(36756003)(40100003)(5004730100002)(10630500004)(19580405001)(11100500001)(10770500003)(19580395003)(87936001)(5002640100001)(5007970100001)(93886004)(50986999)(54356999)(5008740100001)(97736004)(76176999)(5001960100002)(106116001)(105586002)(106356001)(101416001)(4500500003)(81156007)(77096005)(99286002)(102836002)(189998001)(110136002)(86362001)(56826009)(10010500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR06MB457; H:CO2PR06MB457.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: paypal.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D25DAD353C59Djehodgespaypalcorpcom_" MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2015 08:15:52.7587 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR06MB457 X-CFilter: Scanned den1 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] on "control" X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 08:16:03 -0000 --_000_D25DAD353C59Djehodgespaypalcorpcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 10/19/15, 9:02 AM, "Andrew Sullivan" > wrote: On Fri, Oct 09, 2015 at 11:59:33AM -0400, Andrew Sullivan wrote: Therefore, I claim, the two cases collapse to one, because once you're in the mode of looking for some overriding ancestor policy (however you got into that mode), you're looking for the same thing. Does that make sense? yes, it does to me. =3DJeffH --_000_D25DAD353C59Djehodgespaypalcorpcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On 10/19/15, 9:02 AM, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:

On Fri, Oct 09, 2015 at 11:59:33AM -0400, Andrew Sullivan wrote:
Therefore, I claim, the two cases collapse to one, because once you're=
in the mode of looking for some overriding ancestor policy (however
you got into that mode), you're looking for the same thing.
Does that make sense?

yes, it does to me. 

=3DJeffH

--_000_D25DAD353C59Djehodgespaypalcorpcom_-- From nobody Tue Nov 3 01:18:42 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0201B30AA for ; Tue, 3 Nov 2015 01:18:40 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham 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 dJfxisQRogZq for ; Tue, 3 Nov 2015 01:18:38 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 0F07F1B30A7 for ; Tue, 3 Nov 2015 01:18:31 -0800 (PST) Received: by wmeg8 with SMTP id g8so79062665wme.0 for ; Tue, 03 Nov 2015 01:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla_org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=V9hhMs7Y8PPnwt6K/K+xczkK+BruxaXDkzAj0iG30UE=; b=NJtXoSRaK9xxMNv8lBwZ4vrxyMt5Zul014JNQGq+9Xo/V5jfB9cAlgMgsLTFr+Gwlc TK6TQHUBrN4Wy2OE7XGwVO15LklCZy9gszePvY/9FysQwvDbCHPoI0JVggD3EgrRtmQr LIHZrc8wdc9WFDLaPQIjcyLi5feBxPSM/WrmAoMMH9A5saFcNdQ4oPlI5wxA0g8s+AF5 JGJfr5+577xp5BnKzimnTG1OkAtOpsA5PsKrRVawTSPMkn7SHYjnRO/SDNhtve3hSvcR B4AP3yewjHLuEJhC2raDQNWzvUpbNKoDlzKrWE8XH/cgW7Q2KvBoDWerBc4F3n893VUs zKZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=V9hhMs7Y8PPnwt6K/K+xczkK+BruxaXDkzAj0iG30UE=; b=dW0fQkrWX0x4ZNFyWdkAKjcrvO2OzcS+i5TWLwXTQYu/Qw0FHoC5jxzP0xCloMgy33 r2T7NJz0OiNfTmaRslDSPctfE7cqXUxWKLouxzYRPFyc2y/fBrAmpTE3Whjq2ax0JAdS I/BhoBlPXo9ejiKmtD0fNmvMuP74LJp03jyiDlHyeInH7IBQtJebwJCCD5fm4iwdpl09 hGGbI/f3FZS0DY4HcKtWdFNdcXtaDC/rUsQQk5WcXW71fhzCo5QQ4vh1If4heeH+BSFJ Cm0SCGuanJh+HYmYWIZWcYBU71yoDbIkSJ/IpxB4PDAN/HnZDDiI0LGvSV5KK6Kl7jeX ce7Q== X-Gm-Message-State: ALoCoQnJSQFJVGCDQcRbhMy9yKE9LWlT95/TyMvJ0ZNyXnaHAUYVn19Gb1XfTVlbSVSLcMVAIR+S X-Received: by 10.28.52.12 with SMTP id b12mr17147148wma.16.1446542306706; Tue, 03 Nov 2015 01:18:26 -0800 (PST) Received: from [192.168.0.106] (fpc2-shef11-2-0-cust7.17-1.static.cable.virginm.net. [94.173.170.136]) by smtp.gmail.com with ESMTPSA id 79sm22302132wmf.13.2015.11.03.01.18.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 01:18:25 -0800 (PST) To: John R Levine , Jothan Frakes References: <20151102065541.44322.qmail@ary.lan> From: Gervase Markham Openpgp: id=EEDEEFF962E97696DACBD2CCD9B347EA9DF43DBB X-Enigmail-Draft-Status: N1110 Message-ID: <56387BE0.100@mozilla.org> Date: Tue, 3 Nov 2015 09:18:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 09:18:41 -0000 On 03/11/15 00:28, John R Levine wrote: > * - yes, I know it's in the PSL but that's due to the limits of the > current text format, not because it's actually public. Well, to be pedantic... it's more that we default to including new gTLDs. If Bloomberg got in touch and told us that this wasn't a public suffix, we could perhaps replace: bloomberg with !bloomberg Which would, I believe, according to the rules, encode the fact that bloomberg was not a public suffix. Not sure how PSL-using software would react to that, of course, as we've never had a rule like that before... :-) Gerv From nobody Tue Nov 3 01:27:51 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11D71B30A8 for ; Tue, 3 Nov 2015 01:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 79bG_Vo1y4rO for ; Tue, 3 Nov 2015 01:27:45 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03461B30D9 for ; Tue, 3 Nov 2015 01:27:44 -0800 (PST) Received: (qmail 76508 invoked from network); 3 Nov 2015 09:27:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=12adb.56387e10.k1511; bh=9pKzMVBMBy505L492X+c79TE8UIgBa4hbYELfqgjn0I=; b=jl3APwPFPluj8Z5scdjHfKrxZOXwzfHf2hQgO1jDONitKtoQaRsZj0X4VtASPbqSzCCVkLYXTDQH2X9Svp3BpJg7jkzZaB2uUnTGBpI0m4fydavl3px444yeaz+p6a6QH262l376c5E2hgyg24N8iNiGwvqzr28Y4ueftkOKbEiAjhPR/yyonMlxwnTnpwbxEHWKtC7zDSPhmnpfm+nMkqqFNm1+dOEhJkWhKe3ryI9bFOeOVZPAT94QN9DEkEBb DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=12adb.56387e10.k1511; bh=9pKzMVBMBy505L492X+c79TE8UIgBa4hbYELfqgjn0I=; b=gSM9/NjcL+qSsufxrieVGStvxcOps4AcTLEtG0bMP+fqZPBdA/L87tVYgKONt1qOea4N2h6eSitPsVTV95R46YiG1tplnyP+ucbxOywU3/5uO4kSIEg8H4JOZ87fpGs6dDCgX2NW+ODy+Rb275h9L2rh/qA1IjqQXsw+ugV/1Y5QHkd8xRaxFBWsIQb9iM3YJ0M+pAASNzfvkjdkbWmBUPCO4EDnnFEJL531dVIsOGuMMlygIZDo4GaQ83VNh7O9 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 03 Nov 2015 09:27:43 -0000 Date: 3 Nov 2015 18:27:40 +0900 Message-ID: From: "John R Levine" To: "Gervase Markham" In-Reply-To: <56387BE0.100@mozilla.org> References: <20151102065541.44322.qmail@ary.lan> <56387BE0.100@mozilla.org> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 09:27:46 -0000 > suffix, we could perhaps replace: > > bloomberg > with > !bloomberg Hmmn. For the new gTLDs, each application makes it clear who's going to accept registrations from other people and who's a closed vanity domain. For bloomberg, for example, it's here: https://gtldresult.icann.org/application-result/applicationstatus/applicationdetails/127 Section 18 of each application says who can register, in this case: Description of registration policies. BIP will initially register .bloomberg domain names for Bloomberg Philanthropies for the use of, or in connection with, charitable campaigns and advocacy on public issues. In the future, BIP may also register domain names for other Bloomberg entities for commercial use. In operating the .bloomberg gTLD, BIP will follow the policies and procedures required by the Registry Agreement. Registration of domain names in the .bloomberg gTLD will not be open to the public or non-Bloomberg affiliated companies. I realize looking at all of the applications is tedious, but it's quite mechanical. R's, John From nobody Tue Nov 3 01:38:10 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C371B3124 for ; Tue, 3 Nov 2015 01:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fMi91Ip0y0oj for ; Tue, 3 Nov 2015 01:38:07 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3371F1B3123 for ; Tue, 3 Nov 2015 01:38:07 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 3 Nov 2015 01:38:04 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Tue, 3 Nov 2015 01:38:05 -0800 From: Francisco Arias To: John R Levine , Gervase Markham Thread-Topic: [dbound] Proposed scope of work Thread-Index: AQHRFTubov8p4dfndEuOgID7zgE1Yp6I+i8AgAAB9QCAAGfQAIAAlLuAgACUJACAAAKXAIAAiO+A Date: Tue, 3 Nov 2015 09:38:04 +0000 Message-ID: References: <20151102065541.44322.qmail@ary.lan> <56387BE0.100@mozilla.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 09:38:08 -0000 TmV3IGdUTEQgYXBwbGljYXRpb25zIG1heSBub3QgbmVjZXNzYXJpbHkgcmVmbGVjdCB3aGF0IHVs dGltYXRlbHkgZ290DQppbXBsZW1lbnRlZC4gRm9yIHRoZSBkZWZpbml0aXZlIGFuc3dlciB0aGUg cmVnaXN0cnkgYWdyZWVtZW50IHBhZ2Ugb2YgZWFjaA0KVExEIHdvdWxkIGRvOg0KDQpodHRwczov L3d3dy5pY2Fubi5vcmcvcmVzb3VyY2VzL3BhZ2VzL3JlZ2lzdHJpZXMvcmVnaXN0cmllcy1hZ3Jl ZW1lbnRzLWVuDQoNClRob3NlIFRMRHMgdGhhdCBoYXZlIFNwZWNpZmljYXRpb24gMTMsIGUuZy4s DQpodHRwczovL3d3dy5pY2Fubi5vcmcvcmVzb3VyY2VzL2FncmVlbWVudC9ibG9vbWJlcmctMjAx NC0wNy0xNy1lbiBoYXMNCmh0dHBzOi8vd3d3LmljYW5uLm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVz L3RsZHMvYmxvb21iZXJnL2Jsb29tYmVyZy1zcGVjMTMtMQ0KN2p1bDE0LWVuLnBkZiBUaGVyZSBh cmUgYSBudW1iZXIgb2YgdGhlc2Ugc28gY2FsbGVkIOKAnGJyYW5kIFRMRHPigJ0uDQoNClBsZWFz ZSBsZXQgbWUga25vdyBpZiB0aGVyZSBpcyBpbnRlcmVzdCBpbiBoYXZpbmcgYSBtb3JlIGF1dG9t YXRhYmxlIHdheQ0KdG8gZGlzY292ZXIgdGhpcywgZS5nLiwgYnkgZXhwYW5kaW5nIGh0dHA6Ly9u ZXdndGxkcy5pY2Fubi5vcmcvbmV3Z3RsZHMuY3N2DQoNClJlZ2FyZHMsDQoNCi0tIA0KRnJhbmNp c2NvLg0KDQoNCg0KDQoNCg0KDQpPbiAxMS8zLzE1LCA2OjI3IFBNLCAiZGJvdW5kIG9uIGJlaGFs ZiBvZiBKb2huIFIgTGV2aW5lIg0KPGRib3VuZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBqb2hubEB0YXVnaC5jb20+IHdyb3RlOg0KDQo+PiBzdWZmaXgsIHdlIGNvdWxkIHBlcmhhcHMg cmVwbGFjZToNCj4+DQo+PiBibG9vbWJlcmcNCj4+IHdpdGgNCj4+ICFibG9vbWJlcmcNCj4NCj5I bW1uLiAgRm9yIHRoZSBuZXcgZ1RMRHMsIGVhY2ggYXBwbGljYXRpb24gbWFrZXMgaXQgY2xlYXIg d2hvJ3MgZ29pbmcgdG8NCj5hY2NlcHQgcmVnaXN0cmF0aW9ucyBmcm9tIG90aGVyIHBlb3BsZSBh bmQgd2hvJ3MgYSBjbG9zZWQgdmFuaXR5IGRvbWFpbi4NCj4NCj5Gb3IgYmxvb21iZXJnLCBmb3Ig ZXhhbXBsZSwgaXQncyBoZXJlOg0KPg0KPmh0dHBzOi8vZ3RsZHJlc3VsdC5pY2Fubi5vcmcvYXBw bGljYXRpb24tcmVzdWx0L2FwcGxpY2F0aW9uc3RhdHVzL2FwcGxpY2F0DQo+aW9uZGV0YWlscy8x MjcNCj4NCj5TZWN0aW9uIDE4IG9mIGVhY2ggYXBwbGljYXRpb24gc2F5cyB3aG8gY2FuIHJlZ2lz dGVyLCBpbiB0aGlzIGNhc2U6DQo+DQo+ICBEZXNjcmlwdGlvbiBvZiByZWdpc3RyYXRpb24gcG9s aWNpZXMuICBCSVAgd2lsbCBpbml0aWFsbHkgcmVnaXN0ZXINCj4gIC5ibG9vbWJlcmcgZG9tYWlu IG5hbWVzIGZvciBCbG9vbWJlcmcgUGhpbGFudGhyb3BpZXMgZm9yIHRoZSB1c2Ugb2YsIG9yDQo+ ICBpbiBjb25uZWN0aW9uIHdpdGgsIGNoYXJpdGFibGUgY2FtcGFpZ25zIGFuZCBhZHZvY2FjeSBv biBwdWJsaWMgaXNzdWVzLg0KPiAgSW4gdGhlIGZ1dHVyZSwgQklQIG1heSBhbHNvIHJlZ2lzdGVy IGRvbWFpbiBuYW1lcyBmb3Igb3RoZXIgQmxvb21iZXJnDQo+ICBlbnRpdGllcyBmb3IgY29tbWVy Y2lhbCB1c2UuICBJbiBvcGVyYXRpbmcgdGhlIC5ibG9vbWJlcmcgZ1RMRCwgQklQIHdpbGwNCj4g IGZvbGxvdyB0aGUgcG9saWNpZXMgYW5kIHByb2NlZHVyZXMgcmVxdWlyZWQgYnkgdGhlIFJlZ2lz dHJ5IEFncmVlbWVudC4NCj4gIFJlZ2lzdHJhdGlvbiBvZiBkb21haW4gbmFtZXMgaW4gdGhlIC5i bG9vbWJlcmcgZ1RMRCB3aWxsIG5vdCBiZSBvcGVuIHRvDQo+ICB0aGUgcHVibGljIG9yIG5vbi1C bG9vbWJlcmcgYWZmaWxpYXRlZCBjb21wYW5pZXMuDQo+DQo+SSByZWFsaXplIGxvb2tpbmcgYXQg YWxsIG9mIHRoZSBhcHBsaWNhdGlvbnMgaXMgdGVkaW91cywgYnV0IGl0J3MgcXVpdGUNCj5tZWNo YW5pY2FsLg0KPg0KPlIncywNCj5Kb2huDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5kYm91bmQgbWFpbGluZyBsaXN0DQo+ZGJvdW5kQGlldGYu b3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYm91bmQNCg0K From nobody Tue Nov 3 02:14:33 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463991B318E for ; Tue, 3 Nov 2015 02:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.238 X-Spam-Level: X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 cW3YWWN7wgZh for ; Tue, 3 Nov 2015 02:14:31 -0800 (PST) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) (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 C1CAB1B318A for ; Tue, 3 Nov 2015 02:14:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 0513914968F; Tue, 3 Nov 2015 08:14:26 -0200 (BRST) X-Virus-Scanned: Debian amavisd-new at mail.nic.br Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0Prktv9R3CS; Tue, 3 Nov 2015 08:14:24 -0200 (BRST) Received: from [192.168.1.35] (unknown [191.255.66.166]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 4F2EA149416; Tue, 3 Nov 2015 08:14:24 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1446545664; bh=61EctIZZwWEgFxhMUW1wu93wToQ3DYLQcHayiHbnm2U=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=kv/QoErTeER92X6sUfK1Jt+mj+i/5kfh6DjLnsahX0JU8Kt+ZTwDnnNBGr4XyMtNk MlUhkJacRnmeRrlbD++Lodqx4xJ9B0sH+M5L33F7xkdSp2amoADLfXyPnBkrxenBbZ jYiwr7f7GCM+nXrQzrbz+EOUF5VPLJGMafbN4jZs= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Rubens Kuhl In-Reply-To: Date: Tue, 3 Nov 2015 08:14:22 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54169816-FA78-463C-A9CA-2049FBA170D1@nic.br> References: <20151102065541.44322.qmail@ary.lan> <56387BE0.100@mozilla.org> To: Francisco Arias X-Mailer: Apple Mail (2.2104) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br 4F2EA149416 Archived-At: Cc: Gervase Markham , John R Levine , "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 10:14:32 -0000 The actual logic would be something like - Has Spec 9 exemption but no Spec 13 -> Single use TLD - Has both Spec 9 exemption and Spec 13 clauses -> Brand TLD That might be useful to differentiate.=20 Rubens > On Nov 3, 2015, at 7:38 AM, Francisco Arias = wrote: >=20 > New gTLD applications may not necessarily reflect what ultimately got > implemented. For the definitive answer the registry agreement page of = each > TLD would do: >=20 > = https://www.icann.org/resources/pages/registries/registries-agreements-en >=20 > Those TLDs that have Specification 13, e.g., > https://www.icann.org/resources/agreement/bloomberg-2014-07-17-en has > = https://www.icann.org/sites/default/files/tlds/bloomberg/bloomberg-spec13-= 1 > 7jul14-en.pdf There are a number of these so called =E2=80=9Cbrand = TLDs=E2=80=9D. >=20 > Please let me know if there is interest in having a more automatable = way > to discover this, e.g., by expanding = http://newgtlds.icann.org/newgtlds.csv >=20 > Regards, >=20 > --=20 > Francisco. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 11/3/15, 6:27 PM, "dbound on behalf of John R Levine" > wrote: >=20 >>> suffix, we could perhaps replace: >>>=20 >>> bloomberg >>> with >>> !bloomberg >>=20 >> Hmmn. For the new gTLDs, each application makes it clear who's going = to >> accept registrations from other people and who's a closed vanity = domain. >>=20 >> For bloomberg, for example, it's here: >>=20 >> = https://gtldresult.icann.org/application-result/applicationstatus/applicat= >> iondetails/127 >>=20 >> Section 18 of each application says who can register, in this case: >>=20 >> Description of registration policies. BIP will initially register >> .bloomberg domain names for Bloomberg Philanthropies for the use of, = or >> in connection with, charitable campaigns and advocacy on public = issues. >> In the future, BIP may also register domain names for other Bloomberg >> entities for commercial use. In operating the .bloomberg gTLD, BIP = will >> follow the policies and procedures required by the Registry = Agreement. >> Registration of domain names in the .bloomberg gTLD will not be open = to >> the public or non-Bloomberg affiliated companies. >>=20 >> I realize looking at all of the applications is tedious, but it's = quite >> mechanical. >>=20 >> R's, >> John >>=20 >> _______________________________________________ >> dbound mailing list >> dbound@ietf.org >> https://www.ietf.org/mailman/listinfo/dbound >=20 > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound From nobody Tue Nov 3 03:20:30 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFEE1B322B for ; Tue, 3 Nov 2015 03:20:28 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham 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 1Fxuim-UFKYQ for ; Tue, 3 Nov 2015 03:20:24 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 D7BD11ACD85 for ; Tue, 3 Nov 2015 03:20:23 -0800 (PST) Received: by wmeg8 with SMTP id g8so11908384wme.1 for ; Tue, 03 Nov 2015 03:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla_org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=I/ajiCJqGJdQz2zpKf88xwOxM+pPmJBuWiGIe5Mc6fM=; b=ZnIpTDRWEL2r4U5QpGnl8ky56LVywG9jBex2sG9w7M8WvYJu+uEI/CHZjzj47wgqw/ h9vaQpRPmfSIfnaKY+WWHmnIVNAw0mO5Rq81fczUW93w+F9j0MusqFNgHszdcjnoO7RF v8ktgIw149AIk123OKSwj8NukF23SCJ9+QymC/NVYXUnsUuFi8lZbl0kAQELg/ovZ45l zGF3IfjJbGH6ahhyuT8s48oZ9eTjP5jsR5tmR4T9oKRjFWAdSt2tuJ4/tSt+zcCe/wZt tA746Sm1lOV7+PcX4DBIfggfCFp1XLYEeRyOuqhXN15OpegYkDYCsKoonWX11X8ghvLe DyGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=I/ajiCJqGJdQz2zpKf88xwOxM+pPmJBuWiGIe5Mc6fM=; b=dyUa+G7q3n9tXPpf8tiR0YJ2x4Er1hTyMvhFDimC0e7m7w5rPrNTk9JcoXX/z7G9or WpNy9RH6Iad7EoBqkg3E0CKgcTdt2y9IPV/JDEpM+IimGyljEEv32RLBg02xWIPHN3up yqqopzLgkzhZCpGm2f7XzB3BMCOl1lxiOqnONqBsLDsi2Ib90SJqkEBWid8aHRGgwNbm v2ytli7AyiBKQ2e63UyjsmJwCXkNYLV9mQMq1xZz+7TwTUNliW24umUdeQHJ8Y4qvoUE 6sOe2cRvOXIH6o4jKoY08P9P4x2C2Jq89Y7pcCUo2KSkCfAOHPF/c7q2Wke0GZGpC79X jh9Q== X-Gm-Message-State: ALoCoQn0Xc/2jIPUOSvKbuUd/MuIKtGD848trD4imZ0PFaZi3eAOOPnW21FfXTb5OJgPugnDV5TK X-Received: by 10.28.170.196 with SMTP id t187mr20556184wme.1.1446549622323; Tue, 03 Nov 2015 03:20:22 -0800 (PST) Received: from [192.168.0.106] (fpc2-shef11-2-0-cust7.17-1.static.cable.virginm.net. [94.173.170.136]) by smtp.gmail.com with ESMTPSA id c67sm22790400wmh.11.2015.11.03.03.20.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 03:20:21 -0800 (PST) To: Francisco Arias , John R Levine References: <20151102065541.44322.qmail@ary.lan> <56387BE0.100@mozilla.org> From: Gervase Markham Openpgp: id=EEDEEFF962E97696DACBD2CCD9B347EA9DF43DBB Message-ID: <56389874.8040601@mozilla.org> Date: Tue, 3 Nov 2015 11:20:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 11:20:28 -0000 On 03/11/15 09:38, Francisco Arias wrote: > Please let me know if there is interest in having a more automatable way > to discover this, e.g., by expanding http://newgtlds.icann.org/newgtlds.csv That would be definitely useful, yes. We'd have to have a discussion about how to use the information, but having it provided by ICANN would be a great start. Gerv From nobody Tue Nov 3 04:02:06 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33491B3296 for ; Tue, 3 Nov 2015 04:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 TrwqIHuofSVD for ; Tue, 3 Nov 2015 04:02:03 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 086E71A8700 for ; Tue, 3 Nov 2015 04:02:03 -0800 (PST) Received: by iody8 with SMTP id y8so15942194iod.1 for ; Tue, 03 Nov 2015 04:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=srbDY6EOUb4NLEFIjxoEiIdx23F9kMcuJ+WpJHqOVo8=; b=Vmx/ChAneiLobdx0prrDIQPWnqBuCGIzH6nq4rjOjnZTQOmSnV13cYvDFa7i9WgKn/ 8yr7DMx9KLHCJIOjTEtLUhqGInJq0MMw958nZw17+tVdeP+KjqqKkNJYGXazUiEyQj3q 9NSWPE8S8FF1FaWLn4bejFKpQbgmAX78aRiuY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=srbDY6EOUb4NLEFIjxoEiIdx23F9kMcuJ+WpJHqOVo8=; b=KIkTNdGzz+SZGJW8eec2YHsLQ7skDYrTQscaft17sVEudcdc6WurKFLR4X9fiXc46+ A7vaP+rOk1uhWz0HRbpFYWA6AxIhcNRsjCxkdlHMzuVL+1rQDFMYNJO0SdTOQvJF7EDE U7etA+9AGeu1mpQa1PeZsQMp0rKZCmgdVGDJB4stLNU3DoP92ZDBJ/M0CSaIp4ClN2oh b3UCm3t9HoYmrnnJiVeiaYZtWEBsxaEFpfsGX8ii40Bv5LUhavoCoi0+b99sPCwNvKkx ZaicUJhPe3fc8Ppjg1C4h3DCiC0xSUir5xzVlKjE9bzic9DUmeiAQ0ZT56BGR56bjE1H L85g== X-Gm-Message-State: ALoCoQmDZWHQ4wgWr4IqK0wfOeftg14anBc08mljZ/yk2pSloW52MSwKJPiSENGKcQqYkMw6xkOD MIME-Version: 1.0 X-Received: by 10.107.19.219 with SMTP id 88mr31857054iot.41.1446552122328; Tue, 03 Nov 2015 04:02:02 -0800 (PST) Received: by 10.50.202.71 with HTTP; Tue, 3 Nov 2015 04:02:02 -0800 (PST) Date: Tue, 3 Nov 2015 07:02:02 -0500 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=001a113f94be669c5e0523a1a9fb Archived-At: Subject: [dbound] ODUP - some clarifications X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 12:02:06 -0000 --001a113f94be669c5e0523a1a9fb Content-Type: text/plain; charset=UTF-8 I appreciate the feedback I received about my draft in tonight's dbound working group meeting. It was clear that clarification was necessary in some places, which can be brought into the draft, but which I also present here. 1. Examples - Examples on the ODUP resolution process are lacking. There were several comments that indicated that the process was not understood. This really isn't a guessing game. The algorithm is laid out in completeness in the appendix (more formally than it is in the step-by-step), but really some examples would be helpful to demonstrate this. Some are provided in this email, in the context of other questions, but certainly more will be added to the draft. Also, there is nearly running code, in addition to the pseudo code written into the draft), which I'll make available for further illustration and example. -------------- 2. Performance - The performance is _not_ O(n**2) as was mentioned in the meeting. It is order O(n). That's quite a difference :). To illustrate, we take the name a.b.c. Here are the _worst-case_ resolution paths: c._odup/TXT (NODATA) b.c._odup/TXT (NODATA) a.b.c._odup/TXT (NXDOMAIN or NODATA) _odup/TXT OR c._odup/TXT (+org) b._odup.c/TXT (NODATA) a.b._odup.c/TXT (NXDOMAIN or NODATA) _odup.c/TXT OR c._odup/TXT (+org) b._odup.c/TXT (+org) a._odup.b.c/TXT (NXDOMAIN or NODATA) _odup.b.c OR c._odup/TXT (NODATA) b.c._odup/TXT (+org) a._odup.b.c/TXT (NXDOMAIN or NODATA) _odup.b.c/TXT So, worst case is n + 1 lookups, or O(n). I don't know that the performance is any different than that of qname minimization. But if you replace any of the NODATA (only) responses with NXDOMAIN, steps are skipped, resulting in fewer lookups. Also, let's assume the client has a local copy of the policy-negative realm (_odup zone). It already knows the answer to any of the above lookups whose names end with "_odup", so it starts from a lower point in the resolution process, thus eliminating more lookups. Now assume both a local copy and a "blank slate" (i.e., no one has deployed any ODUP records outside of the _odup zone). There are two lookups required in the worst case scenario, regardless of name length. For example, assume the policy is delegated to the b.c zone with either: b.c._odup "+org" OR c._odup "+bound" (and b.c._odup doesn't exist in the negative policy realm) The worst-case lookup scenario to find the policy for a.b.c is: a._odup.b.c/TXT (NXDOMAIN or NODATA) _odup.b.c/TXT and the worst case to find the policy for b.c is simply: _odup.b.c/TXT -------------- 3. There was a question about how names (particularly TLDs) with DNAMEs at the zone apex are affected by this mechanism. I don't know that there is any impact at all; it should work as designed. For example, given the TLD foo, with a DNAME to bar, and a lookup for a.foo: foo._odup/TXT (NODATA) a.foo._odup/TXT (NXDOMAIN or NODATA) _odup/TXT OR foo._odup/TXT (+org) a._odup.foo/TXT CNAME (synthesized) to a._odup.bar/TXT (NXDOMAIN or NODATA) _odup.foo/TXT CNAME (synthesized) to _odup.foo/TXT -------------- 4. _odup TLD? Yes, that is what is proposed. Note that both by name and by definition, this is only a policy-negative realm. That means that policy directives other than "bound", "org" (lacking from -00 draft, but necessary for exceptions to wildcards), and "-all" MUST NOT be used in the policy-negative realm (see Section 5 for more detail). Technically speaking, there are no concerns here. It works. There are some non-technical questions that might be asked, some of which were alluded to in the meeting (and I'm sure there will be others): Q: If there is an _odup TLD, and there is policy under that TLD, how is that different than having a third party manage policy? A: I suppose the same question might be asked of traditional DNS namespace delegation: if I have a domain example.com, why do I need the root or com? The primary answer are the same to both: how do you know how to get there without a starting place? Just as with other TLDs, which are mostly about delegation, this "TLD" is all about delegating policy--not (otherwise) defining it. Q: Why should a third party manage it? A: It's no different than current behavior (with the possible exception of *who*, but that's another question), in which Mozilla maintains the PSL. The difference is that with the ODUP policy-negative realm, there's an option to delegate policy definition to a subdomain (i.e., using "bound" or "org"), thereby moving "the line" upward. Also, see a later question about its management. If IANA has a hand in it, then it's more a "parent party" than a "third party". They are depended on anyway for DNS resolution. Q: Who would manage it? A: The proposal is that this would be managed by IANA, with joint help from CA/Browser Forum. The idea was have authority and expertise both in conjunction with names directly associated with IANA, as well as consumer applications, such as browsers. This might also provide better continuity with transition from the current PSL since Mozilla is the current maintainer of that list. It also helps mitigate the issue in which non-negative policies (e.g., allowing cookies at a TLD) are instituted at points in the namespace where they should not be (e.g., due to IANA contract). Other ideas are welcome. Q: What about the names in the "Private domains" section of the PSL? A: There are two major sections in the current PSL: "ICANN domains" and "Private domains". The _odup zone would initially be composed of the so-called "ICANN domains" in the PSL. Those classified as "Private" are prime candidates of those that would publish ODUP policy in their own organizational domain. For example, the policy for ap-northeast-1.compute.amazonaws.com (a "private" entry in the current PSL) might be under _odup.amazonaws.com or _odup.compute.amazon.aws.com. If you haven't read the draft in its entirety, I invite you to please read it (or finish it) and comment. Cheers, Casey --001a113f94be669c5e0523a1a9fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I appreciate the feedback I received about my draft in ton= ight's dbound working group meeting.=C2=A0 It was clear that clarificat= ion was necessary in some places, which can be brought into the draft, but = which I also present here.

1.=C2=A0 Examples - Examples = on the ODUP resolution process are lacking.=C2=A0 There were several commen= ts that indicated that the process was not understood.=C2=A0 This really is= n't a guessing game.=C2=A0 The algorithm is laid out in completeness in= the appendix (more formally than it is in the step-by-step), but really so= me examples would be helpful to demonstrate this.=C2=A0 Some are provided i= n this email, in the context of other questions, but certainly more will be= added to the draft.

Also, there is nearly running= code, in addition to the pseudo code written into the draft), which I'= ll make available for further illustration and example.

--------------

2. Performance - The performanc= e is _not_ O(n**2) as was mentioned in the meeting.=C2=A0 It is order O(n).= =C2=A0 That's quite a difference :).=C2=A0 To illustrate, we take the n= ame a.b.c.=C2=A0 Here are the _worst-case_ resolution paths:

c._odup/TXT (NODATA)
b.c._odup/TXT (NODATA)
a.b.c._odup/TXT (NXDOMAIN or NODATA)
_odup/TXT
OR

c._odup/TXT (+org)
b= ._odup.c/TXT (NODATA)
a.b._odup.c/TXT (NXDOMAIN or NODATA)
<= div>_odup.c/TXT

OR

c._odu= p/TXT (+org)
b._odup.c/TXT (+org)
a._odup.b.c/TXT (NXDO= MAIN or NODATA)
_odup.b.c

OR
<= br>
c._odup/TXT (NODATA)
b.c._odup/TXT (+org)
a._odup.b.c/TXT (NXDOMAIN or NODATA)
_odup.b.c/TXT
So, worst case is n + 1 lookups, or O(n).=C2=A0 I don't kno= w that the performance is any different than that of qname minimization.

But if you replace any of the NODATA (only) response= s with NXDOMAIN, steps are skipped, resulting in fewer lookups.
<= br>
Also, let's assume the client has a local copy of the pol= icy-negative realm (_odup zone).=C2=A0 It already knows the answer to any o= f the above lookups whose names end with "_odup", so it starts fr= om a lower point in the resolution process, thus eliminating more lookups.<= /div>

Now assume both a local copy and a "blank sla= te" (i.e., no one has deployed any ODUP records outside of the _odup z= one).=C2=A0 There are two lookups required in the worst case scenario, rega= rdless of name length.=C2=A0 For example, assume the policy is delegated to= the b.c zone with either:

b.c._odup "+org&qu= ot;

OR

c._odup "+bou= nd"
(and b.c._odup doesn't exist in the negative policy = realm)

The worst-case lookup scenario to find the = policy for a.b.c is:

a._odup.b.c/TXT (NXDOMAIN or = NODATA)
_odup.b.c/TXT

and the worst case= to find the policy for b.c is simply:

_odup.= b.c/TXT

--------------

<= div>3. There was a question about how names (particularly TLDs) with DNAMEs= at the zone apex are affected by this mechanism.=C2=A0 I don't know th= at there is any impact at all; it should work as designed.=C2=A0 For exampl= e, given the TLD foo, with a DNAME to bar, and a lookup for a.foo:

foo._odup/TXT (NODATA)
a.foo._odup/TXT (NXD= OMAIN or NODATA)
_odup/TXT

OR
<= div>
foo._odup/TXT (+org)
a._odup.foo/TXT CNAME= (synthesized) to=C2=A0
=C2=A0 =C2=A0 a._odup.bar/TXT (NXDOMAIN o= r NODATA)
_odup.foo/TXT CNAME (synthesized) to=C2=A0
= =C2=A0 =C2=A0 _odup.foo/TXT

-----------= ---

4. _odup TLD?=C2=A0 Yes, that is what is= proposed.=C2=A0 Note that both by name and by definition, this is only a p= olicy-negative realm.=C2=A0 That means that policy directives other than=C2= =A0"bound", = "org" (lacking from -00 draft, but necessary for exceptions to wi= ldcards), and "-all" MUST NOT be used in=C2=A0the policy-negative realm (see Sec= tion 5 for more detail).=C2=A0 Technically speaking, there are no concerns = here.=C2=A0 It works.

There are some non-te= chnical questions that might be asked, some of which were alluded to in the= meeting (and I'm sure there will be others):

= Q: If there is an _odup TLD, and there is policy under that TLD, how is tha= t different than having a third party manage policy?

A: I suppose the same question might be asked of traditional DNS namespa= ce delegation: if I have a domain example.co= m, why do I need the root or com?=C2=A0 The primary answer are the same= to both: how do you know how to get there without a starting place?=C2=A0 = Just as with other TLDs, which are mostly about delegation, this "TLD&= quot; is all about delegating policy--not (otherwise) defining it.

Q: Why should a third party manage it?

A: It's no different than current behavior (with the possible exc= eption of *who*, but that's another question), in which Mozilla maintai= ns the PSL.=C2=A0 The difference is that with the ODUP policy-negative real= m, there's an option to delegate policy definition to a subdomain (i.e.= , using "bound" or "org"), thereby moving "the lin= e" upward.=C2=A0 Also, see a later question about its management.=C2= =A0 If IANA has a hand in it, then it's more a "parent party"= than a "third party".=C2=A0 They are depended on anyway for DNS = resolution.

Q: Who would manage it?

=
A: The proposal is that this would be managed by IANA, with join= t help from CA/Browser Forum.=C2=A0 The idea was have authority and experti= se both in conjunction with names directly associated with IANA, as well as= consumer applications, such as browsers.=C2=A0 This might also provide bet= ter continuity with transition from the current PSL since Mozilla is the cu= rrent maintainer of that list.=C2=A0 It also helps mitigate the issue in wh= ich non-negative policies (e.g., allowing cookies at a TLD) are instituted = at points in the namespace where they should not be (e.g., due to IANA cont= ract).=C2=A0 Other ideas are welcome.

Q: What abou= t the names in the "Private domains" section of the PSL?

A: There are two major sections in the current PSL: "= ICANN domains" and "Private domains".=C2=A0 The _odup zone w= ould initially be composed of the so-called "ICANN domains" in th= e PSL.=C2=A0 Those classified as "Private" are prime candidates o= f those that would publish ODUP policy in their own organizational domain.= =C2=A0 For example, the policy for=C2=A0= ap-northeast-1.compute.amazonaws.com (a "private" entry in th= e current PSL) might be under _odup.a= mazonaws.com or _odup.co= mpute.amazon.aws.com.

If you haven'= t read the draft in its entirety, I invite you to please read it (or finish= it) and comment.

Cheers,
Casey

--001a113f94be669c5e0523a1a9fb-- From nobody Tue Nov 3 14:17:49 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4C1B2B01 for ; Tue, 3 Nov 2015 14:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 9HjsCwRTz3_c for ; Tue, 3 Nov 2015 14:17:45 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A51C1B2AFF for ; Tue, 3 Nov 2015 14:17:45 -0800 (PST) Received: by lfbf136 with SMTP id f136so32108476lfb.0 for ; Tue, 03 Nov 2015 14:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jothan_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZSYyDrPOrKMrZUW4QAHQDHpFMBweygHTbKKITWxKlqw=; b=SPknvQHnvCPvBFT5LvYahSFkwosyjpi+PNSyghR3tgdo6qc7punuWInR+urtt2VRZf Mn6AMS36cN5hF8HQBYBxoCVuxz+lwEHcz3QGoUSWHBo8yUM+qJPqUicdrchVo1lUeG3m IHh+ae5ouIafJP8MIeu3ERM1VK/rfxA5CpwUWUD3V5NLXDzVL8ku4vdhIsMLHVueNE+4 oS9PD3cZq6HZ20qt0sL7CYFUHCgvC00Pep96/2XkJE2RZPJk2rzvudPw0b8TMyZtBOm7 p6ls3PEy1i1HXbRlBWSCU4pk6fvx0q0KM5Uyuc9k4KQZaWcPuiB/+o392Z/OG2nxXfQp K3mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZSYyDrPOrKMrZUW4QAHQDHpFMBweygHTbKKITWxKlqw=; b=YUTKsglf49mHRCDBPG4L/zwXi+fYB7j4SaLKi4/PzTN2zxl8tM61tPkFja/fLOmBIl ckD0kzeZr0jmfpM/8z4zQPFiPJadFuyFHFG+yrZBGmcTrVL2GdikX6D4HE3X4Yh3ohYV FriyRqm+FIExdmaJxUc12t5bBPByTfRkhNTdHvzf+ZoxiQS6nAeMqVKK7aqsi0Y2Xjy8 8CuEC8VY9XgjJwKLNodT8AQEupXiDs/7sMuBb6ehWEmhPLYtFvaLE4mBzBDQLBkM35Wl C5QhJPPjkb9REqdCOcXnn8KJ1/hBH+0hG6PllUg/WR6LEaVzH9vOgHRGc0rj2cCxevl8 No2Q== X-Gm-Message-State: ALoCoQk17RT/LR1xLhcc5lKETkGXUVHaRtJUchc9PSTV4DxSwKNURWWpPM4KSvCBEaPTMZGv+d3G X-Received: by 10.25.79.14 with SMTP id d14mr9526159lfb.40.1446589063458; Tue, 03 Nov 2015 14:17:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.140.3 with HTTP; Tue, 3 Nov 2015 14:17:14 -0800 (PST) In-Reply-To: <56389874.8040601@mozilla.org> References: <20151102065541.44322.qmail@ary.lan> <56387BE0.100@mozilla.org> <56389874.8040601@mozilla.org> From: Jothan Frakes Date: Tue, 3 Nov 2015 14:17:14 -0800 Message-ID: To: Gervase Markham Content-Type: multipart/alternative; boundary=001a1141ef5a438b970523aa4371 Archived-At: Cc: Francisco Arias , John R Levine , "dbound@ietf.org" Subject: Re: [dbound] Proposed scope of work X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 22:17:47 -0000 --001a1141ef5a438b970523aa4371 Content-Type: text/plain; charset=UTF-8 The default behavior of inclusion was created to accommodate the thundering herd of new additions in a volunteer-only maintained list to keep it lightweight with respect to level of effort - so that different integrators, application developers, software libraries, etc, could have some awareness of the TLD additions. For the interest of not falling into the trap of where the definitions of public / private seem to confuse things, the concept of public/private has two connotations in this discussion. First is placement within the Mozilla PSL - where there is a section defining ICANN/IANA root down additions vs. self-identified strings that have some cookie or other behavior that is TLD-esque where the operator requested addition. Second is where an entry is asserting an explicit non-public behavior (ie !bloomberg) @Francisco In the case of the second of these - there will be a need to communicate with those registries to update their entries to suit their specific desired behaviour with respect to cookies with the PSL. Derivative users/integrators/security firms/developers that use the Mozilla PSL for 'is that a valid TLD or not' logic will want names included, and the overall Universal Acceptance benefit will remain regardless of if they update their entry to be explicitly non-public. Jothan Frakes Tel: +1.206-355-0230 On Tue, Nov 3, 2015 at 3:20 AM, Gervase Markham wrote: > On 03/11/15 09:38, Francisco Arias wrote: > > Please let me know if there is interest in having a more automatable way > > to discover this, e.g., by expanding > http://newgtlds.icann.org/newgtlds.csv > > That would be definitely useful, yes. We'd have to have a discussion > about how to use the information, but having it provided by ICANN would > be a great start. > > Gerv > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > --001a1141ef5a438b970523aa4371 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The default behavior of inclusion was created to accommoda= te the thundering herd of new additions in a volunteer-only maintained list= to keep it lightweight with respect to level of effort - so that different= integrators, application developers, software libraries, etc, could have s= ome awareness of the TLD additions.

For the interest of not falling = into the trap of where the definitions of public / private seem to confuse = things, the concept of public/private has two connotations in this discussi= on. =C2=A0 =C2=A0

First is placement within the Mozilla PSL - where = there is a section defining ICANN/IANA root down additions vs. self-identif= ied strings that have some cookie or other behavior that is TLD-esque where= the operator requested addition.

Second is where an entry is assert= ing an explicit non-public behavior (ie !bloomberg)

@Francisco In th= e case of the second of these - there will be a need to communicate with th= ose registries to update their entries to suit their specific desired behav= iour with respect to cookies with the PSL.

Derivative users/integrat= ors/security firms/developers that use the Mozilla PSL for 'is that a v= alid TLD or not' logic will want names included, and the overall Univer= sal Acceptance benefit will remain regardless of if they update their entry= to be explicitly non-public.


Jothan Frakes=
Tel: +1.206-355-0230


On Tue, Nov 3, 2015 at 3:20 AM, Gervase Mark= ham <gerv@mozilla.org> wrote:
On 03/11/15 09:38, Francisco Arias wrote:
> Please let me know if there is interest in having a more automatable w= ay
> to discover this, e.g., by expanding http://newgtlds.ican= n.org/newgtlds.csv

That would be definitely useful, yes. We'd have to have a discus= sion
about how to use the information, but having it provided by ICANN would
be a great start.

Gerv

_______________________________________________
dbound mailing list
dbound@ietf.org
https://www.ietf.org/mailman/listinfo/dbound

--001a1141ef5a438b970523aa4371-- From nobody Sat Nov 7 08:37:49 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60ACE1A9172 for ; Sat, 7 Nov 2015 08:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 socX3B0YViUf for ; Sat, 7 Nov 2015 08:37:46 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 E62B21A9176 for ; Sat, 7 Nov 2015 08:37:45 -0800 (PST) Received: by qgeb1 with SMTP id b1so60477345qge.1 for ; Sat, 07 Nov 2015 08:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=qRH4MsUmZpVPsaib3MEJIvGGQS/UVmO/RXFaX813+Cw=; b=WPA/Gz/TyCC3SwuKnhRebl7h4syAavcKGV1+/XK7/+PZALkF5geQhY5ZkZ5PIIiVC2 BSIeAUklmIABDngblDCS5+MD6a+bDHDxSO0iAb4Q4MYJcjLE+cTittsOJ8UUVPq11iBa x09jeqR/YDrECpVIXeHleX3vfXGwRrwEjV2JU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=qRH4MsUmZpVPsaib3MEJIvGGQS/UVmO/RXFaX813+Cw=; b=gSLXc+sJtwYOEF80cf5wEeIJ2I+e4+9wym9IeIbREoBuTwufIVOThUfEgQ2jb+so7x e5BrbhQSzbp6iSHPsbU2lcCMG1BJBg21yHWQtqL9zxduo1xHfccEqbdViZkKgdqCLBIJ R5S0uzurtDmccsIs2HotqQPZ4CRoOPSDAwU0LgUzo3Bi43gVwgmKjafbv4Edy7oq6iSd KZD921HupIpazofJ3jAnLmMOWnGNWVqSIQMflnXx1pGXyBGMicjlhYgy+E0bmOStlULx ntl9WmG3L+70R4TSJJ9Mr3iRWDSl+N7pHRJYDslVI2/cnJjeYH/9DGOPfAKCOv4GlMej y1yg== X-Gm-Message-State: ALoCoQlGgkQX1wjxG/AVitaeTM6N7VBItMWuNiOm/2RhbwBkRXtu99LkB0ADUcDe8MSPqK/4pyGU MIME-Version: 1.0 X-Received: by 10.140.169.5 with SMTP id p5mr8572800qhp.78.1446914264926; Sat, 07 Nov 2015 08:37:44 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.198.219 with HTTP; Sat, 7 Nov 2015 08:37:44 -0800 (PST) Date: Sat, 7 Nov 2015 08:37:44 -0800 X-Google-Sender-Auth: O90_elNK9rshgUhrf4xFCfL0Puk Message-ID: From: "Kurt Andersen (b)" To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=001a113b39cac82a950523f5fafc Archived-At: Subject: [dbound] Questions about the _odup algorithm X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 16:37:47 -0000 --001a113b39cac82a950523f5fafc Content-Type: text/plain; charset=UTF-8 Citing a pastebin copy of Appendix A (for line numbering): http://pastebin.com/iYziF5LW Perhaps it is a syntax misunderstanding, but it looks to me like line 44 ends up setting subDomainLabels to -1 and from there I'm a bit lost. It might be because of the mix of ordering in the label arrays (8..3) is throwing me a bit off (usually handle arrays from min..max). Can you clarify? Thanks, Kurt Andersen --001a113b39cac82a950523f5fafc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Citing a pastebin copy of Appendix A (= for line numbering): http://pasteb= in.com/iYziF5LW

Perhaps it is a syntax misunderstanding, b= ut it looks to me like line 44 ends up setting subDomainLabels to -1 and fr= om there I'm a bit lost. It might be because of the mix of ordering in = the label arrays (8..3) is throwing me a bit off (usually handle arrays fro= m min..max).

Can you clarify?

Thanks,
= =C2=A0 Kurt Andersen
--001a113b39cac82a950523f5fafc-- From nobody Sat Nov 7 09:03:57 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066B61B2DE0 for ; Sat, 7 Nov 2015 09:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=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 agk5GA9AXJjD for ; Sat, 7 Nov 2015 09:03:48 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 658D21ACE50 for ; Sat, 7 Nov 2015 09:03:48 -0800 (PST) Received: by ioc74 with SMTP id 74so85198718ioc.2 for ; Sat, 07 Nov 2015 09:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TG1DFFts/spCWywJaldd7uHJPoNi2Y0TrFeqRlNT1KU=; b=JKTt/3lUrdyZnu3WcXRgcGM3sQFIuQrySUbiKSiVOmDxnaY0FvPcXxjOu7s6QuES1z C4jFWqQPj0EbQQKEIWnczbZDunXl+sptaoEob/1Eo/fWw7bNuvvBYXMr5Zc+byuCLXdG ubkR253cfwtjc7tj3sfZDx4CaQPHTmomNyRfI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TG1DFFts/spCWywJaldd7uHJPoNi2Y0TrFeqRlNT1KU=; b=GZb3VJc23b8t7VYEnuzNw2zN4zBY/lpW67D1zc7+ShL4RCxnxjGCWTR5xP6lUP7RA3 Bm4XcaQMTg8JRrDowS99YdJiixXZ9Q4lAqZsqWymgsAF/cAD1bm0bBSiNywLFVrWc4Xw Y1EWL5NnfW5DFxlQnxtuXfD5h+Q7DQ1W7d0xTH0OG2ZJlsmAKuXTDyIj2fPtR3TvOgOz 9a1+Ou7+ugQ/b/F4xUtpGJC/N1c1MFY+iklOveY3bcHZc1i8nNffognvWBRB5EVE3RLk 9zSw9p6KBl7bFEHztxNLbfnqJKiJpTRePHXEvnODABJOXKIsOZorCa2V/L+av8GkWz73 10bA== X-Gm-Message-State: ALoCoQmknrVmfZgHIroQbpNvDpLAVx0aDk09r1WqlFHUuQqyKvmfQp3Cy9uvI+hlaAlC8T2VqK0J MIME-Version: 1.0 X-Received: by 10.107.152.2 with SMTP id a2mr19400702ioe.123.1446915827794; Sat, 07 Nov 2015 09:03:47 -0800 (PST) Received: by 10.50.202.71 with HTTP; Sat, 7 Nov 2015 09:03:47 -0800 (PST) In-Reply-To: References: Date: Sat, 7 Nov 2015 12:03:47 -0500 Message-ID: From: Casey Deccio To: "Kurt Andersen (b)" Content-Type: multipart/alternative; boundary=001a1140e9d2efaeef0523f657cd Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Questions about the _odup algorithm X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 17:03:50 -0000 --001a1140e9d2efaeef0523f657cd Content-Type: text/plain; charset=UTF-8 On Sat, Nov 7, 2015 at 11:37 AM, Kurt Andersen (b) wrote: > Citing a pastebin copy of Appendix A (for line numbering): > http://pastebin.com/iYziF5LW > > Perhaps it is a syntax misunderstanding, but it looks to me like line 44 > ends up setting subDomainLabels to -1 and from there I'm a bit lost. It > might be because of the mix of ordering in the label arrays (8..3) is > throwing me a bit off (usually handle arrays from min..max). > > Can you clarify? > Hi Kurt, Thanks for the question--and for taking the time to read into the draft. Line 44 would only set subDomainLabels to -1 if both n and orgBoundary are 0. But that is the base case, handled in lines 26 - 42. You only arrive at line 44 if n != orgBoundary. Combine that with the constraint that 0 <= orgBoundary <= n (line 7), then when you arrive at line 44, n is always greater than orgBoundary, which means subDomainLabels is always greater than or equal to 0. When I initially wrote up the pseudo code, it made sense to me to use 1-based sequence indexing. I can look into whether it makes sense to use 0-based sequence indexing. There might pros and cons to both, but the most important thing is that it is correct :) I have some working code that I'll post early next week (hopefully Monday). Casey --001a1140e9d2efaeef0523f657cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 7, 2015 at 11:37 AM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:
Citing a pastebin copy of Appendix A (for line= numbering): htt= p://pastebin.com/iYziF5LW

Perhaps it is a syntax misunders= tanding, but it looks to me like line 44 ends up setting subDomainLabels to= -1 and from there I'm a bit lost. It might be because of the mix of or= dering in the label arrays (8..3) is throwing me a bit off (usually handle = arrays from min..max).

Can you clarify?
<= /blockquote>

Hi Kurt,

Thanks for the questio= n--and for taking the time to read into the draft.

Line 44 would only set subDomainLabels to -1 if both n and orgBoundary are=20 0.=C2=A0 But that is the base case, handled in lines 26 - 42.=C2=A0 You onl= y=20 arrive at line 44 if n !=3D orgBoundary.=C2=A0 Combine that with the constr= aint that 0 <=3D orgBoundary <=3D n (line 7), then when you arrive at lin= e 44, n is always greater than orgBoundary, which means subDomainLabels=20 is always greater than or equal to 0.

When I initially wrote up the pseudo code, it made sense to me to use 1-based sequence=20 indexing.=C2=A0 I can look into whether it makes sense to use 0-based=20 sequence indexing.=C2=A0 There might pros and cons to both, but the most=20 important thing is that it is correct :)

I have some working c= ode that I'll post early next week (hopefully Monday).
<= div id=3D":6ub" class=3D"" tabindex=3D"0">
Casey
--001a1140e9d2efaeef0523f657cd-- From nobody Sun Nov 8 23:35:31 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A081B6CAF for ; Sun, 8 Nov 2015 23:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 YSiCMtNA1sT8 for ; Sun, 8 Nov 2015 23:35:28 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0094.outbound.protection.outlook.com [104.47.126.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6CD1B6CAB for ; Sun, 8 Nov 2015 23:35:27 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by KAWPR01MB0129.jpnprd01.prod.outlook.com (10.161.26.21) with Microsoft SMTP Server (TLS) id 15.1.318.15; Mon, 9 Nov 2015 07:35:24 +0000 To: Casey Deccio , "dbound@ietf.org" References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56404CB4.7000401@it.aoyama.ac.jp> Date: Mon, 9 Nov 2015 16:35:16 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR0201CA0031.apcprd02.prod.outlook.com (25.164.90.169) To KAWPR01MB0129.jpnprd01.prod.outlook.com (25.161.26.21) X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0129; 2:/CbCfxQQUFHmuD5I0MosrArl2JEVgHOXBMNZyJNzFvzufWWWAHUDcK1DzafOLIUlqhXwG50eGwKCJUowpgHY+Y/T88S5sJRQIDFMzpUuaqdSnHOjlZbJ1l9udQbxD2GosRWleknGkEgjX+8vdP4H0ZAhdra8wqwnkLmCpH8QKG8=; 3:D1W17nE5+X4R7Qm+9kx6FHNW2uOSEWGLwWGBFkZYoOzLyj7DrOP1gByjww2DkNpYhXtsksiiqyBdy6xKU0kteaN4rQr1vKszNn7TXsX0gqG5LNX67oCtyj+fWHN4vh//uoxfmiW+wsHusNSJ17O1zg==; 25:wL52njKRg4anLpL7kB5plZtH2qDZ6XwEWPVb/Hqqlvaqsbpg6r6cYBjqpZx7+YBKzVwgag2UJozYA81oov6sZdc6P3MtardFAGQzZwsilHkwgptM29WQ6h+t0eXWWOKHzMBAzRae3BTisG9m9RyRijCLLsRJ86QGbk5Q/D6dFEnrMxGe+A5H+9Ko1Dl7O45weNEwDgxLCSm3M2db7bnzwKywFVuorAZ8upzJ9n3mqotfhRoVlDmEAFhPHgyfDydUVrp7D8xNfa9lMkMS7bjGCw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KAWPR01MB0129; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:KAWPR01MB0129; BCL:0; PCL:0; RULEID:; SRVR:KAWPR01MB0129; X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0129; 4:ozyUndSgiBzE5qL4Jae0KnmCc2EkFtigi6jYsdmn4vpsYqdh6Zyoz0brdEr/F0jHVSyPanQUlhsGu12w+8h2Ne7JtyMAMNVnjOh59TlizVWI4R2FXrFykSy2HDEgvjkhzR7FgqiP6CFtWJjrq0iN4X3uUkwUO2JTd37uZI/VdXs1wX06OxIWUSTC5HUuZt3Bq04IMeg45ULCEtSvhQqo2Wfj4uOzCHVt+JEdcyfH52UqSXRt4/CphK112v9lxblyLtpMOuvgsgplmIxpba293SkNFMKwAnKavKdZUg1hl2OeEnByOKQCVnLFkk7q8UvzvNqwIiOGM/JuPotY2qqWCKzkPjSKmTPVwfPZ2d9z7NaNHcFaLw5U/F3F0IyGcMU2 X-Forefront-PRVS: 0755F54DD9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(479174004)(24454002)(189002)(199003)(23676002)(5001770100001)(189998001)(97736004)(33656002)(86362001)(107886002)(5004730100002)(5007970100001)(65816999)(47776003)(87976001)(101416001)(5001960100002)(65806001)(66066001)(80316001)(50466002)(74482002)(76176999)(59896002)(50986999)(87266999)(106356001)(92566002)(40100003)(2501003)(122386002)(105586002)(99136001)(5008740100001)(81156007)(4001350100001)(230700001)(54356999)(42186005)(77096005)(5001920100001)(83506001)(64126003)(2950100001)(65956001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0129; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMTI5OzIzOmtrNzlMbkhQSXNOdW96VnY0REVOd05xWnpW?= =?utf-8?B?N0cxS0U0V25UaGpJOHZwcExJVW5MU21NUlRZQ0EyenFPU3V4ck4xa1ZLS0Zo?= =?utf-8?B?VUxHZGRMSjZ1bnlvZXg1a3M4ZWgxbkM5OWhqVUU4U2p6TGhONXpld09zK2Nm?= =?utf-8?B?SVJmZ1RoYWhOVzhvR3pIMjZpbkg4dlM4c1liaW5ENnkwc2xoREg1OUw5UmJZ?= =?utf-8?B?QzVpMkM4dkkrRSt0S0ZUZU8xNithOXVZNU5EbTgxV1lxbVB4WWxhaExucmR3?= =?utf-8?B?TkhxN2RKNkUxQWhEbEF0N2ZQaGpTUG9LdUtuQllBVU9la0ppTEsvc0UwR3Q0?= =?utf-8?B?ZFZFOUJvdjVURGhmTFZJakZlQzZWOEI5dkhLbWFKMERpRzFVRlVlQjZKTlVF?= =?utf-8?B?T2V2WHQwNyt1YjRBd0g0ZStvZGRwVnhnckFla1NLczA2cUFINW1kN3FZVnlU?= =?utf-8?B?cWJsb3pJL0hyNFkyRlpmSFRaaWwwZEJRd3NaZEwvMmpZMlBhbHF6QjlsT3BY?= =?utf-8?B?NWFzM2dBVDFXU3pjYmFnaTRsbzVPZm5jRkZZTVdiNmpYaWNCdGZoek1XZ0pO?= =?utf-8?B?dkJiejdibGIzdUg4dkpqVlAyNjV4cE83eXpPNFdETjNSeVN3RGN3dVBlcjRJ?= =?utf-8?B?R1FvbFQvOXdkdjVDbkszWC9USm5hZjQ3dGpid2h5MXBLQzBoWmFnUUZtS0pn?= =?utf-8?B?K3JjOE1tQzF6TTFmSlNJRTBleWtJR0ozRE5COENOL290djlpdUlQS05QTTZa?= =?utf-8?B?QnBHZ1lMTHFHUUpXZVdKN1RjMHFmdjlXN3hqWnJvVXRUalhibnhTbTl2R1Vl?= =?utf-8?B?TUx0Sjl1R1phaWdXRVVHb0Rhdmh2eUR4dzR5azdBWTdsOTkxQ2xrVlBoWTFz?= =?utf-8?B?YUpZeElUMjQwdDJMa1lRWXFBMUNHR0F3SXpBWHlPWjJaVEFtZ3ZhYjdlZTB2?= =?utf-8?B?LzNSQXFLb0NSazdjdjhQR2NEeG5uNk9sZWNha3diSDVid3NqMWtDRThDNXB5?= =?utf-8?B?UDc0L0ljaXdpbWFhR3dGazUxZDdiaDIvZW55QS9IS1BCTFVKNm1NeGlNZFdU?= =?utf-8?B?aDAxajRCVklMVlEwN2o5bCs2aU1Pc0NEQUErdC9jcDlXcmNQMHY3NHhXUm9q?= =?utf-8?B?UFViRjFvdDRWbk1sSFQ5ejFSUjRjbEFVSEQrcjRnN0x5NFptenNzYlZ2RFRM?= =?utf-8?B?Y2FoNWV2bVRieFFxVncwc1MrbFJPdFYrQ3JURXRTYzgxR1N1NEVLK2lrbTFi?= =?utf-8?B?VUlyUE1waDV1RnM1em1hTDJIaysxWnhMa0t6WHhyZzZMUEpqYjUyWUNnWmZh?= =?utf-8?B?bTkxRUFsQnVDQjd1TFlMcGJXOVBhMjdlaWpPYnFnVFNuQ05rRENrVkh4RDdM?= =?utf-8?B?VUtSL3Blak0zQUNjbEtzM0tOdVg3NHhqSi9mZWNMVXBjQVM4SC9xK3BKZmVk?= =?utf-8?B?aGg4NUgva1RNb0lYV0FvcGtUY0FNYVJyUTFKZjdVTldnSWVERzN5WUhtcFp4?= =?utf-8?B?NkZUMXpmTkJoaGQvTWtUblJLREoxdDJXVFpreHJ6RnJKTlZrZUVoRUJ1d05h?= =?utf-8?B?aGVUQ0FpOE8yaTRQMFNqemNtdVVkQjBuakxqeWVQYi93QmJ4VU9oYVl6YUxt?= =?utf-8?B?Q0d4dmIwYTFDdU0wZE5zZVI4MDM5bXVOcXltY1l6UzB0NzRxYm11NkdzaDZB?= =?utf-8?B?WWhBL3FrZ0IzK05iWjM1Smc2TlNhWklKdkh1QmJqQ0U3YVV5ODRsYWpRQlpT?= =?utf-8?B?ZDVhTlNIS0FBTjhDQ2l5UT09?= X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0129; 5:kOn9a9KR1shu0loWodcH//JLks7Gex1ja+3hyKK08DGCD7tsNCdrTH6QjbJjI+82i5C9JIMJJWjY/OygUcXcqbIPoBCeWhDHbfnch47Y+DQwVMvZEs5G9GRedWzWus2vmci1oVoMJP+aEncoYOpSjw==; 24:eLskFopykfhUJZCfc5qAfJKZHKfxdn2YL3Wvg6m5K4XF9MJ11IYq7fNfIKAiW7R81UJe+6rQoQJtPcNrKmUiEYIJIjg++9ZZ3pmzj8RyG2Y=; 20:+7fx2fgurMbyInQFmUvreerl04U45Pvmvk8Ph22P7p3MPYR72fMlej5UzSXWS/zNFU6tNbROcRvaCn/Y+LCBbg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2015 07:35:24.1214 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0129 Archived-At: Subject: Re: [dbound] ODUP - some clarifications X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 07:35:30 -0000 Hello Casey, On 2015/11/03 21:02, Casey Deccio wrote: > I appreciate the feedback I received about my draft in tonight's dbound > working group meeting. It was clear that clarification was necessary in > some places, which can be brought into the draft, but which I also present > here. > 2. Performance - The performance is _not_ O(n**2) as was mentioned in the > meeting. It is order O(n). That's quite a difference :). To illustrate, > we take the name a.b.c. Here are the _worst-case_ resolution paths: Below, you write OR, which I guess you intend to be exclusive. If that's true, then indeed we get O(n). But why and how can these cases be made exclusive? Regards, Martin. > c._odup/TXT (NODATA) > b.c._odup/TXT (NODATA) > a.b.c._odup/TXT (NXDOMAIN or NODATA) > _odup/TXT > > OR > > c._odup/TXT (+org) > b._odup.c/TXT (NODATA) > a.b._odup.c/TXT (NXDOMAIN or NODATA) > _odup.c/TXT > > OR > > c._odup/TXT (+org) > b._odup.c/TXT (+org) > a._odup.b.c/TXT (NXDOMAIN or NODATA) > _odup.b.c > > OR > > c._odup/TXT (NODATA) > b.c._odup/TXT (+org) > a._odup.b.c/TXT (NXDOMAIN or NODATA) > _odup.b.c/TXT > > So, worst case is n + 1 lookups, or O(n). I don't know that the > performance is any different than that of qname minimization. > > But if you replace any of the NODATA (only) responses with NXDOMAIN, steps > are skipped, resulting in fewer lookups. > > Also, let's assume the client has a local copy of the policy-negative realm > (_odup zone). It already knows the answer to any of the above lookups > whose names end with "_odup", so it starts from a lower point in the > resolution process, thus eliminating more lookups. > > Now assume both a local copy and a "blank slate" (i.e., no one has deployed > any ODUP records outside of the _odup zone). There are two lookups > required in the worst case scenario, regardless of name length. For > example, assume the policy is delegated to the b.c zone with either: > > b.c._odup "+org" > > OR > > c._odup "+bound" > (and b.c._odup doesn't exist in the negative policy realm) > > The worst-case lookup scenario to find the policy for a.b.c is: > > a._odup.b.c/TXT (NXDOMAIN or NODATA) > _odup.b.c/TXT > > and the worst case to find the policy for b.c is simply: > > _odup.b.c/TXT > > -------------- From nobody Mon Nov 9 01:44:06 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BC31B7B63 for ; Mon, 9 Nov 2015 01:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 tZEL5newQmWT for ; Mon, 9 Nov 2015 01:44:03 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353831B7B61 for ; Mon, 9 Nov 2015 01:44:03 -0800 (PST) Received: (qmail 50752 invoked from network); 9 Nov 2015 09:44:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=c63e.56406ae2.k1511; bh=WQ7Q2G2rmHjtZpU45Nvw9soYDfORt4MWE1OCjdf8rR4=; b=2OyR/zbN/p9+9cT6zeYdH445JD1LgI7zHpuCwQa4L82YFRRq3WH0fyTNQFGtbZ8gVdqkXsTxIjkurM9bbe1UDoENNXq3U8zVl8zvFtbvdmrNucvklNOS4c+yXehV0L/tSJyftdt7Yw/YYFYglZx1i3E/sLaz14hCdElkPd7dIy8U1mppS8uZyWalMD77a+ohx/nouFx+JE9KZYcADGcinpKJBbBtxAdkVWBaVVLLyzB4NZ0h7w+pz78ez833QXpi DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=c63e.56406ae2.k1511; bh=WQ7Q2G2rmHjtZpU45Nvw9soYDfORt4MWE1OCjdf8rR4=; b=WUSg5aPivdzmSjgYBHayaNcRLyBgDbyeR3K9UQVDuI+dkt+cxLVlxi1pm7XwKYDDg6gj00JK8ENllU2ZjEWwE7hcS53W+2DdFWWrLyvZLcCf6HjtzCAaJV26d3tGVCkbFvr5lbYniYdmtPNaa8mK2uKZUvcfHvKp6CN30dS3TYEtLW3DhE92q/2UaxCk3q5e5vStbz0RDq09XVtIDnrlc4q3rUHlJPVoP5hy+fhKHaDNtnMohrqL06bykH2VamgW Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 09 Nov 2015 09:44:01 -0000 Date: 9 Nov 2015 18:43:58 +0900 Message-ID: From: "John R Levine" To: dbound@ietf.org User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [dbound] Updated orgboundary draft X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 09:44:04 -0000 I've updated my old orgboundary draft to address issues that showed up recently. It's sort of like Casey's draft but it's much simpler, and every domain publishes its own info in its own namespace. I added a flag so you can say no boundaries below this one, and it has a less kludgy way of allowing different applications to have different boundaries. A boundary check will generally be one DNS lookup if a boundary does not permit lower level boundaries, or two if it does. It uses DNS wildcards in a way that is fairly aggressive but as far as I can tell is 100% in compliance with the specs and will work on normal name servers. https://tools.ietf.org/id/draft-levine-orgboundary-03.txt Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Nov 9 05:55:55 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB751B2BC5 for ; Mon, 9 Nov 2015 05:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 nuFOTubYXzdB for ; Mon, 9 Nov 2015 05:55:52 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 8F2471B2BC0 for ; Mon, 9 Nov 2015 05:55:52 -0800 (PST) Received: by iody8 with SMTP id y8so185781675iod.1 for ; Mon, 09 Nov 2015 05:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yRZYSh2l8LhfNv4o7O2fgEDF6JtAz/roBzaybBEMeBU=; b=LPhf9HG3PVPvGt8Xq3J3ne9xurcx5yVdCFs9L3a6EMprAHGmX3xvGWz1O+VVNPVwEV 2zZ9wHa+y4xRQOhJtKkjUOxgFMbmqPu+C5cHwMOCcI67jFKmJbeEHtiISBgaT+s4wfWi mzsOiryUzNq/M+qWFeVmNWAjrW6HnBtDtgFbk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yRZYSh2l8LhfNv4o7O2fgEDF6JtAz/roBzaybBEMeBU=; b=RF867SLkusQv4UWFD7HSuljT2VrK0PNXw+gfUWkLm0ikESivf58+2/vzCg5kGRZgsN 4E7sNT61j8lIQbMnoiZUq1QOawTFeaRjTMBTvwz/LUvv/V0EuHN+aCiC77MuG7vngWVi RE7QfyUqtkIcpYLltH1tmWqiWAgp0yoAeDLHIwRtZjbbK0d7N0NxBXTGN/d/y/gUgKw0 VBSWrBXDAidqJVUgAYReA/x6xeXYO9Sa4yH9prk6oDGgtEHiZGU271zklRJeB8olphbm EhDjNdQ0ZJWD24aUD+8PGFz+TX46LQTcBpu+S2qSGMrfOtaU9r1SgD0gLAknRq9BBA3l PPUg== X-Gm-Message-State: ALoCoQkKP1bSo4jSY8t6OuN74LOGFJ+5gfoNYXgjqSIFobrc5KTXl6Rcs8PNfaFZDKDQRBM5sR3P MIME-Version: 1.0 X-Received: by 10.107.19.219 with SMTP id 88mr30921285iot.41.1447077351882; Mon, 09 Nov 2015 05:55:51 -0800 (PST) Received: by 10.50.202.71 with HTTP; Mon, 9 Nov 2015 05:55:51 -0800 (PST) In-Reply-To: <56404CB4.7000401@it.aoyama.ac.jp> References: <56404CB4.7000401@it.aoyama.ac.jp> Date: Mon, 9 Nov 2015 08:55:51 -0500 Message-ID: From: Casey Deccio To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=001a113f94be859e7705241bf3b4 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] ODUP - some clarifications X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 13:55:54 -0000 --001a113f94be859e7705241bf3b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Martin, On Mon, Nov 9, 2015 at 2:35 AM, Martin J. D=C3=BCrst wrote: > > Below, you write OR, which I guess you intend to be exclusive. If that's > true, then indeed we get O(n). But why and how can these cases be made > exclusive? > In short: by design :) This is a top-down, policy designation mechanism. Once you learn that one organizational domain has designated another in the subdomain space, there is no need to search further in that first domain space. I've numbered the examples below. In number 1), because the first two responses are NODATA, there are no TXT records and thus no ODUP statements, which means that there is nothing telling us that there is an organizational domain or boundary below. So with each subsequent query we keep our qnames within the same organizational domain (i.e., the root zone). It doesn't make sense to look for a policy at _odup.c/TXT because there is nothing telling us that the domain name "c" is an organizational domain. Doing so would be analogous to attempting to identify and query the name servers for the DNS name sub.example.com, when there is no delegation from example.com to sub.example.com! In number 2), we learn in the response to the first query (within the root organizational domain), that "c" is an organizational domain. Knowing this, there is no reason to resolve b.c._odup/TXT or a.b.c._odup/TXT. Doing so would be be like continuing to query example.com name servers for sub.example.com, when we've learned that there is a delegation from example.com to sub.example.com! The qname of the third query is also within the "c" organizational domain because of the NODATA response to the second query (i.e., b._odup.c/TXT). Does this help? Regards, Casey 1. c._odup/TXT (NODATA) > b.c._odup/TXT (NODATA) > a.b.c._odup/TXT (NXDOMAIN or NODATA) > _odup/TXT > > OR > > 2. > c._odup/TXT (+org) > b._odup.c/TXT (NODATA) > a.b._odup.c/TXT (NXDOMAIN or NODATA) > _odup.c/TXT > > OR > > 3. > c._odup/TXT (+org) > b._odup.c/TXT (+org) > a._odup.b.c/TXT (NXDOMAIN or NODATA) > _odup.b.c > > OR > > 4. > c._odup/TXT (NODATA) > b.c._odup/TXT (+org) > a._odup.b.c/TXT (NXDOMAIN or NODATA) > _odup.b.c/TXT > > So, worst case is n + 1 lookups, or O(n). I don't know that the > performance is any different than that of qname minimization. > > But if you replace any of the NODATA (only) responses with NXDOMAIN, step= s > are skipped, resulting in fewer lookups. > > --001a113f94be859e7705241bf3b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

On Mon, Nov 9, 2015 at 2:35 AM, Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote:

 Below, you write OR, which I guess you intend to be exclusive. If that'= s true, then indeed we get O(n). But why and how can these cases be made ex= clusive?

In short: by design :)

=
This is a top-down, policy designation mechanism.=C2=A0 Once you= learn that one organizational domain has designated another in the subdoma= in space, there is no need to search further in that first domain space.=C2= =A0 I've numbered the examples below.

In number 1), b= ecause the first two responses are NODATA, there are no TXT records and thu= s no ODUP statements, which means that there is nothing telling us that the= re is an organizational domain or boundary below.=C2=A0 So with each subseq= uent query we keep our qnames within the same organizational domain (i.e., = the root zone).=C2=A0 It doesn't make sense to look for a policy at _od= up.c/TXT because there is nothing telling us that the domain name "c&q= uot; is an organizational domain.=C2=A0 Doing so would be analogous to atte= mpting to identify and query the name servers for the DNS name sub.example.com, when there is= no delegation from exampl= e.com to sub.examp= le.com!

In number 2), we learn in the response to the= first query (within the root organizational domain), that "c" is= an organizational domain.=C2=A0 Knowing this, there is no reason to resolv= e b.c._odup/TXT or a.b.c._odup/TXT.=C2=A0 Doing so would be be like continu= ing to query example.com name servers for su= b.example.com, when we've learned that there is a delegation from <= a href=3D"http://example.com" target=3D"_blank">example.com to sub.example.com!=C2=A0 Th= e qname of the third query is also within the "c" organizational = domain because of the NODATA response to the second query (i.e., b._odup.c/= TXT).

Does this help?

Regards,
Casey

1.

c._odup/TXT (NODATA)
b.c._odup/TXT (NODATA)
a.b.c._odup/TXT (NXDOMAIN or NODATA)
_odup/TXT

OR


2.
=C2=A0
c._odup/TXT (+org)
b._odup.c/TXT (NODATA)
a.b._odup.c/TXT (NXDOMAIN or NODATA)
_odup.c/TXT

OR


3.
=C2=A0
c._odup/TXT (+org)
b._odup.c/TXT (+org)
a._odup.b.c/TXT (NXDOMAIN or NODATA)
_odup.b.c

OR


4.
=C2=A0
c._odup/TXT (NODATA)
b.c._odup/TXT (+org)
a._odup.b.c/TXT (NXDOMAIN or NODATA)
_odup.b.c/TXT

So, worst case is n + 1 lookups, or O(n).=C2=A0 I don't know that the performance is any different than that of qname minimization.

But if you replace any of the NODATA (only) responses with NXDOMAIN, steps<= br> are skipped, resulting in fewer lookups.

--001a113f94be859e7705241bf3b4-- From nobody Wed Nov 11 13:36:55 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956731B3A9F for ; Wed, 11 Nov 2015 13:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 YgG_wyb7KGKP for ; Wed, 11 Nov 2015 13:36:53 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AAF1B3A9E for ; Wed, 11 Nov 2015 13:36:52 -0800 (PST) Received: by wmec201 with SMTP id c201so65207932wme.1 for ; Wed, 11 Nov 2015 13:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=sQ/fGBGsCKEP+g0WL2s9J9zbfe0RE1rAGLfq5yUQSkI=; b=Jplj2PiAtvaVZcF++4VF+eR99lLo3h+IaNxFFMrg7aFfff/4Z6KqIQnh9MbSCBooEY 8zu2ItFfI2lLQSw6pc2SF4uitMRtoSgJGccL9a6h16bwb04miefLWe/p7bGP6PtQDFlO en9ysA/KI87cqKDzDjYEOjCpj0aup63ijOuxM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=sQ/fGBGsCKEP+g0WL2s9J9zbfe0RE1rAGLfq5yUQSkI=; b=f/7j9vwJJFvVZSp8OQy0kpyfmR4aYPnRSThx2B2FtlMLUgQ7nutrXt41eyZLl9Zy4j iJ9+ImHBT0V1Ev8tnS9EGt64bm66HK58Ysyrad0Yzy+1oyJZ/B7x1ffAl1/BW9cShfpX juVv++F8W5i6jliQFXGgB8M7hj9/yD2iepLoneFCXS/YWTp5XmC9DbgBs6BHFwylUSOO HOEkobgjjL+Zs/qJfWRlq6mgo+OsOuhTrwY6e/7jCEizezjiu2a85XQMb7b0ZuqWbvfE c5vblaC1jMAafZwvQ9fKA4KIkvwAyRIFmxPLwRpJ5Vl6fiDyk/oXicjLJNUT4uYB/oA0 dHBA== X-Gm-Message-State: ALoCoQlAEUyIL+7y/QSnHtgqh3bJd7yXAjyyC89YK2ROPHwdtG4/41NSLyJUrXDI1+tUi5hKjluL MIME-Version: 1.0 X-Received: by 10.194.57.142 with SMTP id i14mr14304303wjq.24.1447277811508; Wed, 11 Nov 2015 13:36:51 -0800 (PST) Received: by 10.195.12.137 with HTTP; Wed, 11 Nov 2015 13:36:51 -0800 (PST) Date: Wed, 11 Nov 2015 16:36:51 -0500 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=047d7ba97d24d8c27005244a9f7f Archived-At: Subject: [dbound] New version of draft-deccio-dbound-organizational-domain-policy X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 21:36:54 -0000 --047d7ba97d24d8c27005244a9f7f Content-Type: text/plain; charset=UTF-8 I've made modifications to draft-deccio-dbound-organizational-domain-policy, captured in a -01 draft. Changes include the following: - Add BNF representation of ODUP statements - Updates to algorithm for completeness - Rewording of and examples added to textual algorithm - Add notion of "fetch" directive (documentation to come) - Add resolution examples Your reviews are appreciated. Cheers, Casey A new version of I-D, > draft-deccio-dbound-organizational-domain-policy-01.txt > has been successfully submitted by Casey Deccio and posted to the > IETF repository. > > Name: draft-deccio-dbound-organizational-domain-policy > Revision: 01 > Title: Organizational Domains and Use Policies for Domain Names > Document date: 2015-11-11 > Group: Individual Submission > Pages: 23 > URL: > https://www.ietf.org/internet-drafts/draft-deccio-dbound-organizational-domain-policy-01.txt > Status: > https://datatracker.ietf.org/doc/draft-deccio-dbound-organizational-domain-policy/ > Htmlized: > https://tools.ietf.org/html/draft-deccio-dbound-organizational-domain-policy-01 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-deccio-dbound-organizational-domain-policy-01 > > Abstract: > Various Internet protocols and applications require some mechanism > for identifying policy surrounding the use Domain Name System (DNS) > names. In this document we describe an extensible system in which > domain name policies can be discovered at various levels in the DNS > tree. > --047d7ba97d24d8c27005244a9f7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've made modifications to draft-deccio-dbound-or= ganizational-domain-policy, captured in a -01 draft.

Changes i= nclude the following:
- Add BNF representation of ODUP statements
- U= pdates to algorithm for completeness
- Rewording of and examples added t= o textual algorithm
- Add notion of "fetch" directive (documen= tation to come)
- Add resolution examples

Yo= ur reviews are appreciated.

Cheers,
Casey

A new ve= rsion of I-D, draft-deccio-dbound-organizational-domain-policy-01.txt
ha= s been successfully submitted by Casey Deccio and posted to the
IETF rep= ository.

Name:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 draft-deccio-dbo= und-organizational-domain-policy
Revision:=C2=A0=C2=A0=C2=A0 01
Title= :=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Organizational Domains and Use Polic= ies for Domain Names
Document date:=C2=A0=C2=A0=C2=A0 2015-11-11
Gro= up:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Individual Submission
Pages:=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 23
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://= www.ietf.org/internet-drafts/draft-deccio-dbound-organizational-domain-poli= cy-01.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-deccio-dbound-orga= nizational-domain-policy/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 https://tools.ietf.org/html/draft-deccio-dbound-organi= zational-domain-policy-01
Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/rfcd= iff?url2=3Ddraft-deccio-dbound-organizational-domain-policy-01

A= bstract:
=C2=A0 Various Internet protocols and applications require some= mechanism
=C2=A0 for identifying policy surrounding the use Domain Name= System (DNS)
=C2=A0 names.=C2=A0 In this document we describe an extens= ible system in which
=C2=A0 domain name policies can be discovered at va= rious levels in the DNS
=C2=A0 tree.

--047d7ba97d24d8c27005244a9f7f-- From nobody Wed Nov 11 14:31:01 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB711B3B54 for ; Wed, 11 Nov 2015 14:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 0nF3PVYKNtux for ; Wed, 11 Nov 2015 14:30:59 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 73C241B3B3B for ; Wed, 11 Nov 2015 14:30:59 -0800 (PST) Received: by wmvv187 with SMTP id v187so6498727wmv.1 for ; Wed, 11 Nov 2015 14:30:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=38tGvZ9L3kQSioNbkSrLJnh2vsgre7o6NBPWKcYeGzY=; b=RBVVE2DN06orD/vyEicp52cCJq0/V9IBaMklDAFdlKSsq5BDTChYtCAJ0U26x8sevz t1Lav7VmYZdL16P+GIDqVqp0FBlxQ6B+UUeKs2NX7Wm2gilE7zpxZ5tliLinkkRKQ2pq C0r6sfPqs2ODc7DSUpPFyIsw93Wuk/JJABMhk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=38tGvZ9L3kQSioNbkSrLJnh2vsgre7o6NBPWKcYeGzY=; b=HBSLxUZB19nXEsHjE2Cqb2HgNwht7nnlYW3I+Jjd30yhhZERUP8bn9XP8th3ptMl3W QwXt/dRIG3W3bM6QONeEoF0B1q35slKSoEZLLoKZkF2KzVzC4uQhdhrAUreUUhsSrNQr kg/qaVCcquJRIquSqQ0ubjjNcOStl+0bu5cpwY6lUBTsKn859iFXXkglOuivaQXe6vqx w1b/4AVqyzWSfQ2Oyffk0KUV7DaJSKEwzIqykbqi6bDZAoC0VgVsRSMNvoagT1oV4HAf 9vkzbBUqtaSJim+/e2ei0v4nZwjRajFuKWfzNYgaCNuTfd3Jj8BSGzTQ8RSM0LmMdjVP EBVw== X-Gm-Message-State: ALoCoQnf1ror1WNc61I8FfMhsWbgTfIIv7PGsbal7AsbpEiRMGoVh+RvivcOY3YerEcjVrsfrQ4k MIME-Version: 1.0 X-Received: by 10.194.57.142 with SMTP id i14mr14519566wjq.24.1447281057944; Wed, 11 Nov 2015 14:30:57 -0800 (PST) Received: by 10.195.12.137 with HTTP; Wed, 11 Nov 2015 14:30:57 -0800 (PST) Date: Wed, 11 Nov 2015 17:30:57 -0500 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=047d7ba97d24596ae605244b616b Archived-At: Subject: [dbound] ODUP code X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 22:31:00 -0000 --047d7ba97d24596ae605244b616b Content-Type: text/plain; charset=UTF-8 All, I've posted some code that implements the ODUP resolution algorithm from draft-deccio-dbound-organizational-domain-policy at: https://github.com/verisign/odup There is some documentation and examples in the README. Feedback is welcome. Cheers, Casey --047d7ba97d24596ae605244b616b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

I've posted some code= that implements the ODUP resolution algorithm from draft-deccio-dbound-org= anizational-domain-policy at:

https://github.com/verisign/odup

There is some= documentation and examples in the README.

Feedback is we= lcome.

Cheers,
Casey
--047d7ba97d24596ae605244b616b-- From nobody Wed Nov 11 17:53:28 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F84F1A0369 for ; Wed, 11 Nov 2015 17:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 GXyuW1W4xPqq for ; Wed, 11 Nov 2015 17:53:25 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0B91A032D for ; Wed, 11 Nov 2015 17:53:23 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B13F5F984; Wed, 11 Nov 2015 20:53:20 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 00E8B1FFB7; Wed, 11 Nov 2015 20:52:51 -0500 (EST) From: Daniel Kahn Gillmor To: Casey Deccio , "dbound\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 11 Nov 2015 20:52:51 -0500 Message-ID: <87si4cnfv0.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dbound] New version of draft-deccio-dbound-organizational-domain-policy X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 01:53:27 -0000 Hi all-- On Wed 2015-11-11 16:36:51 -0500, Casey Deccio wrote: > A new version of I-D, >> draft-deccio-dbound-organizational-domain-policy-01.txt >> has been successfully submitted by Casey Deccio and posted to the >> IETF repository. I've done a quick read of this draft, and i'm sorry to say that i was unable to attend the dbound meeting in yokohama. I still don't fully understand the tradeoffs involved here, but i thought maybe exposing my ignorance publicly would be useful :) Sorry if these questions/concerns have been brought up already, please point me to pre-existing answers! 0) if i understand it correctly, the use of the _odup zone itself for the "negative policy realm" seems likely to violate the DNS privacy intent of https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/, since the existing queries might have to make it all the way back to the root nameservers (or whoever is operating _odup). Am i misunderstanding this? It seems to be mentioned in Security Considerations, but it's not clear to me why we need to accept this additional privacy cost. Are the only additional advantages the zone prefetching/caching/SOA freshness checks? if so, surely we can come up with other solutions besides that? 1) I thought that the hijacking of TXT records in the way SPF did it was frowned upon by the DNS community. The SPF research has a page and a half of text about why the TXT record ended up winning for them and the dedicated RRTYPE lost, but it seems like a cautionary tale rather than something to emulate: https://tools.ietf.org/html/rfc6686#appendix-A Shouldn't this use a dedicated RRTYPE from the start instead of a custom (and therefore otherwise-globally-forbidden) label and a TXT record? Implementors can use the "private use" range initially for experimentation and request an early assignment if we think this is the way to go: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 2) For this to be used in an endpoint, the endpoint will need the results of the full list of queries, right? this differs from qname minimization, where the recursive resolver can do the chain of more-subtle queries and simply return the correct answer. For endpoints that want to validate DNSSEC-signed odup queries, they'll have N responses that they need to validate, each with potentially N signatures forming the full chain for each. is this the O(N^2) that came up in the meeting? 3) section 5 says "Directives other than "bound" and "-all" MUST NOT be used in the policy-negative realm.", but the examples in section 5.1 have an "org" directive (mapping from the !www.ck PSL entry). I understand that as a PSL exception, !www.ck may not technically be in the "policy-negative realm", but that means that the later conflation (e.g. in section 5.2) of "policy-negative realm" with "_odup DNS zone" aren't quite correct either. There may be only terminology fixes needed here, but i don't understand the scheme well enough to be sure. 4) step 4 in section 4 needs an s/ODUUP/ODUP/ hope this is useful feeback, --dkg From nobody Wed Nov 11 18:12:21 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219951A1A38 for ; Wed, 11 Nov 2015 18:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 Glf24emm0aUa for ; Wed, 11 Nov 2015 18:12:19 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9544F1A1A2D for ; Wed, 11 Nov 2015 18:12:18 -0800 (PST) Received: (qmail 6448 invoked from network); 12 Nov 2015 02:12:17 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 12 Nov 2015 02:12:17 -0000 Date: 12 Nov 2015 02:11:54 -0000 Message-ID: <20151112021154.2231.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dbound] Updated draft-levine-orgboundary-03 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 02:12:20 -0000 Not to toot my own horn or anything, but I really think this does most of what people have said they want DBOUND to do, published in the DNS, with each domain publishing its own info in the tree it controls, no new TLDs or other administratively painful changes, provision for different boundaries for different applications, and most checks in one or two DNS queries regardless of how deep the name tree is. What's not to like? R's, John >I added a flag so you can say no boundaries below this one, and it has a >less kludgy way of allowing different applications to have different >boundaries. > >A boundary check will generally be one DNS lookup if a boundary does not >permit lower level boundaries, or two if it does. It uses DNS wildcards >in a way that is fairly aggressive but as far as I can tell is 100% in >compliance with the specs and will work on normal name servers. > >https://tools.ietf.org/id/draft-levine-orgboundary-03.txt From nobody Wed Nov 11 19:06:25 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57581A21A5 for ; Wed, 11 Nov 2015 19:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 uTr8eFjQSus8 for ; Wed, 11 Nov 2015 19:06:21 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3DB1A21A0 for ; Wed, 11 Nov 2015 19:06:20 -0800 (PST) Received: by wmvv187 with SMTP id v187so12786004wmv.1 for ; Wed, 11 Nov 2015 19:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+4beLy6uvcRnyw/k9+BgvSixvx2xzPSpoluAEbdD+JE=; b=Yk7eHISKLBox/1AhGGcvJBOrWLnNGND+pIcoK41IZM7hzx9u3nKRx8YP9m2OyKCiOg c+B34qH8GfPA89gm7Om20C0/ab6+PbXuOUjzBoLj/6Ekrg0L0NyG48M7z6hvVV2ktEJ4 93xZ2KJ7TNCssQtaXs1vz2xN9/y8hxmTbskYE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+4beLy6uvcRnyw/k9+BgvSixvx2xzPSpoluAEbdD+JE=; b=lQFcV0g2DfLJi/LARuA8wcsFL8/+8ekdpQP9Mchi/TvsEcnGe6ox9xPYT56KTjayCx TWNOFeJpW+HVVuJEgqsudD78/iZ7ig09RxJMV7AfzNBW9eRcJesz11dd4fsEHUzoiAys fxfOHV+/13KwwrZ4H0wEJUuAyh7AHxPigisR+W39EsuAkK2BrJuLHoh/GFMlzJFolsl9 OHizus488HDFaKbnhxwMamdfGSTLO0kC5cmkUuE7XwNVj5usoMau7DP9f/o9gQxroLr/ x/k7f4QmRfVQwUy2NU8NHzwWbJe5vLjqo4UwErRtWL5PDbcuoZ4By3ZWEiwO4Np2kdoy HNCw== X-Gm-Message-State: ALoCoQmjb3HJCJSzFGytxeQ59vcwuZpMT+MKvwJy4BFIqhVlGQiBcW/+5z9SqJXsHf+7/EeeWrA5 MIME-Version: 1.0 X-Received: by 10.28.129.131 with SMTP id c125mr37464211wmd.21.1447297578799; Wed, 11 Nov 2015 19:06:18 -0800 (PST) Received: by 10.195.12.137 with HTTP; Wed, 11 Nov 2015 19:06:18 -0800 (PST) In-Reply-To: <87si4cnfv0.fsf@alice.fifthhorseman.net> References: <87si4cnfv0.fsf@alice.fifthhorseman.net> Date: Wed, 11 Nov 2015 22:06:18 -0500 Message-ID: From: Casey Deccio To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a114247f611adaa05244f3a46 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] New version of draft-deccio-dbound-organizational-domain-policy X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 03:06:23 -0000 --001a114247f611adaa05244f3a46 Content-Type: text/plain; charset=UTF-8 Hi Daniel, On Wed, Nov 11, 2015 at 8:52 PM, Daniel Kahn Gillmor wrote: > I've done a quick read of this draft, Thanks! > 0) if i understand it correctly, the use of the _odup zone itself for > the "negative policy realm" seems likely to violate the DNS privacy > intent of > https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/, > since the existing queries might have to make it all the way back to > the root nameservers (or whoever is operating _odup). Am i > misunderstanding this? That is correct. But... > It seems to be mentioned in Security > Considerations, but it's not clear to me why we need to accept this > additional privacy cost. also in the security section: "Additionally, referencing a locally downloaded version of the policy-negative realm for partial or "sufficient" ODUP resolution, as suggested in Section 5 can reduce queries to the _odup zone." Section 5 says: "It also enables consumer applications to work offline by simply downloading all the policy-negative statements when those are sufficient for the purposes of the application. "Even when a self-contained listing of the policy-negative names is locally available but insufficient for the needs of the consumer application (i.e., a more specific assurance of policy is necessary), this resource can provide an efficient starting place for ODUP resolution. Rather than starting with the root domain name as the organizational domain, the shortest organizational domain below the policy-negative boundary is used first. This increases efficiency by avoiding network latency associated with unnecessary DNS lookups." In addition to increasing efficiency by avoiding costly DNS lookups, what is lacking is an explicit statement of privacy, although it is mentioned in the security section (quoted above). Local download of the policy-negative zone would be the preferred method for ODUP resolution. Anticipated high-traffic zones could also make their realms available (e.g., using the "fetch" directive--which admittedly isn't fleshed out). For example, the following are the queries and responses for www.example.com : com._odup./TXT: NOERROR: v=odup1 +bound example.com._odup./TXT: NXDOMAIN www._odup.example.com./TXT: NXDOMAIN With a locally downloaded policy-neative realm, the lookups change to only the following: www._odup.example.com./TXT: NXDOMAIN Only _odup.example.com sees the queries. Also, it's entirely possible (and encouraged?) that over time the policy-negative realm would shrink, since the capability to declare these items in arbitrary namespace through policy delegation would be possible. > Are the only additional advantages the > zone prefetching/caching/SOA freshness checks? if so, surely we can > come up with other solutions besides that? > No, the primary benefit is a backwards compatible solution with a facilitated transition path. The zone prefetching/caching are means to enable the local download, which results in the increased efficiency (through decreased latency) and privacy. > > 1) I thought that the hijacking of TXT records in the way SPF did it > was frowned upon by the DNS community. The SPF research has a page > and a half of text about why the TXT record ended up winning for > them and the dedicated RRTYPE lost, but it seems like a cautionary > tale rather than something to emulate: > > https://tools.ietf.org/html/rfc6686#appendix-A > > Shouldn't this use a dedicated RRTYPE from the start instead of a > custom (and therefore otherwise-globally-forbidden) label and a TXT > record? Implementors can use the "private use" range initially for > experimentation and request an early assignment if we think this is > the way to go: > > > https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 > I'm not married to TXT, but it's certainly the path of least resistance for a solution like this. And SPF isn't alone here: don't forget DKIM and DMARC, the latter of which was approved earlier this year. There could be discussion on this, but the precedent is there. > > 2) For this to be used in an endpoint, the endpoint will need the > results of the full list of queries, right? I suppose it depends on the endpoint--how the application is consuming the data. As currently constituted, the output of ODUP resolution for a given name is: - organizational domain (above which is the organizational "boundary") - policy domain (the same as, or a subdomain of the organizational domain; where the actual use policy is) - policy (the policy--either explicit, or inherited from the policy domain) > this differs from qname > minimization, where the recursive resolver can do the chain of > more-subtle queries and simply return the correct answer. Yes, it is slightly different. > For > endpoints that want to validate DNSSEC-signed odup queries, they'll > have N responses that they need to validate, each with potentially N > signatures forming the full chain for each. is this the O(N^2) that > came up in the meeting? > No. The O(N^2) that was mentioned in the meeting was due to a misunderstanding about how the resolution worked, specifically with regard to how the labels are arranged around the _odup label in the resolution process. DNSSEC validation requires extra queries for DNSKEY and DS records, but remember we're working within the same namespace as the names we're looking up. So there aren't any extra queries. > > 3) section 5 says "Directives other than "bound" and "-all" MUST NOT be > used in the policy-negative realm.", but the examples in section 5.1 > have an "org" directive (mapping from the !www.ck PSL entry). I > understand that as a PSL exception, !www.ck may not technically be > in the "policy-negative realm", but that means that the later > conflation (e.g. in section 5.2) of "policy-negative realm" with > "_odup DNS zone" aren't quite correct either. There may be only > terminology fixes needed here, but i don't understand the scheme > well enough to be sure. > You are correct. I forgot to add that "+org" is also allowed. > > 4) step 4 in section 4 needs an s/ODUUP/ODUP/ > Will fix it. > > hope this is useful feeback, > Yes. Thanks! Casey --001a114247f611adaa05244f3a46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Daniel,

On Wed, Nov 11, 2015 at 8:52 PM, Da= niel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
I've done a quick read of this draft,

Thanks!
=C2=A0
=C2=A0 0) if i understand it correctly, the use of the _odup zone itself for
=C2=A0 =C2=A0 the "negative policy realm" seems likely to violate= the DNS privacy
=C2=A0 =C2=A0 intent of
=C2=A0 =C2=A0 https://datatrack= er.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/,
=C2=A0 =C2=A0 since the existing queries might have to make it all the way = back to
=C2=A0 =C2=A0 the root nameservers (or whoever is operating _odup).=C2=A0 A= m i
=C2=A0 =C2=A0 misunderstanding this?

That i= s correct.=C2=A0 But...
=C2=A0
=C2=A0 It seems to be mentioned in Security
=C2=A0 =C2=A0 Considerations, but it's not clear to me why we need to a= ccept this
=C2=A0 =C2=A0 additional privacy cost.

also= in the security section:

=C2=A0 "Additionally, referencing a=C2=A0=C2=A0 locally downloaded version of the policy-negative realm for = partial
=C2=A0=C2=A0 or "sufficient" ODUP resolution, as sugge= sted in Section 5 can reduce
=C2=A0=C2=A0 queries to the _odup zone.&quo= t;

Section 5 says:

=C2=A0 "It also enables co= nsumer applications to work offline by simply
=C2=A0=C2=A0 downloading a= ll the policy-negative statements when those are
=C2=A0=C2=A0 sufficient= for the purposes of the application.

=C2=A0=C2=A0 "Even when a= self-contained listing of the policy-negative names is
=C2=A0=C2=A0 loc= ally available but insufficient for the needs of the consumer
=C2=A0=C2= =A0 application (i.e., a more specific assurance of policy is necessary),=C2=A0=C2=A0 this resource can provide an efficient starting place for OD= UP
=C2=A0=C2=A0 resolution.=C2=A0 Rather than starting with the root dom= ain name as the
=C2=A0=C2=A0 organizational domain, the shortest organiz= ational domain below the
=C2=A0=C2=A0 policy-negative boundary is used f= irst.=C2=A0 This increases efficiency by
=C2=A0=C2=A0 avoiding network l= atency associated with unnecessary DNS lookups."

In = addition to increasing efficiency by avoiding costly DNS lookups, what is l= acking is an explicit statement of privacy, although it is mentioned in the= security section (quoted above).=C2=A0 Local download of the policy-negati= ve zone would be the preferred method for ODUP resolution.=C2=A0 Anticipate= d high-traffic zones could also make their realms available (e.g., using th= e "fetch" directive--which admittedly isn't fleshed out).
=
For example, the following are the queries and responses for= www.example.com:<= br>
com._odup./TXT: NOERROR: v=3Dodup1 +bound
example.com._odup./TXT: NXDOMAIN
www._odup.example.com./TXT: NXDOMAIN

With a locally downloaded policy-neative realm, the lookups chan=
ge to only the following:
www._odup.example.com./TXT: NXDOMA= IN

Only _odup.example.com sees the queries.

Also, it's entirely possible (and encouraged?) that over time the= policy-negative realm would shrink, since the capability to declare these = items in arbitrary namespace through policy delegation would be possible.
=C2=A0
= =C2=A0 Are the only additional advantages the
=C2=A0 =C2=A0 zone prefetching/caching/SOA freshness checks? if so, surely = we can
=C2=A0 =C2=A0 come up with other solutions besides that?

No, the primary benefit is a backwards compatible solutio= n with a facilitated transition path.=C2=A0 The zone prefetching/caching ar= e means to enable the local download, which results in the increased effici= ency (through decreased latency) and privacy.
=C2=A0

=C2=A01) I thought that the hijacking of TXT records in the way SPF did it<= br> =C2=A0 =C2=A0 was frowned upon by the DNS community.=C2=A0 The SPF research= has a page
=C2=A0 =C2=A0 and a half of text about why the TXT record ended up winning = for
=C2=A0 =C2=A0 them and the dedicated RRTYPE lost, but it seems like a cauti= onary
=C2=A0 =C2=A0 tale rather than something to emulate:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/htm= l/rfc6686#appendix-A

=C2=A0 =C2=A0 Shouldn't this use a dedicated RRTYPE from the start inst= ead of a
=C2=A0 =C2=A0 custom (and therefore otherwise-globally-forbidden) label and= a TXT
=C2=A0 =C2=A0 record?=C2=A0 Implementors can use the "private use"= ; range initially for
=C2=A0 =C2=A0 experimentation and request an early assignment if we think t= his is
=C2=A0 =C2=A0 the way to go:

=C2=A0 =C2=A0 =C2=A0 https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#= dns-parameters-4

I'm not marrie= d to TXT, but it's certainly the path of least resistance for a solutio= n like this.=C2=A0 And SPF isn't alone here: don't forget DKIM and = DMARC, the latter of which was approved earlier this year.=C2=A0 There coul= d be discussion on this, but the precedent is there.
=C2=A0

=C2=A02) For this to be used in an endpoint, the endpoint will need the
=C2=A0 =C2=A0 results of the full list of queries, right?
=
I suppose it depends on the endpoint--how the application is= consuming the data.

As currently constituted, the output= of ODUP resolution for a given name is:

- organizational= domain (above which is the organizational "boundary")
<= div>- policy domain (the same as, or a subdomain of the organizational doma= in; where the actual use policy is)
- policy (the policy--eit= her explicit, or inherited from the policy domain)
=C2=A0
=
=C2=A0 this differs= from qname
=C2=A0 =C2=A0 minimization, where the recursive resolver can do the chain o= f
=C2=A0 =C2=A0 more-subtle queries and simply return the correct answer.

Yes, it is slightly different.
= =C2=A0
For
=C2=A0 =C2=A0 endpoints that want to validate DNSSEC-signed odup queries, t= hey'll
=C2=A0 =C2=A0 have N responses that they need to validate, each with potent= ially N
=C2=A0 =C2=A0 signatures forming the full chain for each.=C2=A0 is this the= O(N^2) that
=C2=A0 =C2=A0 came up in the meeting?

N= o.=C2=A0 The O(N^2) that was mentioned in the meeting was due to a misunder= standing about how the resolution worked, specifically with regard to how t= he labels are arranged around the _odup label in the resolution process.
DNSSEC validation requires extra queries for DNSKEY and DS = records, but remember we're working within the same namespace as the na= mes we're looking up.=C2=A0 So there aren't any extra queries.
<= /div>
=C2=A0

=C2=A03) section 5 says "Directives other than "bound" and &= quot;-all" MUST NOT be
=C2=A0 =C2=A0 used in the policy-negative realm.", but the examples in= section 5.1
=C2=A0 =C2=A0 have an "org" directive (mapping from the !www.ck PSL entr= y).=C2=A0 I
=C2=A0 =C2=A0 understand that as a PSL exception, !www.ck may not technically be =C2=A0 =C2=A0 in the "policy-negative realm", but that means that= the later
=C2=A0 =C2=A0 conflation (e.g. in section 5.2) of "policy-negative rea= lm" with
=C2=A0 =C2=A0 "_odup DNS zone" aren't quite correct either.= =C2=A0 There may be only
=C2=A0 =C2=A0 terminology fixes needed here, but i don't understand the= scheme
=C2=A0 =C2=A0 well enough to be sure.

Y= ou are correct.=C2=A0 I forgot to add that "+org" is also allowed= .
=C2=A0

=C2=A04) step 4 in section 4 needs an s/ODUUP/ODUP/
Will fix it.
=C2=A0

hope this is useful feeback,

Yes.=C2=A0= Thanks!

Casey
--001a114247f611adaa05244f3a46-- From nobody Wed Nov 11 22:36:33 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7418B1AD0B4 for ; Wed, 11 Nov 2015 22:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Mv7DvWuGdMh3 for ; Wed, 11 Nov 2015 22:36:30 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id C5A6D1AD0B0 for ; Wed, 11 Nov 2015 22:36:29 -0800 (PST) Received: from yaojiankang (unknown [218.241.103.35]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5gDhiM0RWmPU4Bw--.15627S2; Thu, 12 Nov 2015 14:36:18 +0800 (CST) Date: Thu, 12 Nov 2015 14:36:20 +0800 From: "Jiankang Yao" To: "John R Levine" References: <20150929195514.14378.qmail@ary.lan> , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2015111214361410885223@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart673446243473_=----" X-CM-TRANSID: AQAAf0B5gDhiM0RWmPU4Bw--.15627S2 X-Coremail-Antispam: 1UD129KBjvJXoWxJryUtF4ktry7Zr45JFyxXwb_yoW8CFyrpF ZxtrnrKr4qyr1Ikw1Iv3yxuFy8JrZ7Aa45Xas5Cr18C34aqa4jqw4fK3W8AFZ3Xa1rtFyD KrWUZrZ5Jay5CaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBjb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF0I0E 4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4 IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IE b7IF0Fy26I8I3I1lc2xSY4AK67AK6r47MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4 AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE 17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMI IF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3 Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64 xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07jwdb8UUUUU= X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Cc: dbound Subject: [dbound] wildcard issue and two way assertion X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: yaojk List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 06:36:32 -0000 This is a multi-part message in MIME format. ------=_001_NextPart673446243473_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCg0KRnJvbTogSm9obiBSIExldmluZQ0KRGF0ZTogMjAxNS0xMC0wMyAyMjo0OQ0KVG86IHlh b2prDQpDQzogZGJvdW5kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Rib3VuZF0gRnc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteWFvLWRib3VuZC1kbnMtc29sdXRpb24tMDAu dHh0DQo+ID4+IElmIEkgd2FudCB0byBzYXksICJhbGwgbmFtZXMgdW5kZXIgZXhhbXBsZS5jb20g YXJlIHVuZGVyIHRoZSBzYW1lDQo+ID4+IGF1dGhvcml0eSIsIGhvdyBkbyBJIGRvIHRoYXQ/IA0K DQpJIHRoaW5rIHRoYXQgd2UgbmVlZCB0d28td2F5IGFzc2VydGlvbiBoZXJlLiBwYXJlbnRzIGNh biBzYXkgYWxsIG15IGNoaWxkcmVuIGFyZSB1bmRlciBteSBjb250cm9sIGFuZCBzaGFyZSB0aGUg c2FtZSBib3VuZGFyaWVzLiBpbiB0aGUgb3RoZXIgaGFuZCwNCnRoZSBjaGlsZHJlbiBzaG91bGQg c2F5IHRoYXQgSSBzaGFyZSB0aGUgc2FtZSBib3VuZGFyeSB3aGljaCBteSBwYXJlbnRzIHNwZWNp ZnkgdG9vLg0KDQoNCj4+IERvIEkgaGF2ZSB0byBwdXQgYSBEQk9VTkQgcmVjb3JkIGF0DQo+ID4+ IGV2ZXJ5IG5hbWUgdGhhdCBleGlzdHMgYXQgYW5kIGJlbG93IGV4YW1wbGUuY29tPw0KPiA+DQo+ ID4gSXQgaXMgd2lsZGNhcmQgaXNzdWUuIEl0IGlzIGFuIGluaXRpYWwgZHJhZnQsIHdoaWNoIHN0 aWxsIGRvZXMgbm90IGNvdmVyIGl0Lg0KPiANCj4gSSB0aGluayB5b3Ugd2lsbCBmaW5kIHRoYXQg RE5TIHdpbGRjYXJkcyBkb24ndCBkbyB3aGF0IHlvdSB3YW50LiAgSW4gDQo+IHBhcnRpY3VsYXIs IHdpbGRjYXJkcyBkb24ndCBtYXRjaCBhbnl3aGVyZSB0aGF0IGEgbmFtZSBleGlzdHMsIGV2ZW4g aWYgDQo+IHRoZXJlIGFyZSBubyByZWNvcmRzIGF0IHRoYXQgbmFtZS4gIFNvIGlmIHlvdSBoYXZl IGEgd2lsZGNhcmQgYXQgDQo+ICouZXhhbXBsZS5jb20gd2l0aCB5b3VyIHByb3Bvc2VkIHJlY29y ZCwgYW5kIGFuIEEgcmVjb3JkIGF0IA0KPiBhLmIuZXhhbXBsZS5jb20sIHRoZSB3aWxkY2FyZCB3 aWxsIG5vdCBtYXRjaCBhLmIuZXhhbXBsZS5jb20gb3IgDQo+ICBiLmV4YW1wbGUuY29tLg0KPiAN Cg0Kd2lsZGNhcmRzIHdvcmsgZm9yIHRoZSBub24tY29uZmlndXJlZCBzdWItZG9tYWluIG5hbWVz LiBJbiB0aGlzIGV4bWFwbGUsIHF1ZXJpbmcgYy5leGFtcGxlLmNvbSB3aWxsIHdvcmsgaWYgYy5l eGFtcGxlLmNvbSAgaXMgbm90IGNvbmZpZ3VyZWQgaW4gc29tZSB3YXlzLg0KDQppZiB0aGVyZSBp cyBhIHJlY29yZCBmb3IgYS5iLmV4YW1wbGUuY29tLCBpdCBpbmRpY2F0ZXMgdGhhdCB0aGUgYS5i LmV4bWFwbGUuY29tIG9yIGIuZXhtYXBsZS5jb20gbWF5IGV4aXN0LiBzbyB1bmRlciB0aGlzIHNp dHVhdGlvbiwgYS5iLmV4bWFwbGUuY29tIG9yIGIuZXhtYXBsZS5jb20gc2hvdWxkIGNvbmZpZ3Vy ZSB0aGVpciBvd24gZGJvdW5kIHJlY29yZCANCnNpbmNlIGEuYi5leG1hcGxlLmNvbSBvciBiLmV4 bWFwbGUuY29tIG1heSBiZSBvdXQgb2YgY29udHJvbCBvZiB0aGUgcGFyZW50cy4gVGhlIGRlYm91 bmQgcmVjb3JkIGhhcyBzaW1pbGFyIHNhbWUgbGltaXRhdGlvbiB3aXRoIHRoZSB3aWxkY2FyZC4N Cg0KSmlhbmthbmcgWWFvDQoNCg0KPiBBbmRyZXcncyBTT1BBIHJlY29yZCBoYXMgdGhlIHNhbWUg cHJvYmxlbSwgeW91J2QgbmVlZCB0byBwdXQgYSBTT1BBIHJlY29yZCANCj4gYXQgZXZlcnkgbmFt ZSB0aGF0IGV4aXN0cyBpbiB0aGUgRE5TIHN1YnRyZWUsIHdoaWNoIHdvdWxkIGJlIGEgdmVyeSAN Cj4gZGlmZmljdWx0IHByb3Zpc2lvbmluZyBwcm9ibGVtLg0KPiANCj4gUmVnYXJkcywNCj4gSm9o biBMZXZpbmUsIGpvaG5sQHRhdWdoLmNvbSwgVGF1Z2hhbm5vY2sgTmV0d29ya3MsIFRydW1hbnNi dXJnIE5ZDQo+IFBsZWFzZSBjb25zaWRlciB0aGUgZW52aXJvbm1lbnQgYmVmb3JlIHJlYWRpbmcg dGhpcyBlLW1haWwu ------=_001_NextPart673446243473_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
 
 
Date: 2015-10-03 22:49
> >> If I want to say, "a= ll names under example.com are under the&nbs= p;same
> >> authority", how do I do&n= bsp;that? 
 
I think that we need two-way assertion here. parents can say all my=20 children are under my control and share the same boundaries. in the other=20 hand,
the children should say that I share the same boundary which my=20 parents specify too.
 
 
>> Do I have to put a DBOUND=  record at
> >> every name that exists at=  and below example.com?
> >
> > It is wildcard issue. It = ;is an initial draft, which still does = not cover it.
> 
> I think you will find that DN= S wildcards don't do what you want. &nb= sp;In 
> particular, wildcards don't match anywh= ere that a name exists, even if 
> there are no records at that = name.  So if you have a wildcard a= t 
> *.example.com with your proposed record= , and an A record at 
> a.b.example.com, the wildcard will not&= nbsp;match a.b.example.com or 
>  b.example.com.
> 
 
wildcards work for the non-configured sub-domain names. In this exmap= le,=20 quering c.example.com will work if c.example.com  is not configured i= n some=20 ways.
 
if there is a record for a.b.example.com, it indicates that the=20 a.b.exmaple.com or b.exmaple.com may exist. so under this situation,=20 a.b.exmaple.com or b.exmaple.com should configure their own dbound record =
since a.b.exmaple.com or b.exmaple.com may be out of control of the=20 parents. The debound record has similar same limitation with the=20 wildcard.
 
Jiankang Yao
 
 
> Andrew's SOPA record has the same&= nbsp;problem, you'd need to put a SOPA = record 
> at every name that exists in = the DNS subtree, which would be a very&= nbsp;
> difficult provisioning problem.
> 
> Regards,
> John Levine, johnl@taugh.com, Taughannock&nb= sp;Networks, Trumansburg NY
> Please consider the environment before&= nbsp;reading this e-mail.
 
------=_001_NextPart673446243473_=------ From nobody Wed Nov 11 22:53:20 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828861B2A14 for ; Wed, 11 Nov 2015 22:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 aUko9eCvUdib for ; Wed, 11 Nov 2015 22:53:17 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 A5AAA1B2A10 for ; Wed, 11 Nov 2015 22:53:17 -0800 (PST) Received: by vkgy188 with SMTP id y188so5055460vkg.1 for ; Wed, 11 Nov 2015 22:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mNJODO+8Bdin0YukFuxRT3QuqJk/TCrI3IsCuK9wGLI=; b=HoDRp9ZBcWCmJZLiOt4Id6DiLnUM1H2IeGen8qywSGVKK0AlceQNtDegnxZhEaDK2e vnpyFObWUcxOU1pKw6IkR2nQQqULj1dfaKn7m1IrEFfMoxpvHiweFYbWMhAz0vgwoe4K ayqjDR0+bXH3f8U87FCqNX6FxRTJCShS1/1u5gi+CHMvmraeM+nSQkziXiC7SmI2cK8b EUrhvwWFvTkAJjqEkYwcPW/GTXMvkF+qNmwchySXpoDWm4Nb93+ARqDZhYemSm6ZOgQZ pMjWHpMuEAoEGgDIeBFICX6bTXW4mTCiTA5iaQphe4M0wJhHvOyQXJjOt1lCVEVJpbPo N5wA== MIME-Version: 1.0 X-Received: by 10.31.141.130 with SMTP id p124mr1677918vkd.144.1447311196744; Wed, 11 Nov 2015 22:53:16 -0800 (PST) Received: by 10.103.83.73 with HTTP; Wed, 11 Nov 2015 22:53:16 -0800 (PST) In-Reply-To: References: <87si4cnfv0.fsf@alice.fifthhorseman.net> Date: Wed, 11 Nov 2015 22:53:16 -0800 Message-ID: From: "Murray S. Kucherawy" To: Casey Deccio Content-Type: multipart/alternative; boundary=001a11425a4ec2ef410524526555 Archived-At: Cc: Daniel Kahn Gillmor , "dbound@ietf.org" Subject: Re: [dbound] New version of draft-deccio-dbound-organizational-domain-policy X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 06:53:19 -0000 --001a11425a4ec2ef410524526555 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 11, 2015 at 7:06 PM, Casey Deccio wrote: > >> 1) I thought that the hijacking of TXT records in the way SPF did it >> was frowned upon by the DNS community. The SPF research has a page >> and a half of text about why the TXT record ended up winning for >> them and the dedicated RRTYPE lost, but it seems like a cautionary >> tale rather than something to emulate: >> >> https://tools.ietf.org/html/rfc6686#appendix-A >> >> Shouldn't this use a dedicated RRTYPE from the start instead of a >> custom (and therefore otherwise-globally-forbidden) label and a TXT >> record? Implementors can use the "private use" range initially for >> experimentation and request an early assignment if we think this is >> the way to go: >> >> >> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 >> > > I'm not married to TXT, but it's certainly the path of least resistance > for a solution like this. And SPF isn't alone here: don't forget DKIM and > DMARC, the latter of which was approved earlier this year. There could be > discussion on this, but the precedent is there. > The general tension here -- and I'm sure I'm over-simplifying it somewhat -- is that the DNS community absolutely insists that the right thing to do is a new RRTYPE, while operators absolutely insist that that's not pragmatic because nearly all DNS provisioning systems short of editing your own zone files don't include easy support for new RRTYPEs. There are also other operational concerns. We summarized these issues in the SPFBIS working group here: http://tools.ietf.org/html/rfc6686#appendix-A If we try to push a DBOUND solution that involves further overloading of TXT, we should probably expect to have that battle again. -MSK --001a11425a4ec2ef410524526555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 11, 2015 at 7:06 PM, Casey Deccio <casey@decci= o.net> wrote:

=C2=A01) I thought that the hijacking of TXT records in the way SPF did it<= br> =C2=A0 =C2=A0 was frowned upon by the DNS community.=C2=A0 The SPF research= has a page
=C2=A0 =C2=A0 and a half of text about why the TXT record ended up winning = for
=C2=A0 =C2=A0 them and the dedicated RRTYPE lost, but it seems like a cauti= onary
=C2=A0 =C2=A0 tale rather than something to emulate:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/htm= l/rfc6686#appendix-A

=C2=A0 =C2=A0 Shouldn't this use a dedicated RRTYPE from the start inst= ead of a
=C2=A0 =C2=A0 custom (and therefore otherwise-globally-forbidden) label and= a TXT
=C2=A0 =C2=A0 record?=C2=A0 Implementors can use the "private use"= ; range initially for
=C2=A0 =C2=A0 experimentation and request an early assignment if we think t= his is
=C2=A0 =C2=A0 the way to go:

=C2=A0 =C2=A0 =C2=A0 https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#= dns-parameters-4

I'm not= married to TXT, but it's certainly the path of least resistance for a = solution like this.=C2=A0 And SPF isn't alone here: don't forget DK= IM and DMARC, the latter of which was approved earlier this year.=C2=A0 The= re could be discussion on this, but the precedent is there.
=

The general tension here= -- and I'm sure I'm over-simplifying it somewhat -- is that the DN= S community absolutely insists that the right thing to do is a new RRTYPE, = while operators absolutely insist that that's not pragmatic because nea= rly all DNS provisioning systems short of editing your own zone files don&#= 39;t include easy support for new RRTYPEs.=C2=A0 There are also other opera= tional concerns.

We summarized these issues in the SPFBIS= working group here: http://tools.ietf.org/html/rfc6686#appendix-A

If = we try to push a DBOUND solution that involves further overloading of TXT, = we should probably expect to have that battle again.

-MSK=
--001a11425a4ec2ef410524526555-- From nobody Thu Nov 12 05:51:57 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8059D1A8AE6 for ; Thu, 12 Nov 2015 05:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 ae_Z1C_8U9ms for ; Thu, 12 Nov 2015 05:51:55 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 D47561A8AD9 for ; Thu, 12 Nov 2015 05:51:54 -0800 (PST) Received: by wmvv187 with SMTP id v187so33943539wmv.1 for ; Thu, 12 Nov 2015 05:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/PSn+Eif9kKFSPqupd7r3Sbyp+EfGJgyPsuDO/r0RI0=; b=RGod/7ZKdFydrL/4EC5lU1W8wB8KM8k4xyWe7QOIu8OjePL0SH5LWg4gqWaUEm5cay 8vjdeUg0Dnf0LDRsJRcN7Lx/n2S+qovVsQmzgZ8NQxt5TjNqbpxfauiN4BNmnzPp3Pst IxAIEBMYm5H8jionoEERam6TC5cDTcrgUR6MM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/PSn+Eif9kKFSPqupd7r3Sbyp+EfGJgyPsuDO/r0RI0=; b=PS2hCmw7I3JMT4hu6WUWRRDG7GtjNBRCgNMO53TRpEPc3UQ1feDsZ2LxPm+7RKlbSR ftURhR9O9v5oTz/ym2fXJayadjRc+AEyTqh29UUPnJwLPkgUY5jWTToRDXCfoBfQZBOs Ot3so9diItxrxWoiTRAgOFB8FOxBQMN+GiJO5msw6Id/2HiPt/46doXKP1tf5RuV34+q ZQZrvo+MwDdcpL4RPGiTdGSegaU2rgiryL/DZATwpt0eB5RT+9/j6gfNRx8g3kqiHWKa PCBReXvIZ22LYsCipgF0w2OOcQYUZEycm1YZjHCq/ySKU72mLEtbOUiXvNwuU9abcBwb w48A== X-Gm-Message-State: ALoCoQmtFy4LBQMfWQZXrkWCMW6A5t5wr8I8MKO/OJ/Oh2L476MRVTcfH6/2+U5WQC+EVxwdvwCv MIME-Version: 1.0 X-Received: by 10.194.57.142 with SMTP id i14mr18814385wjq.24.1447336313187; Thu, 12 Nov 2015 05:51:53 -0800 (PST) Received: by 10.195.12.137 with HTTP; Thu, 12 Nov 2015 05:51:53 -0800 (PST) In-Reply-To: References: <87si4cnfv0.fsf@alice.fifthhorseman.net> Date: Thu, 12 Nov 2015 08:51:53 -0500 Message-ID: From: Casey Deccio To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=047d7ba97d24d18d1e0524583e0b Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] New version of draft-deccio-dbound-organizational-domain-policy X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 13:51:56 -0000 --047d7ba97d24d18d1e0524583e0b Content-Type: text/plain; charset=UTF-8 On Wed, Nov 11, 2015 at 10:06 PM, Casey Deccio wrote: > > DNSSEC validation requires extra queries for DNSKEY and DS records, but > remember we're working within the same namespace as the names we're looking > up. So there aren't any extra queries. > Minor update: if the _odup subdomain space (at any level, not just the root level) is delegated (i.e., in the form of a DNS delegation, with NS records), then, if signed, there would be additional queries for DNSKEY and DS for that zone. However, the worst case (but highly unlikely) number of "extra" queries is 2n, which is O(n), not O(n^2). Casey --047d7ba97d24d18d1e0524583e0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 11, 2015 at 10:06 PM, Casey Deccio <casey@de= ccio.net> wrote:

DNSSEC validation req= uires extra queries for DNSKEY and DS records, but remember we're worki= ng within the same namespace as the names we're looking up.=C2=A0 So th= ere aren't any extra queries.

Minor update: i= f the _odup subdomain space (at any level, not just the root level) is dele= gated (i.e., in the form of a DNS delegation, with NS records), then, if si= gned, there would be additional queries for DNSKEY and DS for that zone.=C2= =A0 However, the worst case (but highly unlikely) number of "extra&quo= t; queries is 2n, which is O(n), not O(n^2).

Casey
--047d7ba97d24d18d1e0524583e0b-- From nobody Thu Nov 12 08:41:25 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469061B3005 for ; Thu, 12 Nov 2015 08:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 jq6xnpJ3SNAZ for ; Thu, 12 Nov 2015 08:41:21 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 206B21B2AF8 for ; Thu, 12 Nov 2015 08:41:21 -0800 (PST) Received: by wmww144 with SMTP id w144so96532709wmw.0 for ; Thu, 12 Nov 2015 08:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mMdXvaBi9VoWVrYjDSPCf/8wQEyoje1LyybOjl8IYbg=; b=X8nbV4FBHG2hafQnpbmQR5i9AHCFIrPWE9rGfv5et10YG/m986J7ORQp7B3JFaaLe2 /jL0Huwr2xACdRny8+z0uPPdYLZDFuDPKjXG6VD1+uOwaJwdYrApzM5gr907ciz2BsoT TpiLZ8Kz6Dso4wFeI/YBjrvLJ/LCBrC5lC32k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mMdXvaBi9VoWVrYjDSPCf/8wQEyoje1LyybOjl8IYbg=; b=GjBPil3YFYVDBqURchK3jwdj1YhbpPEBe0jKqXs/RRC3FhzFmGqRvDoH7YAUXLPkg3 nESO4GsXRaD5Gz/feei/5z/KH8ctqQGjN5Bq4VT6sr3YMDg5rwdueAW4t06SHmhQmMYU 94hIy1Cddo+eFFQi1+y38P9Ncp0XzTSJhOmPU7E4EYdh3wxcbFTUCOF8COYXqYoC0RW9 7y/L/qsuFAbuI+f+iqCpl7gq/Vus1/lo+gqPWijZw20FusZOa4Qhy4SwKpXnLVWQzlM5 HXXvaTU1LMywUBoVu8R7L2q1G8/VRmcnqRWVtq+9Q/2Pn8/O7kYkwRN7caYcEoGkRn/O ETfA== X-Gm-Message-State: ALoCoQmOdje6xWFhVMRaPsUURVOSzGK5Vosf+G9zk5nLrdDame6Hg82rA90URoex56I1wMVlZOY0 MIME-Version: 1.0 X-Received: by 10.28.216.196 with SMTP id p187mr49631978wmg.14.1447346479370; Thu, 12 Nov 2015 08:41:19 -0800 (PST) Received: by 10.195.12.137 with HTTP; Thu, 12 Nov 2015 08:41:19 -0800 (PST) In-Reply-To: <20151112021154.2231.qmail@ary.lan> References: <20151112021154.2231.qmail@ary.lan> Date: Thu, 12 Nov 2015 11:41:19 -0500 Message-ID: From: Casey Deccio To: John Levine Content-Type: multipart/alternative; boundary=001a11469002c56da705245a9c13 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Updated draft-levine-orgboundary-03 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 16:41:23 -0000 --001a11469002c56da705245a9c13 Content-Type: text/plain; charset=UTF-8 Hi John, On Wed, Nov 11, 2015 at 9:11 PM, John Levine wrote: > Not to toot my own horn or anything, but I really think this does most > of what people have said they want DBOUND to do, published in the DNS, > with each domain publishing its own info in the tree it controls, no > new TLDs or other administratively painful changes, provision for > different boundaries for different applications, and most checks in > one or two DNS queries regardless of how deep the name tree is. > > What's not to like? > > I've given the draft a detailed read. In general, the approach is admittedly very similar to that in draft-deccio-dbound-organizational-domain-policy (ODUP) Some differences are a matter of preference, and others have more technical implications. - Both drafts use "opt-out" models. - Terminology concerns (nits): - Boundaries vs. policies: both drafts mention boundaries and policies. While there are similarities, and in particular, policies often utilize boundaries, they aren't one and the same. Yet that they seem to be portrayed as such in the draft. - "Organization" (e.g., "belongs to the same organization"). The way I understand the understand "organization" doesn't coincide with how it is used in this draft. I don't think of an organizational boundary as something associated with a service or policy. For example, I don't see how a cookie policy changes the organizational boundary between two domains. I see "policy boundary" on occasion. Perhaps the two simply need to be reconciled. - Lookup process - the process is very similar to that in ODUP. Some similarities and differences follow: - They both have iteration-stopping mechanisms (NXDOMAIN for ODUP; NOLOWER for the current draft). - The current draft begins queries at the TLD, rather than at the root (well, the _odup TLD anyway). - The current draft uses the entire DNS name (plus the _bound label) to create the qname to be queried; in ODUP, each label is considered separately. There are revealing components to both (discussed on the ODUP draft and in other email threads), but the latter is the more conservative approach. - There is no "default" policy behavior in the current draft; the default policy behavior in ODUP is current behavior. - There is no mechanism for offline lookup in the current draft, contrasted with the ability to download policy realms (including the policy-negative realm and other high-profile realms) for local use in the ODUP draft. - Because one record for each service/policy is required, there are potentially n*m lookups. So while the performance is O(n) for any given service, it is O(n*m) for all services/policies. Some applications would require understanding of multiple policies. Contrast this with a hard O(n) with ODUP, which has a consolidated service list. - The following is a confusing sentence for "boundary node": "the one above the closest node to the root that also belongs to the same organization as the input domain name." It is somewhat clarified by the sentence immediately after, but the qualifiers in the sentence itself are ambiguous. - Why the use of wildcards? The time complexity doesn't improve with this. It just seems like added complexity, so you can query for the entire name, rather than label-by-label. But as, mentioned previously, this is revealing to higher level DNS authorities. - What would be the road map to deploy this "now", given existing application behavior? This was one of the big reasons for the design of ODUP: to provide a mechanism that is backwards compatible with existing behaviors and has a transition path for expansion, with the idea that it is technically capable of going "now". Cheers, Casey --001a11469002c56da705245a9c13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

On Wed, Nov 11, 2015 at 9:11 PM, John Levine <johnl@taugh.c= om> wrote:
Not to toot my own horn or anything, but I really think this does most of what people have said they want DBOUND to do, published in the DNS,
with each domain publishing its own info in the tree it controls, no
new TLDs or other administratively painful changes, provision for
different boundaries for different applications, and most checks in
one or two DNS queries regardless of how deep the name tree is.

What's not to like?



I've given the draft a detaile= d read.=C2=A0 In general, the approach is admittedly very similar to that i= n draft-deccio-dbound-organizational-domain-policy (ODUP)=C2=A0 Some differ= ences are a matter of preference, and others have more technical implicatio= ns.

- Both drafts use "opt-out" models.

=
- Terminology concerns (nits):
=C2=A0 - Boundaries= vs. policies: both drafts mention boundaries and policies.=C2=A0 While the= re are similarities, and in particular, policies often utilize boundaries, = they aren't one and the same.=C2=A0 Yet that they seem to be portrayed = as such in the draft.
=C2=A0 - "Organization" (e.g., "bel= ongs to the same organization").=C2=A0 The way I understand the unders= tand "organization" doesn't coincide with how it is used in t= his draft.=C2=A0 I don't think of an organizational boundary as somethi= ng associated with a service or policy.=C2=A0 For example, I don't see = how a cookie policy changes the organizational boundary between two domains= .=C2=A0 I see "policy boundary" on occasion.=C2=A0 Perhaps the tw= o simply need to be reconciled.

- Lookup process - the pr= ocess is very similar to that in ODUP.=C2=A0 Some similarities and differen= ces follow:
=C2=A0 - They both have iteration-stopping mechan= isms (NXDOMAIN for ODUP; NOLOWER for the current draft).
=C2= =A0 - The current draft begins queries at the TLD, rather than at the root = (well, the _odup TLD anyway).
=C2=A0 - The current draft uses= the entire DNS name (plus the _bound label) to create the qname to be quer= ied; in ODUP, each label is considered separately.=C2=A0 There are revealin= g components to both (discussed on the ODUP draft and in other email thread= s), but the latter is the more conservative approach.
=C2=A0 = - There is no "default" policy behavior in the current draft; the= default policy behavior in ODUP is current behavior.
=C2=A0 = - There is no mechanism for offline lookup in the current draft, contrasted= with the ability to download policy realms (including the policy-negative = realm and other high-profile realms) for local use in the ODUP draft.
=C2=A0 - Because one record for each service/policy is required, there = are potentially n*m lookups.=C2=A0 So while the performance is O(n) for any= given service, it is O(n*m) for all services/policies.=C2=A0 Some applicat= ions would require understanding of multiple policies.=C2=A0 Contrast this = with a hard O(n) with ODUP, which has a consolidated service list.
=
- The following is a confusing sentence for "boundary n= ode":
=C2=A0= "the one above the closest node to the root that also belongs to the same organization as the input domain name."=C2=A0
I= t is somewhat clarified by the sentence immediately after, but the qualifie= rs in the sentence itself are ambiguous.

- Why the use of wildcards?= =C2=A0 The time complexity doesn't improve with this.=C2=A0 It just see= ms like added complexity, so you can query for the entire name, rather than= label-by-label.=C2=A0 But as, mentioned previously, this is revealing to h= igher level DNS authorities.

- What would be the road map= to deploy this "now", given existing application behavior?=C2=A0= This was one of the big reasons for the design of ODUP: to provide a mecha= nism that is backwards compatible with existing behaviors and has a transit= ion path for expansion, with the idea that it is technically capable of goi= ng "now".

Cheers,
Case= y
--001a11469002c56da705245a9c13-- From nobody Thu Nov 12 08:57:57 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AC31B3041 for ; Thu, 12 Nov 2015 08:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 p9yE-ysmfXnQ for ; Thu, 12 Nov 2015 08:57:55 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 63E111B303E for ; Thu, 12 Nov 2015 08:57:55 -0800 (PST) Received: by wmec201 with SMTP id c201so101134260wme.1 for ; Thu, 12 Nov 2015 08:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UTwA7NefRpFeA27f9UKEsGYR6yrIGhS6oWLoivPU7Dk=; b=OIv3tdK/d1LE2I+4NmCpQ36ryOtAy9T10zBhKwRZSSNZF7ejEP4BrSWDZh75msRZFh 77lehb03o7zPAWYnnC5I+4k3HwjpHZgS6L9q9lL37CYuQsi0Jxh5/0zmYhlgoMqIA/aa xMtm01ZG6hMCiT/Crqb6cj12uhSDEC9BAtsb4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UTwA7NefRpFeA27f9UKEsGYR6yrIGhS6oWLoivPU7Dk=; b=AQBMAZ/C6sZDpUSG7+pCAtoOsVwWiAAfCP+UK0PIplO5twJfkRvojZqTSzDJfDXvB+ nNRsUVP3LPcYCF1nDmAy6LHoR3YhByFJ2agyleya9BiqRtfJQAq2/4Z7G6f3DOp1KW1T P4WI2/HPWF0NKGst/4l1XWAipO5NMLQh9vzStlAr1FG+b3SDiFOHO6WHwBY9Txu/Qeu8 Ul1+/oZvzwY9FYAbgtEXW2B4xLeMEoHvXRrb7IDrKNvwuxgCUfmlKQjY1DMwGov5AwyW sc9C2P8jQZwd/B7D2/8xSwU4DFxGVa1B+aeAMYFRgo/xJKpp4OxBZta/6Kokm1dloGuW qDiQ== X-Gm-Message-State: ALoCoQni0V/dT+Sc34pBpu90zLnnu6CBZB/9kMcglnGWCud/nsBnlj8uZQvZ0cX3WfDEgOnEEUho MIME-Version: 1.0 X-Received: by 10.28.129.131 with SMTP id c125mr41327305wmd.21.1447347473956; Thu, 12 Nov 2015 08:57:53 -0800 (PST) Received: by 10.195.12.137 with HTTP; Thu, 12 Nov 2015 08:57:53 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Nov 2015 11:57:53 -0500 Message-ID: From: Casey Deccio To: John R Levine Content-Type: multipart/alternative; boundary=001a114247f60d637705245ad817 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Updated orgboundary draft X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 16:57:56 -0000 --001a114247f60d637705245ad817 Content-Type: text/plain; charset=UTF-8 Hi John, On Mon, Nov 9, 2015 at 4:43 AM, John R Levine wrote: > I've updated my old orgboundary draft to address issues that showed up > recently. It's sort of like Casey's draft but it's much simpler, and every > domain publishes its own info in its own namespace. > "Much simpler" is somewhat subjective. If you could provide some detailed, objective feedback and comparisons, that would be useful. Thanks, Casey --001a114247f60d637705245ad817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

On Mon, Nov 9, 2015 at 4:43 AM, John = R Levine <johnl@taugh.com> wrote:
I've update= d my old orgboundary draft to address issues that showed up recently.=C2=A0= It's sort of like Casey's draft but it's much simpler, and eve= ry domain publishes its own info in its own namespace.

"Much simpler" is somewhat subjective.=C2=A0 If y= ou could provide some detailed, objective feedback and comparisons, that wo= uld be useful.

Thanks,
Casey
--001a114247f60d637705245ad817-- From nobody Thu Nov 12 09:05:41 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B401B306D for ; Thu, 12 Nov 2015 09:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 FlPpsrU02qAP for ; Thu, 12 Nov 2015 09:05:39 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9541B3070 for ; Thu, 12 Nov 2015 09:05:38 -0800 (PST) Received: (qmail 43302 invoked from network); 12 Nov 2015 17:05:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a925.5644c6e2.k1511; bh=Dz0mWIkYLrG2rrZZpVZ2GtV4UCP/MSLbK8xIHEmOXyw=; b=nEA5fHRkIZEXOLtjM9DNUB92gSBFS85LnluY6YiJVuTfZv45otK1qQjEP9ZxvsJuK1gX7psGyQFI/MCKXujS4ZfPVeF23VBv1HhntF9WWxROf3vZv9TlwnK5G9CgG9v836d/1wRkzzFY4X/ixNpOoQqKQRAEE0xl+YRAAn8Ji4VG0mwNmGUR2+O7OQ44XQi8U7Ebcs/0h9G0lYAAC/rDBSnyNpnmjDd6iMWn/gYc/T8Ro8wf1wwN5jZOEi4tDs8/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a925.5644c6e2.k1511; bh=Dz0mWIkYLrG2rrZZpVZ2GtV4UCP/MSLbK8xIHEmOXyw=; b=oLq1leHU9GsVnvyCeWPI+j4dbzrtjrRaE3rlOrfBfgtFpyvRgOV2ut+Q7eeSyrYybpNNohyu776PjPN1qfQhcYAtIWtSAKdV7wAsK9LKZ3giPCYJlRAarQ3ZZQ/RBxY9k7FWOUbN2c3ERUjkPdVDhTI6+3ASChXHDmez0rQWpZlpPY3l56y5WiJ+ZeIARlLFMXBOEnRwadypL4nWu3y+4jFMCkTUNoduLMBpm0OwrUNJ1qgxtTpy3UGUmL4TTU4W Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 12 Nov 2015 17:05:37 -0000 Date: 12 Nov 2015 12:05:37 -0500 Message-ID: From: "John R Levine" To: "Casey Deccio" In-Reply-To: References: <20151112021154.2231.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Updated draft-levine-orgboundary-03 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 17:05:40 -0000 > - Why the use of wildcards? The time complexity doesn't improve with > this. It just seems like added complexity, so you can query for the entire > name, rather than label-by-label. But as, mentioned previously, this is > revealing to higher level DNS authorities. Wildcards make the lookup O(1) rather than O(N). I think that's an important difference. > - What would be the road map to deploy this "now", given existing > application behavior? The obvious approach would be to write some libraries with interfaces similar to what people use for the PSL now and swap it in. I suppose that for a while it could default back to the PSL if it doesn't find any BOUND records in the DNS. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Nov 12 09:06:47 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5471B306D for ; Thu, 12 Nov 2015 09:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 HHbUArxxa03j for ; Thu, 12 Nov 2015 09:06:45 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3E41B3074 for ; Thu, 12 Nov 2015 09:06:38 -0800 (PST) Received: (qmail 43437 invoked from network); 12 Nov 2015 17:06:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a9ac.5644c71d.k1511; bh=9QwgFjOrIk040FLJDNe9q4a40pfIXCtt7tIDng2ylxo=; b=T6wa3mtscHk+C63v6B2oGrRzw9koezNKOjtVk9NTq44GRZgxDKVK5Zap584v/PCi5LcuapdH286kf3/zRFWoAcG1320yhYE66bd+SdaHzBVTjgDzAxymvMPhJaY0odqk2LfNa/F7r3YIMQgc8klcjZMpQ5o+tAJ0E6enYe1o6YBCr/8EGp6RPtT6G+WBOCv6prDjaFo/kcmw0bDOsh55pcgVYedTmRnabaf7SzEHXQmKFqwRPS7JviC3ZUccyw4E DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a9ac.5644c71d.k1511; bh=9QwgFjOrIk040FLJDNe9q4a40pfIXCtt7tIDng2ylxo=; b=FM6XVBXPPz+adO3Unb8n5kJV3fqKkPPbG+wu52E3jSaba7EYsUJ6fIZCk43WjDTzOW19EPlx0BCvNIHJaK/FomlIBuu+2dxXZwycMbmj6OUNApBw1pBNRTVrBA/OkdRCcyQpad+rvgekYIB2W5s115qvGgucyzqMPCgF6pwcWBjR0WlqJuygnLc2ubsFGkjd9dgkoU1iaNjU81lTC1Xwjt+cGMFgt0aebkaKJJj4YY3xkSfVAbpELkmexKHbgbYO Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 12 Nov 2015 17:06:37 -0000 Date: 12 Nov 2015 12:06:36 -0500 Message-ID: From: "John R Levine" To: "Casey Deccio" In-Reply-To: References: User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Updated orgboundary draft X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 17:06:46 -0000 > "Much simpler" is somewhat subjective. If you could provide some detailed, > objective feedback and comparisons, that would be useful. I think we should let other people look at them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Nov 12 09:09:19 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF051B3081 for ; Thu, 12 Nov 2015 09:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 45tjMNNCs3tN for ; Thu, 12 Nov 2015 09:09:16 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40AB1B3080 for ; Thu, 12 Nov 2015 09:09:15 -0800 (PST) Received: (qmail 43795 invoked from network); 12 Nov 2015 17:09:14 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 12 Nov 2015 17:09:14 -0000 Date: 12 Nov 2015 17:08:51 -0000 Message-ID: <20151112170851.5367.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dbound] new rrtype vs. txt X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 17:09:18 -0000 >The general tension here -- and I'm sure I'm over-simplifying it somewhat >-- is that the DNS community absolutely insists that the right thing to do >is a new RRTYPE, while operators absolutely insist that that's not >pragmatic because nearly all DNS provisioning systems short of editing your >own zone files don't include easy support for new RRTYPEs. There are also >other operational concerns. SPF has the unusual problem of using TXT records at unprefixed names, which means they are in the same RRSET with TXT records that are used for other stuff. We got a lot less hate for DKIM since those TXT records are at names with _domainkey prefixes. My thing would work either way, although it seems somewhat cleaner with its own RRTYPE. R's, John From nobody Thu Nov 12 09:13:36 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E581A001B for ; Thu, 12 Nov 2015 09:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=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 b--m86aGbwyF for ; Thu, 12 Nov 2015 09:13:33 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323FA1A0016 for ; Thu, 12 Nov 2015 09:13:33 -0800 (PST) Received: by wmww144 with SMTP id w144so209732588wmw.1 for ; Thu, 12 Nov 2015 09:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5tKusFxF47EHwcJgF+zElHWszHOdQ4vj/dt6daRD08Y=; b=M0Fb5wrTUC5iepBnadmSIVlb33qNghoxdQaSwxIB/qUsCVkP3zJimzXMRKeKmPQepD zXcvHF/q49+V9HdR5XWgVsGf2I6wyMwEwdVx0qLGJk3I+a/oeINjZF5gD2NEgo0NkunI ZyBKvF2oFjr5vifCdGz3jbHndvmi/CEHc8Dlw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5tKusFxF47EHwcJgF+zElHWszHOdQ4vj/dt6daRD08Y=; b=AMAC9vpaZuWcf8mHrNPVTAnpeQKWLTAwraVgGH6S0zbWavaYJjxpzQe2ytcdNQd/eZ z0BxtyVsGlrtjbXhaW6KliL/oaAwIzec2wQF5EoGlDxyWZZwVnArRHEt4xZICfQugZF5 5wHw8wfPP5ZyIoJXErBDcjw42k4EuE0mko5uOtXza0oNllo1GJSHdt7cf25D+kAv+H0i +fBCJ/+hcvlmfNnOJBSml7Ix/MXkmmqsblrgcRc5Tnm3qJKH6Svmk0b3vEpgTP3B6/ro pcZeCzuDEowv0jMyGjcHSUKLMrtnwxcPQ9PAnI3UXWH+whcMd/bgMD4RI/ZZJQqmG3Ym QBuQ== X-Gm-Message-State: ALoCoQkp1y/6H71Y21xvv9S1npOLIeA8A9wvVV6PgsvXXdW3MzztmHhe7C6NyIfodkKh0QdaOWtA MIME-Version: 1.0 X-Received: by 10.28.129.131 with SMTP id c125mr41419624wmd.21.1447348411710; Thu, 12 Nov 2015 09:13:31 -0800 (PST) Received: by 10.195.12.137 with HTTP; Thu, 12 Nov 2015 09:13:31 -0800 (PST) In-Reply-To: References: <20151112021154.2231.qmail@ary.lan> Date: Thu, 12 Nov 2015 12:13:31 -0500 Message-ID: From: Casey Deccio To: John R Levine Content-Type: multipart/alternative; boundary=001a114247f6f2500a05245b0fd0 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Updated draft-levine-orgboundary-03 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 17:13:34 -0000 --001a114247f6f2500a05245b0fd0 Content-Type: text/plain; charset=UTF-8 Hi John, On Thu, Nov 12, 2015 at 12:05 PM, John R Levine wrote: > - Why the use of wildcards? The time complexity doesn't improve with >> this. It just seems like added complexity, so you can query for the >> entire >> name, rather than label-by-label. But as, mentioned previously, this is >> revealing to higher level DNS authorities. >> > > Wildcards make the lookup O(1) rather than O(N). I think that's an > important difference. Big-O notation characterizes the upper bound of algorithmic complexity. The lookup process is bounded by n iterations. Wildcards do not change the upper bound to a constant lookup time. Just as the NXDOMAIN in ODUP does not change its time complexity from O(n) to O(1). The bounding remains O(n) in the current draft--or O(n*m) if you consider the service lookups. Casey --001a114247f6f2500a05245b0fd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

On Thu, Nov 12, 2015 at 12:05 PM, Joh= n R Levine <johnl@taugh.com> wrote:
- Why the use of wildcards?=C2=A0 The time complexity doesn't improve w= ith
this.=C2=A0 It just seems like added complexity, so you can query for the e= ntire
name, rather than label-by-label.=C2=A0 But as, mentioned previously, this = is
revealing to higher level DNS authorities.

Wildcards make the lookup O(1) rather than O(N).=C2=A0 I think that's a= n important difference.

Big-O notation char= acterizes the upper bound of algorithmic complexity.=C2=A0 The lookup proce= ss is bounded by n iterations.=C2=A0 Wildcards do not change the upper boun= d to a constant lookup time.=C2=A0 Just as the NXDOMAIN in ODUP does not ch= ange its time complexity from O(n) to O(1).=C2=A0 The bounding remains O(n)= in the current draft--or O(n*m) if you consider the service lookups.
Casey
--001a114247f6f2500a05245b0fd0-- From nobody Thu Nov 12 09:27:44 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A737A1B2A93 for ; Thu, 12 Nov 2015 09:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 NfNyqgwGZQoM for ; Thu, 12 Nov 2015 09:27:41 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05E81B2A92 for ; Thu, 12 Nov 2015 09:27:40 -0800 (PST) Received: (qmail 47362 invoked from network); 12 Nov 2015 17:27:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b900.5644cc0b.k1511; bh=MYTcTvDb6aHaXBkx0U+VhFguOzpOg2fLThsgiVjhk4s=; b=aTz6E/UkhHWnShbV6n2QP4Fs3MiYjvgtd7EzWEDNVdK0VGHaDQil4LTSBMMvEEMsrmYw/dPtESkB6IVaSAICQwz1vnGJ8zCweQ7bSnlDec+neGWwDXbLQ9ToKu41OJCzeEHhWZIdnxZVcC++xnnVrWRZxqV5zvqDyiaAeKZI8PxoaM8rF+keYy8h02RlfS6QEuf5qa4kUYYQgY8ExVCCNwMpwPugWOXWKFgrQKtlhVm5el09W16i62N8cJVw+rXW DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b900.5644cc0b.k1511; bh=MYTcTvDb6aHaXBkx0U+VhFguOzpOg2fLThsgiVjhk4s=; b=SPG8Hluvl+wAlPeoJjMYoe9IjdjKXUSQovOv+N2YmJOaxbOubGsua/OyACXCgO9OL+WGDbukkZTM+u6kOSv4ZULBkv6F6oz0n3ub/xuNE9iTTV8FlyKBVbRt5J8DpJ5onyc7BJKGB7TUkg8mUn91WkkHk/ev/eLA3nZghLiUuh6Nmix1cLeu7ULN/LFVIdPzlrz3R+w8hcbqfsWOC/rH2Ra5CmnNSbUiItJ5spUj1MfjIAADAQ5kNapFbBD2FcE6 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 12 Nov 2015 17:27:39 -0000 Date: 12 Nov 2015 12:27:38 -0500 Message-ID: From: "John R Levine" To: "Casey Deccio" In-Reply-To: References: <20151112021154.2231.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Updated draft-levine-orgboundary-03 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 17:27:41 -0000 >> Wildcards make the lookup O(1) rather than O(N). I think that's an >> important difference. > > Big-O notation characterizes the upper bound of algorithmic complexity. Yes, I know. My scheme will typically make one or two DNS queries regardless of the length of the DNS name. Yours appears to do a tree walk for each name component. My assumption is that each request is likely to be for a particular application. If you need to enumerate the boundaries for M services, that will take M times as long but that doesn't seem like a very common situation. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Nov 12 09:38:33 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF6A1B2AD1 for ; Thu, 12 Nov 2015 09:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 4XOwFzwuBXk8 for ; Thu, 12 Nov 2015 09:38:31 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 C0D091B2ACD for ; Thu, 12 Nov 2015 09:38:30 -0800 (PST) Received: by wmdw130 with SMTP id w130so164531400wmd.0 for ; Thu, 12 Nov 2015 09:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4bvtPAwRR+AmjOTLoPVBWv+gkmdFhO9GqcamLuEL028=; b=AF8Y1LLqHqDaLx6mzaLlL8dvCLFUNhIlz8/XGs4s3X9QA3XrJ2bDOEWbaLx2fJlvX5 +61i14b1MgO7ixn2a8VD0Bss3ALEBDC4yEfgUIv+sYxdFdNBZpFq44CC6fjv8If1Y4An tTiOPOyUpOyq2CXP77fyYH0y5icaK7hT21EzU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4bvtPAwRR+AmjOTLoPVBWv+gkmdFhO9GqcamLuEL028=; b=YUgHaebh7bRjnTw9O3J97WZpNOVgzb159xh3rpmqqqYDaoFsc9wRNtTYCEoQFMjftJ feptmnm2MAGAq4dNO+/an2PWo8/QL+1cyze3lNTemrRvFacfHh3Ckgh9baaVdjDz/b2w Zqr6YuVXrN3FkVn508JowZ99rbKEL9qWRpYutEMyc4rfyDUFsFREa9/hIt59+jEDaidE KH5mrKQCHkzM4cXFtddgtGyYDmMqvlgt+JwxZOg95qvKeBvJYfoJlYZLaT5cJic+nVyZ +B9alNF7PsDJ3M7ayej5xf7U04S0w8d+ZPQWyPgzSUsqdFHlCkfOmKvLbMFZk9dfCJDL J60w== X-Gm-Message-State: ALoCoQmVjgCx5V92bchAgwQYZafdK6Gt6gI4P4GjR3QITxxixlvQsUmerLV7qIJFJe/8thSWa6JV MIME-Version: 1.0 X-Received: by 10.28.48.213 with SMTP id w204mr17325960wmw.38.1447349909296; Thu, 12 Nov 2015 09:38:29 -0800 (PST) Received: by 10.195.12.137 with HTTP; Thu, 12 Nov 2015 09:38:29 -0800 (PST) In-Reply-To: References: <20151112021154.2231.qmail@ary.lan> Date: Thu, 12 Nov 2015 12:38:29 -0500 Message-ID: From: Casey Deccio To: John R Levine Content-Type: multipart/alternative; boundary=001a11422af435a5fb05245b6916 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Updated draft-levine-orgboundary-03 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 17:38:32 -0000 --001a11422af435a5fb05245b6916 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 12, 2015 at 12:27 PM, John R Levine wrote: > Yes, I know. > > My scheme will typically make one or two DNS queries regardless of the > length of the DNS name. What I'm saying is that "typically" does not dictate complexity; worst case dictates complexity. > Yours appears to do a tree walk for each name component. > As I have mentioned both in this thread and in the draft, iteration stops at an NXDOMAIN--which if I understand correctly, is the equivalent of hitting a wildcard response in your draft. I welcome your detailed read and review of the ODUP draft. My assumption is that each request is likely to be for a particular > application. If you need to enumerate the boundaries for M services, that > will take M times as long but that doesn't seem like a very common > situation. > Assumptions are fine. Commonalities are fine. But again, if you get into the realm of bounding algorithmic complexity, it's all about worst case, upper bounding. Worst case vs. anticipated performance, given the baseline behavior, are also discussed in the ODUP draft. I am belaboring this somewhat because we have drafts whose merits are being discussed on this mailing list, and one of the concerns that has been raised is "complexity". Let's be clear about what that means, so the comparisons are apples to apples. Casey --001a11422af435a5fb05245b6916 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 12, 2015 at 12:27 PM, John R Levine <johnl@tau= gh.com> wrote:
Yes, I know.

My scheme will typically make one or two DNS queries regardless of the leng= th of the DNS name.

What I'm saying is = that "typically" does not dictate complexity; worst case dictates= complexity.
=C2=A0
Yours= appears to do a tree walk for each name component.
As I have mentioned both in this thread and in the draft, iter= ation stops at an NXDOMAIN--which if I understand correctly, is the equival= ent of hitting a wildcard response in your draft.=C2=A0 I welcome your deta= iled read and review of the ODUP draft.

My assumption is that each request is likely to be for a particular applica= tion.=C2=A0 If you need to enumerate the boundaries for M services, that wi= ll take M times as long but that doesn't seem like a very common situat= ion.

Assumptions are fine.=C2=A0 Common= alities are fine.=C2=A0 But again, if you get into the realm of bounding al= gorithmic complexity, it's all about worst case, upper bounding.=C2=A0 = Worst case vs. anticipated performance, given the baseline behavior, are al= so discussed in the ODUP draft.

I am belaboring this some= what because we have drafts whose merits are being discussed on this mailin= g list, and one of the concerns that has been raised is "complexity&qu= ot;.=C2=A0 Let's be clear about what that means, so the comparisons are= apples to apples.

Casey
=
--001a11422af435a5fb05245b6916-- From nobody Thu Nov 19 07:49:20 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78511B2BE6 for ; Thu, 19 Nov 2015 07:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.667 X-Spam-Level: ** X-Spam-Status: No, score=2.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=1.004, SPF_PASS=-0.001] autolearn=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 cSbTwbzgE5Sa for ; Thu, 19 Nov 2015 07:49:17 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76ED21B2BD5 for ; Thu, 19 Nov 2015 07:49:17 -0800 (PST) Received: (qmail 66843 invoked from network); 19 Nov 2015 15:49:16 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Nov 2015 15:49:16 -0000 Date: 19 Nov 2015 15:48:54 -0000 Message-ID: <20151119154854.31079.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dbound] Updated draft-levine-orgboundary-04 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 15:49:18 -0000 I've send along another version of my draft, with some editorial changes prompted by some of Casey's comments. The proposed bits on the wire are the same. It would be nice to get some comments on this from someone other than the two of us. https://datatracker.ietf.org/doc/draft-levine-orgboundary/ R's, John