From nobody Mon Jan 4 15:03:10 2016 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 5B2A51ACCF2 for ; Mon, 4 Jan 2016 15:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 bAoSHJOytIKU for ; Mon, 4 Jan 2016 15:03:07 -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 2A96E1ACCF0 for ; Mon, 4 Jan 2016 15:03:07 -0800 (PST) Received: (qmail 63202 invoked from network); 4 Jan 2016 23:03:05 -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=f6e1.568afa29.k1601; bh=ZgYvkAQlUBHbLxjNE2nQl3kf24aGTUwCK5GVSH3WfWw=; b=Wzr5Pt7VFCMOeMO/uy6SEwgveuw1AXsVa4GWIJNIllX4wRjltTVj6ZHDPtmuxlanx5IZQEakZH/VN+ykmB9iVmFZErKMA20QxDPyDi32skLU7GZVCSDPvGOvDoTehTWBDG12Aead8SKy+scG0f8bCw9OlF+VXGtRlJuq1pY927RdMcnhtVBcqrBB8TjioZg29hVa0TVPRUmfJY0vjwEBvvMe4EKgaa6+owjrpoL6iJxLoioZq06NM0oFlFE78tT4 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=f6e1.568afa29.k1601; bh=ZgYvkAQlUBHbLxjNE2nQl3kf24aGTUwCK5GVSH3WfWw=; b=kqDcy9DHGimwwv/z1bTcj6BHZiy3kRUqa4IFoOCa4NPqj0dItD7MP9VSMTKX0n+oyG2SekLnkK/TtqzqYchluGt4CWPTxmifOvyDSk0Ep3MjVoG/CZg32N2RkjPhyLDMT0uqDhsaumQRONfbyjn8rCYEPmEHDFBm4vrjvl3wrlNNYAmXQRWC4VXQgdnHbtRZ66Lf1FTU2YKfAaswzPKsfn8zZfGEhPDO21B9xA0rjID+7QUvTtSKMBYEHxG7nFRx 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; 04 Jan 2016 23:03:05 -0000 Date: 4 Jan 2016 18:03:05 -0500 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] Expiring drafts, do we care ? 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, 04 Jan 2016 23:03:08 -0000 I just got the usual note that a couple of my dbound drafts are expiring. I'm happy to refresh them, but since there's been no traffic here in a month and a half and no comments on my Nov 19 draft (not one of the expiring ones), perhaps there's no point if nothing more is happening. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Jan 18 16:42:23 2016 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 5F7D81A7005 for ; Mon, 18 Jan 2016 16:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 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, J_CHICKENPOX_37=0.6, 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 abEV8DBU8Van for ; Mon, 18 Jan 2016 16:42:20 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d: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 250F81A7003 for ; Mon, 18 Jan 2016 16:42:20 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id s5so36000082qkd.0 for ; Mon, 18 Jan 2016 16:42:20 -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=lX0nGvSEo2kEdVEnGOn+5g+WBqvskzISjbkfSwK69ac=; b=QgEbt1yEKwFtvXVD7DWUcvjk205s7URU31Vle3hORCxH1eUudbnXjPCLMrg2Pv+tE+ /ummOd5epXD0h9tKKtawBRUtFRopbpAVsCusz6TbHPynPxJXIiqxHHz6LcrKpfL19qMU rfA8oLKdf3by8hxg3+KsDpisgQNqJ0e/LUmyY= 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=lX0nGvSEo2kEdVEnGOn+5g+WBqvskzISjbkfSwK69ac=; b=OMKnh4crXL/kADtev672qrZZY/RSjvi37NBm9MV3FIEU6YVHa1zIcQ8QV/2mPFq6Sh 63vBz1hZ2nOYhV5sLYRkEYQSx7qEWegQTFg0Lt2A5m4joRlntVMnzCCPIkcothAt9c7y 8RodFPhLBXqEw5VDB+2m6+ILuPtluOPhxUR/4WknNkTQkAeC3QE83atk9WLpS9JmpqG/ MqkgY3gpMhLn1yvPVwbIiWBUTS84vDuRFwII6CGsQO/G90OgYU4owH3xj4KheQxPpFu+ Beae7awHEywuBYAz7Jm5Wlhry6JjQsVdIykRvWRF0VyA0XOTnYVuSecHm/UQg7H23msJ FnWQ== X-Gm-Message-State: ALoCoQknjlPvrYNCr91jTVipIak6i4pH/k0kFgKU3pbiYo4HNNXfA4a2RbyYB9ZdCPSluC1xQnQJRWIrvdejwG8m/4iWuhwi8A== MIME-Version: 1.0 X-Received: by 10.55.25.146 with SMTP id 18mr34557899qkz.41.1453164139248; Mon, 18 Jan 2016 16:42:19 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.42.67 with HTTP; Mon, 18 Jan 2016 16:42:19 -0800 (PST) Date: Mon, 18 Jan 2016 16:42:19 -0800 X-Google-Sender-Auth: Qc1GyhgUhGfhs2-Dkpw2xDfkPW8 Message-ID: From: "Kurt Andersen (b)" To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=001a1147b2c05216360529a5247a Archived-At: Subject: [dbound] Thoughts and comments on 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: Tue, 19 Jan 2016 00:42:22 -0000 --001a1147b2c05216360529a5247a Content-Type: text/plain; charset=UTF-8 After considering both draft-levine-orgboundary-04 and draft-deccio-dbound-organizational-domain-policy-01 as examples of what was termed during the Yokohama discussion as a "top down" boundary assertion, I have found it much easier to grok the lookup sequence from John's proposal than the one in Casey's. I'm still not sure that I have entirely grasped the nuances and especially the potential corner-case holes that reside within the algorithm proposed by Casey and I don't see the benefit of supporting an "offline" mode since the applicability of the domain boundary lookups is in dealing with online, real time queries. Question regarding the text: The last paragraph of section 2 says "Each domain publishes its own policies". I take this to mean its own boundaries, but would it be more appropriate to say "Each ADMD publishes its own boundaries"? It seems slightly problematic to be dependent on a (potentially uncooperative) parent domain in order for child domains to be looped into the BOUND framework. Since SOA is an established mechanism within DNS management, would it make the mechanism more resilient to follow the SOA chain before branching off to look for BOUND records? As a security measure, the failure to lookup a terminating record with a NOLOWER bit set seems like its interpretation could be application dependent. In the case of cookies or certs, one may want individual name isolation, but in the case of DMARC, that would enable attacks rather than prevent them. Section 3 (and 10) calls for the applications to be indicated as a lookup table managed by IANA. Why not just have defined application mechanisms which could be comma-separated in the record rather than an encoded numeric value? In section 5, paragraph 3, the draft reads "the record would indicate no boundaries. . ." but then the exemplar record is "*._bound.test IN BOUND 0 0 .". Shouldn't that be "*._bound.test IN BOUND 1 0 ." to indicate no boundaries? In section 5, regarding the example with municipal boundaries, using toronto.on.ca, while wildcards work fine for resolving www.toronto.on.ca, would they also "do the right thing" for the same web site answering to " toronto.on.ca" or would they force the boundary up to the on.ca level? This hearkens back to the discussion in the next to last paragraph of section 2 with abc.example. In section 8, the text refers to "a parent publishing records that shadow part or all of the boundary record namespace for delegated subdomains, correct operation depends on the parent and subdomains agreeing about who publishes what" but does not propose any procedural guidance on what sort of division of publishing responsibilities might be reasonable Section 10 (following from the discussion of how to implement as a series of TXT records in section 9) specifies this as a new RRTYPE. I share Murray's concerns based on the experience with the SPF RRTYPE that implementing a new RRTYPE would impede progress on a dbound solution even more so than our difficulties in achieving consensus on the problem statement :-) Nits: - Section 4, first sentence is missing an "and": ". . .takes a domain name an application. . ." --Kurt Andersen --001a1147b2c05216360529a5247a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After considering both=C2=A0draft-levine-orgboundary-04 an= d=C2=A0draft-deccio-dbound-organizational-domain-policy-01 as examples of wha= t was termed during the Yokohama discussion as a "top down" bound= ary assertion, I have found it much easier to grok the lookup sequence from= John's proposal than the one in Casey's.=C2=A0

I'm still not sure that I have entirely grasped the nuances and es= pecially the potential corner-case holes that reside within the algorithm p= roposed by Casey and I don't see the benefit of supporting an "off= line" mode since the applicability of the domain boundary lookups is i= n dealing with online, real time queries.

Que= stion regarding the text:

The last paragraph = of section 2 says "Each domain publishes its own policies". I tak= e this to mean its own boundaries, but would it be more appropriate to say = "Each ADMD publishes its own boundaries"?=C2=A0
=
It seems slightly problematic to be dependent on a (potentiall= y uncooperative) parent domain in order for child domains to be looped into= the BOUND framework. Since SOA is an established mechanism within DNS mana= gement, would it make the mechanism more resilient to follow the SOA chain = before branching off to look for BOUND records?

As a security measure, the failure to lookup a terminating record with a= NOLOWER bit set seems like its interpretation could be application depende= nt. In the case of cookies or certs, one may want individual name isolation= , but in the case of DMARC, that would enable attacks rather than prevent t= hem.

Section 3 (and 10) calls for the applica= tions to be indicated as a lookup table managed by IANA. Why not just have = defined application mechanisms which could be comma-separated in the record= rather than an encoded numeric value?

In sec= tion 5, paragraph 3, the draft reads "the record would indicate= no boundaries. . ." but then the exemplar record is "*._bound.test IN BOUND 0 0 .". Should= n't that be "*._bound.test IN = BOUND 1 0 ." to indicate no boundaries?

In s= ection 5, regarding the example with municipal boundaries, using toronto.on.ca, while wildcards work fine for res= olving www.toronto.on.ca, would th= ey also "do the right thing" for the same web site answering to &= quot;toronto.on.ca" or would they= force the boundary up to the on.ca level? Thi= s hearkens back to the discussion in the next to last paragraph of section = 2 with abc.example.=C2=A0

In section 8, the text r= efers to "a parent publishing records that shadow part or all of the b= oundary record namespace for delegated subdomains, correct operation depend= s on the parent and subdomains agreeing about who publishes what" but = does not propose any procedural guidance on what sort of division of publis= hing responsibilities might be reasonable

Section = 10 (following from the discussion of how to implement as a series of TXT re= cords in section 9) specifies this as a new RRTYPE. I share Murray's co= ncerns based on the experience with the SPF RRTYPE that implementing a new = RRTYPE would impede progress on a dbound solution even more so than our dif= ficulties in achieving consensus on the problem statement :-)
Nits:
  • Section 4, first sentence is missing an= "and": ". . .takes a domain name an application. . ."<= /li>
--Kurt Andersen
--001a1147b2c05216360529a5247a-- From nobody Tue Jan 19 08:11:57 2016 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 C7D021B315C for ; Tue, 19 Jan 2016 08:11:55 -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 ksKpr5oPSVsj for ; Tue, 19 Jan 2016 08:11:49 -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 E93441B3159 for ; Tue, 19 Jan 2016 08:11:47 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id n5so120052389wmn.0 for ; Tue, 19 Jan 2016 08:11: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=A3NnjYPFZAHe+p93jhM/RdTjk3Ih3rpakM6MMzMhfwc=; b=LYWHAVuiEz4w2kW88Z0tWonO8A9OIArsf6QixBQ5y6Z+4nCndbYtCV53zBYKLSpLZ5 vFaSHZNaxlWILrZghWSO5aJHz6OpYl3O0WFpyabIGJP9kX21W3UHXwGAfGSO/ZVWyLyW O76a6Kl86r1VAlgKIogywU40TXacLrrB0NouM= 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=A3NnjYPFZAHe+p93jhM/RdTjk3Ih3rpakM6MMzMhfwc=; b=Pr7llfWqAbgWxS6Tx+IXZx5N2sADf5N1M5LLLfmZ0nEaBKZwda75tXoKQV0YHxneAr 0qaW8+O62r+mGG7heUNcOdt/IttNM5P+L2oj6FmTZs6v+tqlnzvEXh65JN6bVmoiXpLd uVYbpdOgs899RVidrK6cX3c53tJAKVFvWIPbMJBpgAHckd5Dd/GE4UDVH3jjvNSARaBY XfecFfgpl23+bAWVSlXVPVERriAvhtHYm0pfch49FFPCLU24Fn03Zg/o4YD6/WhrckJP 8DFRX6OZvqolIDB8le2IQpKaWqKKuyh0xTiRyaEzcq5RHAS3Zt3Fe1k/n8+SBW7bsXYR IG/w== X-Gm-Message-State: AG10YOQc+d7MtostaIIrDC1yqzN+W9n9I0bJzso5jrv3DCUDASCKMbYfhWw3NWVAR03rZsmxicbSruo3FMf51Q== MIME-Version: 1.0 X-Received: by 10.28.90.67 with SMTP id o64mr19109586wmb.38.1453219906405; Tue, 19 Jan 2016 08:11:46 -0800 (PST) Received: by 10.194.73.137 with HTTP; Tue, 19 Jan 2016 08:11:46 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Jan 2016 11:11:46 -0500 Message-ID: From: Casey Deccio To: "Kurt Andersen (b)" Content-Type: multipart/alternative; boundary=001a114526b84d67120529b22005 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Thoughts and comments on 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: Tue, 19 Jan 2016 16:11:55 -0000 --001a114526b84d67120529b22005 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 18, 2016 at 7:42 PM, Kurt Andersen (b) wrote: > I'm still not sure that I have entirely grasped the nuances and especially > the potential corner-case holes that reside within the algorithm proposed > by Casey > I'm happy to answer specific questions or better explain concepts that are poorly presented. > and I don't see the benefit of supporting an "offline" mode since the > applicability of the domain boundary lookups is in dealing with online, > real time queries. > Unfortunately, domain boundary lookups are not confined to online, real-time queries. For example, for applications with performance considerations, and/or those which have resource- or network-constrained environments, online lookups might not be feasible or desirable. Nor is it necessarily feasible or desirable for logging or forensic applications. I'm sure there are other examples. The context of where we're coming from needs to be understood in designing solutions in this space: the current solution is an offline file. While a solution with an online component is reasonable, closing the door to offline solutions is not backwards compatible neither in the lookup process, nor in the behaviors inherent in the process. Also, this is one of the considerations that was discussed in the Prague meeting and later mailing list discussion: http://www.ietf.org/mail-archive/web/dbound/current/msg00502.html On this topic, I'll be updating my draft (and code implementation) in coming weeks to flesh out and clarify the offline component, addressing some of the concerns that have cropped up in that regard. Regards, Casey --001a114526b84d67120529b22005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 18, 2016 at 7:42 PM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:
I'm still not sure that = I have entirely grasped the nuances and especially the potential corner-cas= e holes that reside within the algorithm proposed by Casey

I'm happy to answer specific questi= ons or better explain concepts that are poorly presented.
=C2= =A0
and I don't see the benefit of s= upporting an "offline" mode since the applicability of the domain= boundary lookups is in dealing with online, real time queries.

Unfortunately, domain boundary look= ups are not confined to online, real-time queries.=C2=A0 For example, for a= pplications with performance considerations, and/or those which have resour= ce- or network-constrained environments, online lookups might not be feasib= le or desirable.=C2=A0 Nor is it necessarily feasible or desirable for logg= ing or forensic applications.=C2=A0 I'm sure there are other examples.<= br>
The context of where we're coming from needs to be understood in= designing solutions in this space: the current solution is an offline file= .=C2=A0 While a solution with an online component is reasonable, closing th= e door to offline solutions is not backwards compatible neither in the look= up process, nor in the behaviors inherent in the process.

Also, this= is one of the considerations that was discussed in the Prague meeting and = later mailing list discussion:

http://www.ietf.org/mail-archive/w= eb/dbound/current/msg00502.html

On this topic, I'= ll be updating my draft (and code implementation) in coming weeks to flesh = out and clarify the offline component, addressing some of the concerns that= have cropped up in that regard.

Regards,
C= asey
--001a114526b84d67120529b22005-- From nobody Thu Jan 21 19:28:25 2016 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 25BF21B3725 for ; Thu, 21 Jan 2016 19:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.264 X-Spam-Level: ** X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_37=0.6, KHOP_DYNAMIC=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 ddikdkwmqRl8 for ; Thu, 21 Jan 2016 19:28:23 -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 ACAEE1B3724 for ; Thu, 21 Jan 2016 19:28:22 -0800 (PST) Received: (qmail 79111 invoked from network); 22 Jan 2016 03:28:21 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 Jan 2016 03:28:21 -0000 Date: 22 Jan 2016 03:27:59 -0000 Message-ID: <20160122032759.2938.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: kboth@drkurt.com Subject: Re: [dbound] Thoughts and comments on 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: Fri, 22 Jan 2016 03:28:24 -0000 Thanks for taking a look. >The last paragraph of section 2 says "Each domain publishes its own >policies". I take this to mean its own boundaries, but would it be more >appropriate to say "Each ADMD publishes its own boundaries"? It's kind of a chicken and egg problem. The domain publishes the boundaries so you know where the ADMD's are. >It seems slightly problematic to be dependent on a (potentially >uncooperative) parent domain in order for child domains to be looped into >the BOUND framework. Since SOA is an established mechanism within DNS >management, would it make the mechanism more resilient to follow the SOA >chain before branching off to look for BOUND records? Zone boundaries have nothing do do with these boundaries. There are plenty of places where a single organization uses multiple zones for its internal convenience and others where lots of logically unrelated domain are in the same zone file and in a few cases the same record. Consider for example all of the separate blogs at *.blogger.com. Also, the DNS decided decades ago that the delegation authority flows down from the root. If you have a disagreement with your parent domain, you fix that with money and lawyers, not technical kludges. >As a security measure, the failure to lookup a terminating record with a >NOLOWER bit set seems like its interpretation could be application >dependent. In the case of cookies or certs, one may want individual name >isolation, but in the case of DMARC, that would enable attacks rather than >prevent them. Sure. Applications should pick defaults that make sense, and it's clear the in some cases the safe default is the names are all different while in others they're all the same. >Section 3 (and 10) calls for the applications to be indicated as a lookup >table managed by IANA. Why not just have defined application mechanisms >which could be comma-separated in the record rather than an encoded numeric >value? You need a registry either way, to keep the application names or numbers from colliding as people invent and start to use new ones. >In section 5, paragraph 3, the draft reads "the record would indicate no >boundaries. . ." but then the exemplar record is "*._bound.test IN BOUND 0 >0 .". Shouldn't that be "*._bound.test IN BOUND 1 0 ." to indicate no >boundaries? Doesn't really matter, although I suppose the 1 would save a lookup. >In section 5, regarding the example with municipal boundaries, using >toronto.on.ca, while wildcards work fine for resolving www.toronto.on.ca, >would they also "do the right thing" for the same web site answering to " >toronto.on.ca" or would they force the boundary up to the on.ca level? This >hearkens back to the discussion in the next to last paragraph of section 2 >with abc.example. In this case, toronto.on.ca is a boundary like on.ca and ca. If you had www.toronto.on.ca that would be an entity with the confusing name "www" located in Toronto. >In section 8, the text refers to "a parent publishing records that shadow >part or all of the boundary record namespace for delegated subdomains, >correct operation depends on the parent and subdomains agreeing about who >publishes what" but does not propose any procedural guidance on what sort >of division of publishing responsibilities might be reasonable Hm, I thought it was obvious but maybe not. If the delegated subdomain is really independent, the parent shouldn't shadow it. If they disagree, see discussion about money and lawyers above. >Section 10 (following from the discussion of how to implement as a series >of TXT records in section 9) specifies this as a new RRTYPE. I share >Murray's concerns based on the experience with the SPF RRTYPE that >implementing a new RRTYPE would impede progress on a dbound solution even >more so than our difficulties in achieving consensus on the problem >statement :-) Doesn't make a lot of difference to me either way. In this case, any name that contains _bound should only have DBOUND records so the downside of using TXT is less than it was with SPF where the names are unprefixed. >Nits: > > - Section 4, first sentence is missing an "and": ". . .takes a domain > name an application. . ." Thx, will fix it if I ever revise it again. R's, John From nobody Tue Jan 26 17:22:40 2016 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 27F941A1EED for ; Tue, 26 Jan 2016 17:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 tyAVtdUWCiAP for ; Tue, 26 Jan 2016 17:22:37 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 807AF1A1EEA for ; Tue, 26 Jan 2016 17:22:35 -0800 (PST) Received: from healthyao-PC (unknown [218.241.103.68]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BJUCjUG6hW1EEzCQ--.42297S2; Wed, 27 Jan 2016 09:22:28 +0800 (CST) Date: Wed, 27 Jan 2016 09:22:28 +0800 From: "Jiankang Yao" To: dbound References: <20160126112702.16322.70903.idtracker@ietfa.amsl.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201601270922110559922@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart802512260605_=----" X-CM-TRANSID: AQAAf0BJUCjUG6hW1EEzCQ--.42297S2 X-Coremail-Antispam: 1UD129KBjvJXoW7CrWUCF13GF43tw1xJFy3XFb_yoW8Xw47pa nF9ayfWwn7Z397K3ykJr1rXFyUA390qa92qF1DJr4jvrWYqa4Utw40kr48K34UZFyrCFWq gF1Ikrn3Zw15urJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9jb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF 0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeV CFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxMxkI ecxEwVAFwVWkMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWU XwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AK xVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvf C2KfnxnUUI43ZEXa7IU8FD73UUUUU== X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: [dbound] updated draft-yao-dbound-dns-solution 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: Wed, 27 Jan 2016 01:22:39 -0000 This is a multi-part message in MIME format. ------=_001_NextPart802512260605_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCiAgICAgSSBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0IChkcmFmdC15YW8tZGJv dW5kLWRucy1zb2x1dGlvbiApIGJhc2VkIG9uIGxhc3QgSUVURiBtZWV0aW5nLg0KDQogICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlhby1kYm91bmQtZG5zLXNvbHV0aW9uLTAy DQoNCiAgICAgYW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLiANCg0KICAgICB0aGFua3MuDQoNCg0K DQpKaWFua2FuZyBZYW8NCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzDQpEYXRlOiAyMDE2LTAxLTI2 IDE5OjI3DQpUbzogWGlhb2RvbmcgTGk7IEppYW5rYW5nIFlhbzsgTmluZyBLb25nOyBYaWFvRG9u ZyBMZWUNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteWFvLWRi b3VuZC1kbnMtc29sdXRpb24tMDIudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC15 YW8tZGJvdW5kLWRucy1zb2x1dGlvbi0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgSmlhbmthbmcgWWFvIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnku DQoNCk5hbWU6IGRyYWZ0LXlhby1kYm91bmQtZG5zLXNvbHV0aW9uDQpSZXZpc2lvbjogMDINClRp dGxlOiBSZXNvdXJjZSBSZWNvcmQgZm9yIEROUyBBZG1pbmlzdHJhdGl2ZSBCb3VuZGFyaWVzDQpE b2N1bWVudCBkYXRlOiAyMDE2LTAxLTI2DQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQ YWdlczogMTANClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQteWFvLWRib3VuZC1kbnMtc29sdXRpb24tMDIudHh0DQpTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteWFvLWRib3VuZC1kbnMt c29sdXRpb24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXlhby1kYm91bmQtZG5zLXNvbHV0aW9uLTAyDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXlhby1kYm91bmQtZG5zLXNvbHV0aW9uLTAy DQoNCkFic3RyYWN0Og0KICAgVHdvIG9yIG1vcmUgRE5TIG5hbWVzIG1heSBoYXZlIHRoZSBzYW1l IEROUyBhZG1pbmlzdHJhdGl2ZQ0KICAgYm91bmRhcmllcy4gIFRoaXMgZG9jdW1lbnQgYWRkcyB0 aGUgZnVuY3Rpb24gb2YgbG9va3VwIG9mIGRvbWFpbiBuYW1lDQogICBhZG1pbmlzdHJhdGl2ZSBi b3VuZGFyeSB0byBkb21haW4gbmFtZSBzeXN0ZW0sIHdoaWNoIGRlc2NyaWJlcyBhIG5ldw0KICAg bWV0aG9kIGZvciB1c2luZyBkYm91bmQgcmVzb3VyY2UgcmVjb3JkIGZvciBqdWRnaW5nIGRvbWFp biBuYW1lDQogICBhZG1pbmlzdHJhdGl2ZSBib3VuZGFyaWVzLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQ= ------=_001_NextPart802512260605_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Dear all,
 
     I have updated the draft=20 (draft-yao-dbound-dns-solution ) based on last IETF meeting.
 
    http= s://tools.ietf.org/html/draft-yao-dbound-dns-solution-02
 
     any comments are welcome. 
 
     thanks.
Jiankang Yao
 
From: internet-drafts
Date: 2016-01-26 19:27
To: Xiaodong Li; Jiankang Yao; Ning Kong; XiaoDong Lee
Subject: New Version Notification for=20 draft-yao-dbound-dns-solution-02.txt
 
A new version of I-D, draft-yao-dbound-dns-s= olution-02.txt
has been successfully submitted by Jiankang&= nbsp;Yao and posted to the
IETF repository.
 
Name: draft-yao-dbound-dns-solution
Revision: 02
Title:=20 Resource Record for DNS Administrative Boundaries=
Document date: 2016-01-26
Group: Individual Submission
Pages: 10
URL:           = ; https://www.ietf.org/internet-drafts/draft-yao-dbound-dns-solution-= 02.txt
Status:         https://= datatracker.ietf.org/doc/draft-yao-dbound-dns-solution/
Htmlized:       https://tools.ietf= .org/html/draft-yao-dbound-dns-solution-02
Diff:          &nbs= p;https://www.ietf.org/rfcdiff?url2=3Ddraft-yao-dbound-dns-solution-02
 
Abstract:
   Two or more DNS names may&= nbsp;have the same DNS administrative
   boundaries.  This document adds=  the function of lookup of domain name<= /DIV>
   administrative boundary to domain&nb= sp;name system, which describes a new
   method for using dbound resourc= e record for judging domain name
   administrative boundaries.
 
           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;        
 
 
Please note that it may take a cou= ple of minutes from the time of submiss= ion
until the htmlized version and diff are=  available at tools.ietf.org.
 
The IETF Secretariat
 
------=_001_NextPart802512260605_=------ From nobody Wed Jan 27 18:56:34 2016 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 7589B1B30E7 for ; Wed, 27 Jan 2016 18:56:33 -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 JandJhwegkn3 for ; Wed, 27 Jan 2016 18:56:31 -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 781B61B30DE for ; Wed, 27 Jan 2016 18:56:31 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id e6so16480665vkh.2 for ; Wed, 27 Jan 2016 18:56:31 -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=Agps0erm5fSaYa7/Tlev80wHwPNG4SDM81HtXOvGF7A=; b=ZajRSHzb5bPHFt2kV/v+LD/s/kx5vdaD0YFZvp2wJACe4AnX629usstYgSEaaR/mj9 XPxyy6aryWB4RtbYhzVmWD3aajm6pMVFL9kGvmpqA+A71sPqjSI7QZT575RdTBzaiuLK YxG9fTDEiWqgmKqBnGp90wR/i204iUki+EJ9whkroHr3BxbFqSpPPJ+6JhUhm6dVB9W1 1KVq4unlJX21my/CmKnUVe0LlNXcO+8pSUkTYlv7y/GpxluQSq2ohtVqipE8WyVHQKts cjczANnhsPJFqOUDzguITKh1k8pvOxiS71Q9kKvVz+GkNIQT0fPsS2gvMjj8xfBoBtVt 9u+A== 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=Agps0erm5fSaYa7/Tlev80wHwPNG4SDM81HtXOvGF7A=; b=egiGlrNkamMZ22VGBXVP11JruTKGv4XPf9LHx0JCEcYM33rkLv5pF5pMvWLZtuoI06 J6rd59omFZsCKcwBpQg+T+pZkKHL1R2t1v03hZjSxowX0xrJtEbrtDN/mtRy9Tqlvwsv PmEk/8VLyEi3axf48ac2JkZwXbI487wdnbI7Ab/3aBRqk3GDo95K5lXhtr9aS/vKoS1d 9+OL4IORFgCv/IoEbh9E4yk5K3824hVGUVwLCx/kvJ4dQYP8FTRgV5H3oo0wGHw4mwiY GeiD/Ml+xiqhZI1prsHXY+Y1Z5pBm2zjEBGZHyUDGjbw32sc8XhxRnaKllUsaKEvdQUT peNA== X-Gm-Message-State: AG10YOQ4PXpd/csLHpETmdFgypwTsi29E6vf/a1/hP67XPP1wcUupg8+XOno3fotm/z9jytMDQJ4KGnPdQN4Sg== MIME-Version: 1.0 X-Received: by 10.31.7.140 with SMTP id 134mr441435vkh.155.1453949790309; Wed, 27 Jan 2016 18:56:30 -0800 (PST) Received: by 10.103.72.220 with HTTP; Wed, 27 Jan 2016 18:56:30 -0800 (PST) Date: Wed, 27 Jan 2016 18:56:30 -0800 Message-ID: From: "Murray S. Kucherawy" To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=001a1143f252c5d226052a5c100e Archived-At: Subject: [dbound] No meeting planned for IETF 95 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, 28 Jan 2016 02:56:33 -0000 --001a1143f252c5d226052a5c100e Content-Type: text/plain; charset=UTF-8 Colleagues, We are more than half way through the window during which we can request meeting time at IETF 95. Pete and I have chatted, and given our remarks at IETF 94 and the dearth of activity since about a week after that meeting, we will likely not be making any such request. This shouldn't be a surprise to anyone, but we would be happy to hear counter-arguments or evidence of necessity before the window closes. -MSK, DBOUND co-chair --001a1143f252c5d226052a5c100e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

We are more than h= alf way through the window during which we can request meeting time at IETF= 95.=C2=A0 Pete and I have chatted, and given our remarks at IETF 94 and th= e dearth of activity since about a week after that meeting, we will likely = not be making any such request.

This shouldn't be a surpri= se to anyone, but we would be happy to hear counter-arguments or evidence o= f necessity before the window closes.

-MSK, DBOUND co-chair
--001a1143f252c5d226052a5c100e-- From nobody Thu Jan 28 09:18:57 2016 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 62FAC1A8A91 for ; Thu, 28 Jan 2016 09:18:55 -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 V0nJROQBmhPY for ; Thu, 28 Jan 2016 09:18:50 -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 2C4601A8A95 for ; Thu, 28 Jan 2016 09:18:50 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id p63so34324820wmp.1 for ; Thu, 28 Jan 2016 09:18:50 -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=01YrZfaq4r/GkgUJSU78YxR60eD3y1h9XfoMtmea8Mo=; b=Byiuwb2CKCD1tDIjZhRTjglcpKLs7FF8tmjo/ZJN0RM/AyOO98mriHdC2JISj9t6PV yRYcal8tEJg0caVOuP8j5cgVlZPHXl3iAcXZF4/BjyBEuA8us15G4opz9RZJjIhpHHkG q2fmmYxuDGsVrOS0ldTfqAD5lcqg0SMstD6FI= 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=01YrZfaq4r/GkgUJSU78YxR60eD3y1h9XfoMtmea8Mo=; b=dJHOf2moX+H/mDy0yxS3C09ShClhcj2gAD4keG4VU/INTAnUnoXYx5pr16y8CoQqYB phJ3hG5sJQNAcA1+3DNWLmFaS69PGvCZefWERUvrVeS8FT6zBGi5qP6TzUiYqNNLAVp0 pOBggqGmbTXJPybjetbLpl3N3o1VZO25ePGCwHkn+jpkCIw36TMy3bEyFuJSHEdFxfzm agk4kyyiO1+anQVLrvxeka3NTXrVcX0hBPYlGkJxvEd1Z2N+2oIBUYrNNW7nWLTxpdef sc9w1BHdo2b3zYMET4HUcNWdQfzVNKfuWrDvA9ish/6/WjkE2bPb8sacc12Ls17IWBEG TNaQ== X-Gm-Message-State: AG10YOSuEc7EfP14IEM3S2jCWzpSscOeUaDTSkVhYHCYNBVMfuERGED5nuYSZtGY/H5n3ObgDyOqzuBRJ6Vk3Q== MIME-Version: 1.0 X-Received: by 10.28.125.77 with SMTP id y74mr1174134wmc.21.1454001528640; Thu, 28 Jan 2016 09:18:48 -0800 (PST) Received: by 10.194.73.137 with HTTP; Thu, 28 Jan 2016 09:18:48 -0800 (PST) In-Reply-To: References: Date: Thu, 28 Jan 2016 12:18:48 -0500 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=001a1141d2169e3fdb052a681c30 Archived-At: Subject: Re: [dbound] No meeting planned for IETF 95 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, 28 Jan 2016 17:18:55 -0000 --001a1141d2169e3fdb052a681c30 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 27, 2016 at 9:56 PM, Murray S. Kucherawy wrote: > Colleagues, > > We are more than half way through the window during which we can request > meeting time at IETF 95. Pete and I have chatted, and given our remarks at > IETF 94 and the dearth of activity since about a week after that meeting, > we will likely not be making any such request. > > This shouldn't be a surprise to anyone, but we would be happy to hear > counter-arguments or evidence of necessity before the window closes. > > I think it would be useful to identify where the working group is at the moment. I'll give my take. Problem statement/milestones: At the WG meeting in Prague and in mailing list conversations the problem was broken down into two major categories: identifying (or repudiating) relationships between in-domain names and for cross-domain names. For current protocols (e.g., HTTP cookies, DMARC) the in-domain relationship component is the most immediately relevant, as they cross-domain relationships are out of scope. The two problem aspects might be solved by a single solution or by separate solutions. It has been expressed that a solution for both should not block the solution for one. It would be useful for the WG to get some consensus on the above points. Such can give way for the definition of milestones, and milestones can help us on our goal of solving the problems at hand. Solutions documents/reviews: There has been a lot of high-level discussion both on the mailing list and in WG meetings about solution concepts. While that thinking is useful, I feel that that discussion has reached a point of diminishing returns, and it is time to see the concepts materialize for further development and feedback by the WG. The concepts can provide more utility when there is some substance to evaluate in light of them. There are three active solutions drafts at the moment, two of which (Levine and Deccio drafts) specifically address the in-domain problem. Very few reviews of these documents have been made, and none have been adopted by the working group. I don't know whether the lack of formal problem breakdown and milestone definition have hindered review and refinement of the solutions drafts, if interest has waned, and/or there are other impediments. I would welcome meeting time at IETF 95, but I think we could only get meaning out of it if we answer some of the questions above, and there is some work done on the mailing list before then to provide a meaningful content for that meeting. Regards, Casey --001a1141d2169e3fdb052a681c30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 27, 2016 at 9:56 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
Colleagues,

We are more than hal= f way through the window during which we can request meeting time at IETF 9= 5.=C2=A0 Pete and I have chatted, and given our remarks at IETF 94 and the = dearth of activity since about a week after that meeting, we will likely no= t be making any such request.

This shouldn't be a surprise= to anyone, but we would be happy to hear counter-arguments or evidence of = necessity before the window closes.

I think it would be useful to identify where the working group= is at the moment.=C2=A0 I'll give my take.

Problem s= tatement/milestones: At the WG meeting in Prague and in mailing list conver= sations the problem was broken down into two major categories: identifying = (or repudiating) relationships between in-domain names and for cross-domain= names.=C2=A0 For current protocols (e.g., HTTP cookies, DMARC) the in-doma= in relationship component is the most immediately relevant, as they cross-d= omain relationships are out of scope.=C2=A0 The two problem aspects might b= e solved by a single solution or by separate solutions.=C2=A0 It has been e= xpressed that a solution for both should not block the solution for one.
It would be useful for the WG to get some consensus on the = above points.=C2=A0 Such can give way for the definition of milestones, and= milestones can help us on our goal of solving the problems at hand.
Solutions documents/reviews: There has been a lot of high-level= discussion both on the mailing list and in WG meetings about solution conc= epts.=C2=A0 While that thinking is useful, I feel that that discussion has = reached a point of diminishing returns, and it is time to see the concepts = materialize for further development and feedback by the WG.=C2=A0 The conce= pts can provide more utility when there is some substance to evaluate in li= ght of them.=C2=A0 There are three active solutions drafts at the moment, t= wo of which (Levine and Deccio drafts) specifically address the in-domain p= roblem.=C2=A0 Very few reviews of these documents have been made, and none = have been adopted by the working group.=C2=A0 I don't know whether the = lack of formal problem breakdown and milestone definition have hindered rev= iew and refinement of the solutions drafts, if interest has waned, and/or t= here are other impediments.

I would welcome meeting time = at IETF 95, but I think we could only get meaning out of it if we answer so= me of the questions above, and there is some work done on the mailing list = before then to provide a meaningful content for that meeting.

Regards,
Casey
--001a1141d2169e3fdb052a681c30-- From nobody Thu Jan 28 12:34:10 2016 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 F272D1ACEBD for ; Thu, 28 Jan 2016 12:34:08 -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 w-tBbm0p4n0R for ; Thu, 28 Jan 2016 12:34:07 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 3EFCE1ACEAB for ; Thu, 28 Jan 2016 12:34:07 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id s68so16176332qkh.3 for ; Thu, 28 Jan 2016 12:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UgFHGkVmT/oWyfLRRGTaxGv1iauEPyXB4vw94MKq0Ds=; b=dxOXrsTIyiKd77s+vP07fxYB7uADHLdXzz4kvL4rDxPzlEpzNq4rPnt7zyO0qKNENk Ir3fmPYTRzzoHLoVm9XTbZzD161N1/bMS+6ONJVmumJjp5jwJ2qAC665RYZccM+PKW/n DtVS1Q6BVxtyQ9wxKTC0mnr9Fc8mNiCggc4ek= 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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UgFHGkVmT/oWyfLRRGTaxGv1iauEPyXB4vw94MKq0Ds=; b=k4LrHu+50DaiCJf4HDu8bmSeJGh/Dof+AI8UEZpxHSRDl7b8ci333tMC3EbI3/KXnM l8Wpnhq5nvySOKzxKTN1geDQzizwSWnehY2P67ECnpFicsnlgaunZHGhq9ziKGrmznvv nPCLcyhhNRrIIa+LLrzjKoHS9ReLh0aOobocGeIjEb7UdsmxSHlM46v4HkbE/YQ9hFYJ k2GkWVUiVuzfd4Kje/uRaNDImUgDmvXLzQFAdI0muEYk9/G07vPC4FrUpUc2QlXTWJWu T8ILeme/e28S3wUPLVEBX9Iv/cvDPENVA8V1m3Y41ka4chMUO/EmKsMR8WR74te7oYJ3 fUrg== X-Gm-Message-State: AG10YOR8BQ8SFIwe2fPvp7aPkOBPIG9jWSqHplmcSDiZGXKGdqPmx0N/J7gMdtXur2V42113W28IVa483H1e+w== MIME-Version: 1.0 X-Received: by 10.55.53.208 with SMTP id c199mr6262118qka.109.1454013246383; Thu, 28 Jan 2016 12:34:06 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.44.129 with HTTP; Thu, 28 Jan 2016 12:34:06 -0800 (PST) In-Reply-To: References: Date: Thu, 28 Jan 2016 12:34:06 -0800 X-Google-Sender-Auth: fBCZutTiXUTjE-9ifkJX7twmvP4 Message-ID: From: "Kurt Andersen (b)" To: Casey Deccio Content-Type: multipart/alternative; boundary=001a11470ed20cc43c052a6ad715 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] No meeting planned for IETF 95 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, 28 Jan 2016 20:34:09 -0000 --001a11470ed20cc43c052a6ad715 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 28, 2016 at 9:18 AM, Casey Deccio wrote: > > I think it would be useful to identify where the working group is at the > moment. I'll give my take. > > Problem statement/milestones: At the WG meeting in Prague and in mailing > list conversations the problem was broken down into two major categories: > identifying (or repudiating) relationships between in-domain names and for > cross-domain names. For current protocols (e.g., HTTP cookies, DMARC) the > in-domain relationship component is the most immediately relevant, as they > cross-domain relationships are out of scope. The two problem aspects might > be solved by a single solution or by separate solutions. It has been > expressed that a solution for both should not block the solution for one. > > It would be useful for the WG to get some consensus on the above points. > Such can give way for the definition of milestones, and milestones can help > us on our goal of solving the problems at hand. > Agreed, with the additional point that there was discussion in Yokohama about further expanding the problem space topology to include a recognition that "top-down" and "bottom-up" approaches may need to be explored, or at least discussed to cover the solution space. Solutions documents/reviews: There has been a lot of high-level discussion > both on the mailing list and in WG meetings about solution concepts. While > that thinking is useful, I feel that that discussion has reached a point of > diminishing returns, and it is time to see the concepts materialize for > further development and feedback by the WG. > Also agreed. > . . . the lack of formal problem breakdown and milestone definition [may] > have hindered review and refinement of the solutions drafts. . . > I think that captures quite a bit of our stagnation. > I would welcome meeting time at IETF 95, but I think we could only get > meaning out of it if we answer some of the questions above, and there is > some work done on the mailing list before then to provide a meaningful > content for that meeting. > F2F at the IETF seems like overkill. I'd suggest that some phone conferences might be a more effective mechanism to advance the discussions. I'm willing to help facilitate such if the chairs and main contributors are in agreement. --Kurt Andersen --001a11470ed20cc43c052a6ad715 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 28, 2016 at 9:18 AM, Casey Deccio <casey@deccio.net> = wrote:

I think it would be useful to identify where the working group is at = the moment.=C2=A0 I'll give my take.

Problem statemen= t/milestones: At the WG meeting in Prague and in mailing list conversations= the problem was broken down into two major categories: identifying (or rep= udiating) relationships between in-domain names and for cross-domain names.= =C2=A0 For current protocols (e.g., HTTP cookies, DMARC) the in-domain rela= tionship component is the most immediately relevant, as they cross-domain r= elationships are out of scope.=C2=A0 The two problem aspects might be solve= d by a single solution or by separate solutions.=C2=A0 It has been expresse= d that a solution for both should not block the solution for one.

It would be useful for the WG to get some consensus on the above p= oints.=C2=A0 Such can give way for the definition of milestones, and milest= ones can help us on our goal of solving the problems at hand.

Agreed, with the additional = point that there was discussion in Yokohama about further expanding the pro= blem space topology to include a recognition that "top-down" and = "bottom-up" approaches may need to be explored, or at least discu= ssed to cover the solution space.

Solutions documents/reviews: There has been a lot of high-level = discussion both on the mailing list and in WG meetings about solution conce= pts.=C2=A0 While that thinking is useful, I feel that that discussion has r= eached a point of diminishing returns, and it is time to see the concepts m= aterialize for further development and feedback by the WG.=C2=A0

Also agreed.
=C2= =A0
. . . the lack of formal problem b= reakdown and milestone definition [may] have hindered review and refinement= of the solutions drafts. . .
=
I think that captures quite a bit of our stagnation.
=C2=A0
I would welcome= meeting time at IETF 95, but I think we could only get meaning out of it i= f we answer some of the questions above, and there is some work done on the= mailing list before then to provide a meaningful content for that meeting.=

F2F at the IETF se= ems like overkill. I'd suggest that some phone conferences might be a m= ore effective mechanism to advance the discussions. I'm willing to help= facilitate such if the chairs and main contributors are in agreement.=C2= =A0

--Kurt Andersen
--001a11470ed20cc43c052a6ad715-- From nobody Thu Jan 28 18:49:00 2016 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 711871B3753 for ; Thu, 28 Jan 2016 18:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=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 SF05FqEFwYkS for ; Thu, 28 Jan 2016 18:48:58 -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 6FB0C1B3752 for ; Thu, 28 Jan 2016 18:48:58 -0800 (PST) Received: (qmail 51064 invoked from network); 29 Jan 2016 02:48:56 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 29 Jan 2016 02:48:56 -0000 Date: 29 Jan 2016 02:48:34 -0000 Message-ID: <20160129024834.48514.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: kboth@drkurt.com Subject: Re: [dbound] No meeting planned for IETF 95 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: Fri, 29 Jan 2016 02:48:59 -0000 If we're going to go back and revisit the question of what problem(s) we're trying to solve, we can save time and shut down the WG, since that's the place we've been spinning our wheels for years. I don't think that top-down vs. bottom-up in particular is a problem since my proposal and I think Casey's can work either way. At this point we have three proposals: draft-deccio-dbound-organizational-domain-policy-01.txt draft-levine-orgboundary-04.txt draft-yao-dbound-dns-solution-02.txt If people are still interested in this topic, it'd be a help if you'd read the drafts, ask questions about stuff that is confusing, and see if we can come up with a list of questions and comments that distinguish them so we can perhaps see which one(s) address people's problems best. For example: Is it OK that Deccio uses a new _odup top level domain? Does Levine need to address some of the more complex cases that Deccio does? Is it useful that Yao's design can refer queries to PSL like text files? R's, John From nobody Thu Jan 28 19:00:11 2016 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 3079A1B3767 for ; Thu, 28 Jan 2016 19:00:09 -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 sCFnDQHAVGzB for ; Thu, 28 Jan 2016 19:00:08 -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 E08CB1B2CAF for ; Thu, 28 Jan 2016 19:00:07 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id p63so50284015wmp.1 for ; Thu, 28 Jan 2016 19:00:07 -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=/iXLY9NoxlI1LxdkvMgOzgdMM0YpYzCgvbRpDB7rWhI=; b=XYc+KxvyXf0FxFACvh+MYkzuIJfbbiURgpybsmzSTvyWKTz8CKv8FdwWekKuJpWP/c YsPHQipKZwxlM2BzDciWhigxLYgSoxfpcPZBynjdYeCBrOTqi7REbCh14tGnd5dmqmRt ToFaZjXzFsTjg85VaPgbv8uifn1oyExFwaffI= 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=/iXLY9NoxlI1LxdkvMgOzgdMM0YpYzCgvbRpDB7rWhI=; b=AxsT7K0Lv4EStSal+r9FMP1NL6EMrz68EPDj2lPJvItHtV1mUGwYKxbT4Sz4Fnd9El lvHHfcA2+o26WwMWmwr/sZaqKqDIXK/anDEADlaZUx/nSL0jf4UqlHstzLKN+doxM6tU C8UkREqdVwxaMPKb7fin+pIN7lfko6wphWNUbjxuwkAuIVyVRQ62269lP84qQ9jdgSOv taoSgjfR7tXQwRQxvF2DVUVaY04SgfmwbP9MRGh/EL0/ywS0pGbpm8mATqebkUvxoDkI d4drtlSwFPoibpJX/TEL6BcKzGoJXi4HcSXwpPbYcCjVBCILpB3TuTJ7minIYbtfgtLg QqDA== X-Gm-Message-State: AG10YORwlI71O9Wu11C1hFc70kI6iXvlK1wI73w2gVF/La+Ze1sxwhBqrrzxOkd6hM4K1bIXj4tEKvOUV2OW9Q== MIME-Version: 1.0 X-Received: by 10.194.80.200 with SMTP id t8mr6071725wjx.74.1454036406472; Thu, 28 Jan 2016 19:00:06 -0800 (PST) Received: by 10.194.73.137 with HTTP; Thu, 28 Jan 2016 19:00:06 -0800 (PST) In-Reply-To: <20160129024834.48514.qmail@ary.lan> References: <20160129024834.48514.qmail@ary.lan> Date: Thu, 28 Jan 2016 22:00:06 -0500 Message-ID: From: Casey Deccio To: John Levine Content-Type: multipart/alternative; boundary=089e0103dfe47faff9052a703bb2 Archived-At: Cc: Kurt Andersen , "dbound@ietf.org" Subject: Re: [dbound] No meeting planned for IETF 95 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: Fri, 29 Jan 2016 03:00:09 -0000 --089e0103dfe47faff9052a703bb2 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 28, 2016 at 9:48 PM, John Levine wrote: > If we're going to go back and revisit the question of what problem(s) > we're trying to solve, we can save time and shut down the WG, since > that's the place we've been spinning our wheels for years. +1 This is precisely what I was referring to in my comment about conceptual discussions having reached the point of diminishing returns. > Is it OK that Deccio uses a new _odup top level domain? > (This will change in the -02 version of the draft.) Casey --089e0103dfe47faff9052a703bb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 28, 2016 at 9:48 PM, John Levine <johnl@taugh.c= om> wrote:
If we're going to go back and rev= isit the question of what problem(s)
we're trying to solve, we can save time and shut down the WG, since
that's the place we've been spinning our wheels for years.

+1

This is precisely what I was referring to= in my comment about conceptual discussions having reached the point of dim= inishing returns.
=C2=A0
Is it OK that Deccio uses a new _odup top level domain?

(This will change in the -02 version of the draft.)
=C2=A0
Casey
--089e0103dfe47faff9052a703bb2-- From nobody Thu Jan 28 20:41:50 2016 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 3E2C61B3D38 for ; Thu, 28 Jan 2016 20:41:48 -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 GeXS9DckVn1X for ; Thu, 28 Jan 2016 20:41:45 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 AD5A21B3D34 for ; Thu, 28 Jan 2016 20:41:45 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id n1so35947449vkb.3 for ; Thu, 28 Jan 2016 20:41:45 -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=066fJd4HTZlUYZFoTpYuSHrxn7Iug1XBltBwns9RWYE=; b=m8fLH98wNxC24TrKopBbuBWL+0ESEbPWdAXTPeueidpOY8a9bxLqkP2nVRNCFKQejc 795kcTsdK+Q7uAlG2Kpd1LeWwWgm7ZzYkjXlmp6qQkKpYUeO5TAKfEnmNcQmqG7VU++u cGyrT9DI7HV5gDIvHXsG5Vkmz5QHpV3vA/ZU0A+7dVzmQO/axoFpi5vnqGo2qjT0Kyf3 /9b/c8VDNtENxQ8p0UCsoA2b9PNskINa5DzUL6RdriFmAYfJAaVDVIbF3z5ZdZt1l9jx XjC/ZwKrUVrHEIlrfI8LSgGDRkmkkWDkILqkY0ApSmFDzIHUYD+810J6CUkWthMTyOz1 dDzA== 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=066fJd4HTZlUYZFoTpYuSHrxn7Iug1XBltBwns9RWYE=; b=OL/cTkviNkOiNFCtcuC7wTGifPlHqV1PxtVpMhGerpjKo1mbKB0DKa0dS9F9KZDkZJ 2XzhwRyRB0E2oVqoXe3HmMYAIYg54tRNA2lHQXcKg7e5YtJ0xZ5nN+JsX/gAAUbccptz DPmwh4YRKX23mBmBxtPv4S2AbnUVn85cvcxub8R6bVfa10yk8my1JBU5yDs2g2hE+try ykFOG8PKGe1sCcg4xmlwxVc1BYHkAXr7Vd4n1yWZ+HigiAbY6DVTf+jDfvRkSCWr2NX3 QrCVI7KEg2CqnrH9Ev/cR+TQDckUhEF7gYSc91EqGWVvCMLUwm9U8s0eGXOG/pLH0PNT zqPw== X-Gm-Message-State: AG10YOTtxK3C1XkctmbhN8Dc6byOeYft6CO1JJpZbUapeXR5AeY27GlCVgAl27PB5ILQs4PDCsoKKNYCtXHSug== MIME-Version: 1.0 X-Received: by 10.31.151.11 with SMTP id z11mr4600552vkd.131.1454042504855; Thu, 28 Jan 2016 20:41:44 -0800 (PST) Received: by 10.103.72.220 with HTTP; Thu, 28 Jan 2016 20:41:44 -0800 (PST) In-Reply-To: <20160129024834.48514.qmail@ary.lan> References: <20160129024834.48514.qmail@ary.lan> Date: Thu, 28 Jan 2016 20:41:44 -0800 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=001a1140f86afd86bb052a71a6ff Archived-At: Cc: Kurt Andersen , "dbound@ietf.org" Subject: Re: [dbound] No meeting planned for IETF 95 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: Fri, 29 Jan 2016 04:41:48 -0000 --001a1140f86afd86bb052a71a6ff Content-Type: text/plain; charset=UTF-8 Speaking strictly as a participant: On Thu, Jan 28, 2016 at 6:48 PM, John Levine wrote: > > Is it OK that Deccio uses a new _odup top level domain? > > Does Levine need to address some of the more complex cases that Deccio > does? > > Is it useful that Yao's design can refer queries to PSL like text files? > > A couple more I can think of off the top of my head: Which ones look like they might start out addressing some of our overall problem space, and then possibly extend to some of the rest? Which ones lend themselves to quick implementation and experimentation? -MSK --001a1140f86afd86bb052a71a6ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking strictly as a participant:

On Thu, Jan 28, 2016 at 6:48 PM= , John Levine <johnl@taugh.com> wrote:

Is it OK that Deccio uses a new _odup top level domain?

Does Levine need to address some of the more complex cases that Deccio does= ?

Is it useful that Yao's design can refer queries to PSL like text files= ?


A couple more I can think of off the top of my head:
Which ones look like they might start out addressing some of our over= all problem space, and then possibly extend to some of the rest?
<= div class=3D"gmail_quote">

Which ones lend themselves to= quick implementation and experimentation?

-MSK
=
--001a1140f86afd86bb052a71a6ff--